The identity recovery gap: confident on paper, exposed in practice

In 2017, the Maersk NotPetya attack taught us all a lesson that influenced cyber recovery best practice. When NotPetya tore through the company, every copy of its Active Directory — primary and backup — was destroyed. Their recovery did not begin with a clean, tested, isolated restore point. It began with luck: one office in Lagos, Nigeria had been offline long enough to retain an intact copy, unaffected by that attack. A hard drive came back on a chartered jet, giving Maersk a seed from which to rebuild. Basic operations resumed in two weeks. Full recovery took almost a month longer.

That story is epic, and it illustrates that identity is not simply another workload to restore after an incident. It is the control plane that determines who and what can reach any and every other workload. If the identity layer remains compromised, restoring data before restoring identity trust simply recreates the attacker’s path back into that environment.

The challenge is that today’s cyber attacks can move far faster than the incident response capabilities and resources many organizations have. Veeam’s “Identity Under Attack” report and a recent Veeam webinar on accelerating SaaS and cloud recovery both point to a widening confidence gap. In the webinar, Veeam highlighted that 69% of organizations believe they are well prepared for a cyber incident, yet only 10% can recover more than 90% of their data when identity is involved.

Break-ins no longer necessary…

The report’s core thesis is that the identity layer is the root of cyber resilience. Until identity can be returned to a trusted state, no other restoration can be trusted — which makes identity recoverability the lynchpin in any resilience strategy.

A compromised identity can look like normal activity because credentials are valid, access paths are authorized, and systems are functioning as designed. The white paper illustrates this with a familiar modern scenario: a service account authenticates from an unfamiliar location, SharePoint permissions change, an OAuth token begins pulling Salesforce records, and an Azure role assignment opens access to sensitive resources. No malware has to appear. No endpoint has to light up. The attacker is using trust relationships the organization built for legitimate work. It’s just using them way outside their intended scope.

That is why identity recovery differs fundamentally from traditional data recovery. A file restore can be scoped to a folder, a mailbox, or an application. Identity recovery has to account for how single compromised credential may have become three compromised credentials across Active Directory, Entra ID, then Okta, allowing attackers to gain access to Microsoft 365, Salesforce and other applications – establishing persistence and exfiltrating data every step of the way. If a compromised identity changes conditional access policies, creates long-lived tokens, alters service principals, or grants itself access to downstream workloads, recovering only the visible data loss leaves the underlying compromise intact and ready for further attack and compromise.

The webinar describes three operational principles for recovery in such an environment. First, identity must be verified clean before anything downstream is restored. Second, identity recovery must be precise. A blanket rollback may remove malicious changes, but it can also wipe out legitimate work, break integrations, and force lengthy reconfiguration. Teams need to identify exactly what changed and surgically restore affected objects, policies, users, applications, and permissions. Third, that same precision must extend across every platform the compromised identity touched, so that restored workloads and restored identity state are consistent with each other — no orphaned references, no reintroduced attacker artifacts — and every credential, token, and trust relationship in the recovered environment is known to be valid.

This last point is easy to underestimate until an incident is underway. Restoring platforms independently without reconciling the identity relationships that connect them can create drift. For example, you may have technically restored systems that no longer agree on permissions, owners, tokens, or object relationships. During a crisis, if you’re restoring identity workloads using a variety of backup and recovery platforms, coordination is labored, resulting in slower decision making, increased operator confusion, and a greater chance of human error at precisely the moment teams need speed and confidence.

Relying on multiple tools compounds identity drift

Fragmented tools make that problem worse. In many organizations, those responsible for backup and recovery are divided by the platforms and workloads they are responsible for protecting, and each of those backup teams may be using one or more different backup and recovery platforms to do their jobs. Identity systems often fall into the gap between those teams — AD belongs to the directory/infrastructure team, Entra ID to the M365 or cloud team, Okta to the security or IAM team — so identity recovery frequently has no single owner and no consistent tooling at all.

Each team may see part of an incident, and there is also a gap in contextual awareness between these teams and the Security Operations team. No one I able to see the full identity-to-data trail. Thus, Veeam’s webinar argues for consolidation not as a convenience, but as a requirement to achieve intelligence resilience operations. It also suggests that all teams could gain shared contextual awareness by leveraging a data security posture management knowledge graph to close that visibility gap between the identities and systems known to be compromised and the associated data that was affected. Indeed, a common operating model can help teams compare production and backup states, identify clean restore points, and coordinate recovery across identity and associated workloads.

It also challenges a persistent misconception: that native platform controls deliver adequate recoverability. Entra ID recycle-bin and retention capabilities may help with certain object deletions, but they do not constitute a complete recovery strategy. As the webinar notes, retention windows may be limited — often scoped only for 30 or 90 days — and some policies may have no meaningful retention at all. The shared responsibility model matters here. Cloud providers do operate the platform. But customers remain responsible for protecting and recovering their identity configuration, permissions, policies, and data relationships.

It’s time to stop looking at MTTR, RPO, and RTO as backup-team scorecards, and start approaching those metrics as C-Suite and board-level issues. How quickly can an organization restore trusted access across every system touched? How much identity and workload drift can it tolerate? What’s the maximum acceptable downtime or data loss when authentication, authorization, and business data are all intertwined?

Merging IT recovery and security operations

Answering those questions requires closer collaboration between IT recovery and security operations. The increased adoption of AI internally and by threat actors has led to CISOs being held accountable for their organization’s ability to recover quickly. So, there should be a vested interest in closer collaboration between these teams. In addition, SecOps and forensics teams benefit from backup context, which preserves states over time, so they can understand what changed and when. Recovery teams need clear communication with SecOps to avoid restoring compromised states. Establishing a shared view of the environment before the incident, during the dwell window, and at the selected recovery point would improve response and recovery times. Over time, a shared view supports more automated, orchestrated restoration. But the first step is simpler: bring recovery teams into incident response planning early, and test recovery as part of incident response exercises, not afterwards.

Non-human identities make convergence even more urgent. Service accounts, API keys, OAuth tokens, service principals, and automation credentials now vastly outnumber human identities. The webinar cites an average ratio of roughly 100 non-human identities for every human identity, with some organizations reaching 500:1. These identities often have no owner, no behavioral baseline, and no human user to report suspicious activity. Yet they may hold privileged access across critical platforms.

Recovery and prevention go hand in hand

The throughline is clear: identity compromise is as much a recovery problem as a prevention problem. Prevention and detection still matter, but when attackers can move from initial access to lateral movement in seconds, organizations need to improve the speed with which they can restore identity trust and every dependent workload without reintroducing errors or gaps.

No organization can prevent every identity compromise — but it can decide, in advance, how well it will respond. That means streamlining your ability to pinpoint and reverse exactly what changed, improving sequenced restoration across every platform a compromised identity touched, coordinating with Security Operations and other stakeholders from a shared, identity-first view of the incident. Organizations that build and rehearse those capabilities before an attack will dramatically improve recovery times. Those that stick with the status quo may find their recovery times deteriorate as AI-orchestrated autonomous attacks become more common. To explore the full data set, download Veeam's “Identity Under Attack” report and learn more about Veeam's approach to identity resilience and recovery.

About Veeam

Veeam, the Data and AI Trust Company, helps organizations protect, recover, and govern their data wherever it resides. Veeam delivers data resilience, security, and recovery capabilities designed to help businesses keep operations running, recover quickly from cyber incidents, and build trusted foundations for AI and digital transformation.