If your organization was hit by ransomware, your identity system was compromised.
That's not speculation. That's the mechanism. Ransomware doesn't drop from the sky fully formed. It gets in, moves laterally, escalates privileges, finds your crown jewels, and then encrypts everything. The lateral movement and privilege escalation happen inside your identity infrastructure. By the time you see the ransom note, your identity system has been serving the attacker for a while.
The question isn't whether your identity was compromised. The question is when.
I've spent 20 years at the C-level as a CISO, CIO, and CTO, and this is the recovery problem most organizations still haven't processed.
The ninety-day problem
The average attacker dwell time in enterprise environments before detection runs somewhere north of ninety days. Ninety days of activity, inside your network, inside your systems, using your identity infrastructure to move around.
That number has profound implications for recovery.
If your attacker has been in your environment for ninety days, the backup you restore from was created while the attacker was present. The "clean" restore point you think you're targeting might not be clean. You might be restoring to a state that was already compromised at the time the backup ran.
How do you know which backup to restore from? You probably don't. Not with certainty.
That's the identity recovery problem. It's not "how do I restore Active Directory?" It's "how do I restore to a state I can actually trust, and how do I verify that trust without using the identity system that's already been compromised?"
The AD forest recovery gap
Active Directory forest recovery shows up in nearly every data-protection platform's feature list now. It's a real capability and worth having. But it's increasingly an incomplete answer.
In 2026, Active Directory and Microsoft Entra ID are so entangled in most enterprise environments that you can't meaningfully separate their recovery. Your on-prem AD is syncing to Entra. Your conditional access policies live in Entra. Your device identities are registered in Entra. Your application registrations, your API permissions, your privileged identity management assignments. All of it is in Entra.
Recovering an AD forest without a complete Entra recovery story isn't recovery. It's half a solution.
The backup platforms are all working this problem from the data-protection side, and several can validate identity infrastructure in an isolated environment during a cyber incident. The purpose-built specialists have been doing AD and Entra recovery longer than the backup platforms have. Semperis is the benchmark in that specialist category: its tooling is built specifically for the scenario where you can't trust your identity infrastructure, and its Entra ID recovery story is the most complete in the category. If identity recovery is a primary concern, that specialist tier is the bar to measure against regardless of what your primary backup platform is.
The gap that every one of them is still working through is the same: the Entra piece is where the real complexity lives in 2026. No vendor has a fully complete hybrid story yet. They're all catching up to the entanglement.
The direction is right. Identity resilience deserves the focus it's getting. But that story is still developing.
More importantly, recovering the identity infrastructure doesn't answer the harder question: which recovery point can you actually trust?
The password reset problem
When you determine that your identity system was compromised, the standard playbook says reset all passwords.
That sounds straightforward. It isn't.
Who gets to reset the passwords? That action requires privileged access to the identity system. If the identity system is the thing that was compromised, who do you trust to have that privilege during recovery?
How do you prevent a compromised account from being the one that resets its own credentials? In an automated environment with hundreds or thousands of accounts, the risk of a bad actor having planted a credential that survives the reset process is real.
How do you know the reset worked? How do you know no accounts were missed? How do you bootstrap trust in the new credential state without being able to fully trust the system that issued the new credentials?
These are not rhetorical questions. They're the operational reality of identity recovery, and they don't appear in most vendor recovery workflows because they don't have easy answers.
Identity in 2026 is not just AD
Something else needs to be said here, and it changes the recovery calculus significantly.
The identity conversation in enterprise security has been organized around two categories: Human Identity and Non-Human Identity. HI and NHI. The HI bucket is users. The NHI bucket is service accounts, API keys, scheduled jobs, and everything else that authenticates without a person directly doing the authenticating.
AI agents are being dropped into the NHI bucket by default. That's the wrong bucket, and the mistake has real consequences for recovery.
A service account is deterministic. It does what it's configured to do. It accesses the same three systems in the same way it has since 2018. Even when it's over-provisioned, the workload rarely uses the extra scope. NHI governance was built around that predictability.
An AI agent is not predictable in the same way. That's the feature, not a bug. The model is designed to reason, plan, and adapt. To find creative paths to the goal when the first approach doesn't work. To explore the potential of its available permissions to accomplish the task it's been given.
A service account doesn't push the limits of its permissions. An AI agent will. And there are documented cases of agents working themselves out of sandboxes because the sandbox was too restrictive for the task, and the permissions next door were loose enough to allow it. The agent did exactly what it was designed to do.
This is why I've been calling AI agents Non-Deterministic Identities. NDIs. Not NHIs. Not HIs. A new category with a new name, because the word shapes the program. If your team governs agents like NHIs, they will build NHI controls. NHI controls were not designed for principals that explore.
The recovery implication is direct. When you're recovering identity after a ransomware incident or extended attacker dwell, you're not just auditing user accounts and service accounts. You're auditing agents whose behavior during the compromise window was non-deterministic. Did an agent access something it shouldn't have? Did it make decisions during the dwell period that compounded the damage? How do you audit behavior that wasn't fully specified in advance?
These are not rhetorical questions. They are the identity recovery questions that no backup vendor has answered yet, because the industry hasn't fully named the problem.
What to do
Before an incident, define your trust bootstrap process. How does recovery work when you can't trust your identity system? What's the out-of-band process for establishing initial privileged access to begin recovery? Who authorizes it? How is it documented?
Understand your Entra exposure. Know which capabilities in your environment are dependent on Entra, and what recovery of those capabilities requires. Don't find out during an incident that your AD recovery plan doesn't cover half your actual identity infrastructure.
Know your dwell time risk. Work backward from your average backup retention window. If an attacker had ninety-day dwell time and your retention is sixty days, your oldest backup was created when the attacker was already present. That's the math. Know what it means for your recovery plan.
Push vendors on the Entra story. AD forest recovery is a starting point. Ask your backup vendor how their identity recovery story handles Entra, hybrid environments, and conditional access policies. If they don't have a complete answer, that's important information.
A few specifics worth committing to:
- Enterprise IT leaders: Define your trust bootstrap process now. Who has authority to begin recovery, how do they get that authority, and how does that process work when your identity infrastructure is the thing you're recovering?
- CISOs: The ninety-day dwell time isn't a threat intelligence statistic. It's a recovery planning variable. Use it as one.