For a long time, cyber recovery meant restoring data. Get the servers back online, recover the files, and reset some passwords. Identity was something you dealt with after the real work was done.
That thinking is getting organizations into trouble.
According to Palo Alto Networks’ Unit 42 Global Incident Response Report, nearly 90% of incident response investigations trace back to identity compromise. Attackers aren’t usually exploiting obscure technical vulnerabilities—they’re getting in through credentials. Stolen passwords, abused service accounts, and social engineering. At the point of attack, they look like legitimate users. And by the time anyone notices, they’ve been moving around the environment for weeks, quietly changing permissions, escalating privileges, creating footholds.
I’ve been making a version of this argument for a while. Around 2018 or 2019, I was talking to a company focused on insider threats and made the point that at the moment of attack, they’re basically all insider threats. Very rarely is someone hacking you in the old-school sense anymore. It starts with identity. What’s changed since then is how much the scope of identity has expanded.
The Problem Nobody Had a Good Answer For
Restoring a virtual machine or recovering a database is a solved problem. Restoring a trustworthy identity environment is not.
Identity is not a static object. It’s a web of relationships—users, groups, roles, service accounts, permissions that cascade and inherit across systems. Modern enterprises don’t run on one directory. They span on-premises Active Directory, cloud-based Entra ID, identity providers like Okta, and a growing stack of automated tools and AI agents that each carry their own identities and access rights. And all of it is constantly changing.
For years, the main way to understand what happened in an attack was logs. SIEM data, event logs, audit trails. That told you something—roughly where a threat moved, roughly when. I had an opportunity to chat with Jaspreet Singh, CEO and founder of Druva, about this, and he framed it well. The old forensics model was dominated by logs, and logging was the only mechanism to understand lateral movement. But logs only give you part of the picture. They don’t tell you how an attacker got in—what access point or privilege got them through the door—and they don’t tell you what changed downstream as a result. What data was touched. What permissions were quietly modified. What you can actually trust when you go to restore.
Singh also pushed back on the idea that recovery follows a clean, linear sequence. It’s more of a cyclic loop—restore, investigate, segment, investigate again, restore more. You don’t get to check a box and move on. You keep validating as you go.
The NHI Problem Is Getting Worse
If human identity management is messy, non-human identity is a bigger mess.
Service accounts, API tokens, machine credentials—these things vastly outnumber human identities in most enterprise environments. Singh put a number on it: at a company of around 1,200 employees, you might be managing more than 2,000 tokens. And that’s before you account for AI agents, IoT devices, and SaaS integrations, each of which has its own identity and access rights.
Anyone who has spent time on the IT admin side of things recognizes this problem immediately. Someone needs access—it’s urgent—you grant it. Nobody ever comes back to ask you to take it away. That’s been the age-old story behind zombie accounts and dormant credentials. What’s different now is scale. With agentic AI and automated workflows, that same dynamic plays out with tokens instead of user accounts, and at exponential volume. Tokens are frequently over-permissioned, poorly monitored, and just sitting there.
Singh was candid that the industry is still early on this. The concepts for managing it better—just-in-time access, intent-based authorization—exist, but making them work reliably at enterprise scale is still years out.
Where Vendors Are Focusing
The more thoughtful approaches to identity resilience have moved past treating it as a backup problem. The shift is toward modeling identity as something that’s continuously evolving—tracking relationships and behavior over time, not just snapshotting directory objects at a point in time.
Druva just announced that its Identity Resilience platform now covers Okta and Microsoft Active Directory in addition to Microsoft Entra ID—putting the three most common enterprise identity providers under one platform for protection, cyber recovery, and threat detection. The company claims its differentiator is what it calls identity-aware recovery, built on a graph-based intelligence layer called Dru MetaGraph that continuously maps relationships between identities, privileges, data, and activity across an environment.
Singh walked me through a real customer example involving a breach where the attacker was a third-party contractor who gained access to project data. Investigators eventually traced the intrusion to a known binary tool used to move between systems. The key was being able to search backup data for artifacts—which machines had the binary installed, which access privileges were used to move between networks. That kind of searchable, contextual view of the backup environment is what compressed what might have been a week-long investigation into something teams could actually work through efficiently.
“The interesting part about graph is when you expose the MetaGraph, especially with identity, to Claude. Rather than giving it a task, we asked, ‘What could you do with it?’ And it came back and said, ‘I could run regression on permissions. I could look at linkage of changes across systems.’ So building a graph lets AI eventually solve problems which are not comprehensible by a regular analyst.”
The point isn’t just that the data exists—it’s that the data is structured in a way that AI can actually reason over it, rather than requiring a skilled analyst to manually trace connections that span dozens of systems.
IDC research manager Johnny Yu noted in the Druva press release that validating what can be trusted after an incident is a harder problem than restoring objects, and it requires understanding the relationships between identity and data to distinguish legitimate activity from compromise.
What This Means in Practice
A few things stand out from this conversation for security and IT teams thinking about recovery readiness.
Most organizations don’t have a real answer to the question of what their identity environment looked like six months ago. They have some snapshots. What they usually don’t have is the relationship context—who had access to what, how that access changed over time, what systems depended on which identities. Without that, validating a restore point is mostly guesswork.
Identity restoration sequencing matters, but it’s not a straight line. Singh was clear that there’s no universal playbook for what order to do things in—the actual process is iterative. But the general principle holds: you can’t restore downstream applications into an environment where identity isn’t trustworthy yet. You have to sort out identity first, then keep checking your work as you bring everything else back up.
