Identity is Infrastructure: Why IAM Must Be Recoverable

Identity is no longer background plumbing. It's the control plane of the modern enterprise: the system that decides who can do what, where, and under what conditions. When identity is compromised or unavailable, applications don't fail gracefully, recovery stalls, and business operations stop entirely.

We've treated Active Directory, Entra ID, and Okta as important but somehow separate from the conversation about cyber resilience. That framing needs to change. Identity recovery isn't one workstream among many. In a serious incident, it's the prerequisite for everything else.

Three incidents make that concrete: the Maersk NotPetya attack in 2017, the Conti ransomware playbook exposed in 2022, and the Stryker attack in March 2026. They span nearly a decade and different attack methods, but they share the same mechanism of failure and the same recovery constraint:  which makes them worth examining closely.

Maersk: The lesson the industry learned the hard way

The Maersk NotPetya attack in June 2017 is the canonical identity recovery story. Not because it was unusual, but because it was brutally clear about the mechanism of failure.

When NotPetya hit Maersk, the malware itself wasn't the primary obstacle to recovery. The loss of Active Directory services was. Employees across the globe couldn't log in. Ports, terminals, and logistics systems couldn't authenticate users or applications to move cargo. Revenue systems went offline. And the IT teams trying to coordinate recovery couldn't function reliably without identity either.

Business restart was contingent entirely on restoring AD first. Not one priority among many. The prerequisite.

They got lucky. A single domain controller in a remote Ghana office was offline during a power outage when the malware ran. That accidental, unconnected DC was the only surviving copy of the company's directory. Bandwidth in Ghana was too slow to transmit hundreds of gigabytes over the network, so a staffer flew from Ghana to Nigeria to hand off the hard drive in person, and it was then flown to London. Maersk recovered Active Directory in nine days. Only after identity was reestablished did the broader enterprise recovery accelerate.

Two lessons from that story still don't get internalized. First: replication is not the same as recoverability. Every synchronized replica was destroyed along with production. Second: redundancy is meaningless if all copies share the same trust boundary and replication topology.

The industry learned this publicly in 2017. Attacks since then have confirmed it repeatedly.

The Conti blueprint and why it still matters

When Conti's internal documentation leaked in February 2022, it gave defenders an unusually detailed look at how a sophisticated ransomware group systematically targeted Active Directory as the mechanism for enterprise-wide compromise.

The playbook runs in four phases:

• Initial access and credential harvesting: A phishing email delivers a Cobalt Strike beacon. Local credentials are extracted from memory using Mimikatz.
• Lateral movement and privilege escalation: Harvested credentials enable movement via RDP and SMB. The attacker identifies a domain-joined server with a Domain Admin session in memory, extracts those credentials, and now controls the AD environment.
• AD compromise and persistence: A DCSync attack extracts the full NTDS.DIT database: every password hash in the domain, the KRBTGT hash, and all service account credentials. The attacker forges a Golden Ticket granting unrestricted access to every resource in the forest. Hidden admin accounts are created, AdminSDHolder ACLs modified, and additional C2 implants installed on domain controllers.
• Ransomware deployment via GPO: A Group Policy Object deploys ransomware as a scheduled task across all domain-joined systems. It replicates to every domain controller within the next AD replication cycle. Within hours, every domain-joined workstation and server is encrypted. AD goes offline. The organization is completely paralyzed.

The recovery requirement isn't "restore some servers." It's recover Active Directory into an isolated recovery environment, validate it's free of attacker persistence, re-establish authority, then rebuild. The ordering matters as much as the capability.

Identity as the blast radius: Stryker 2026

If Maersk and Conti feel like a prior era, the March 2026 Stryker incident removes that comfort.

Threat actors compromised a privileged Entra ID admin account and used Microsoft Intune (the same tool IT teams rely on to manage endpoints) to remotely wipe more than 80,000 devices across 79 countries. Laptops, servers, personal phones enrolled through Stryker's BYOD program: all of them. No ransomware demand. No novel malware. No SMB exploit or zero-day.

The damage was delivered entirely through abusing a trusted identity and device management control plane.

This is what the modern attack pattern looks like: attackers don't break in, they log in. A single compromised admin account with Intune authority delivered enterprise-scale destruction through native platform features. The tooling that makes IT efficient at scale makes it destructive at scale when authority is in the wrong hands.

Stryker's challenge after the attack wasn't rebuilding endpoints. It was re-establishing confidence in identity authority before operations could safely resume. That's the thread connecting all three incidents. Recovery is about restoring trust, not just systems.

The three practice areas and where identity fits

Cyber resilience programs are typically framed around three practice areas: reduce the attack surface, detect and respond to threats, and recover. Identity belongs explicitly in all three, not as an afterthought, but as a first-class workload.

Reducing the attack surface means treating identity as tier-0 infrastructure. MFA, RBAC, Conditional Access policies, and privileged access management are attack surface controls, not compliance checkboxes. Stolen credentials remain the fastest path into an environment. A decade ago, secure BIOS and firmware provenance weren't part of the conversation; identity hygiene follows the same arc: the controls that feel optional today become the gap an attacker exploits tomorrow.

Detection and response requires visibility into identity abuse, not just malware. Lateral movement using legitimate credentials, DCSync attacks, Golden Ticket creation: these don't look like malware in traditional monitoring. They look like administrative activity. Detection has to account for behavioral anomalies in identity and access patterns, not just known-bad indicators.

Recovery is where most identity programs have the most significant gaps. Booting servers quickly doesn't accomplish much if identity is untrusted or the team can't validate what's clean. The fastest path back to minimum viable business goes through identity, not around it.

AD forest recovery: more complex than most teams expect

The Microsoft Active Directory Forest Recovery process is well-documented. It's also more complex in practice than most organizations discover until they're in an incident.

The prescribed approach: assume full forest compromise, recover AD in isolation first, restore a single authoritative writable domain controller per domain, validate core forest services (DNS, Global Catalog, FSMO roles, replication health), then scale out. Reset credentials and trust boundaries as part of recovery, not after. The entire process must be documented and tested before an incident occurs.

That last point is the trap. Forest recovery is complex, manual, and time-consuming. Your first forest recovery should not happen during an active breach.

There are well-understood failure modes that have nothing to do with bad backups and everything to do with AD complexity:

• USN rollback and InvocationID mismatch: Automated restore completes, but AD DS fails to start. Event logs show database signature conflicts. Proceeding risks replication divergence, lingering objects, and irreversible directory corruption. Resolution may require manual metadata cleanup, authoritative versus non-authoritative restore decisions, and AD DS database repair guidance from Microsoft.
• DFSR SYSVOL synchronization failure: SYSVOL restore completes but DFSR reports initial sync never completes, stuck in "journal wrap" or "initial sync" indefinitely. GPOs stop applying. The organization has a false sense of recovery success while security posture is inconsistent across domain controllers.

Both scenarios require stopping automation, engaging Microsoft support with the exact step and specific error, resolving the condition, and resuming. The best identity recovery tools combine well-tested automation with close alignment to the Microsoft process. Not just automation for the clean-path scenario, but the ability to pause at deterministic steps, capture the state needed to engage support, and resume without starting over. Recovery tooling that only handles the easy cases doesn't hold up when it matters.

Hybrid identity: AD, Entra ID and the sync boundary problem

Most enterprise environments aren't pure on-premises AD. They're hybrid: AD synchronized to Entra ID, with SaaS identity providers like Okta in the middle.

Microsoft is explicit about the shared responsibility model for Entra ID. Service availability is Microsoft's responsibility; tenant configuration integrity is the customer's. Modern identity attacks increasingly target the configuration layer: Conditional Access policy changes, privileged role assignments, OAuth app permissions, service principal modifications, token manipulation. These changes often persist quietly and are difficult to reverse at scale. A 99.99% availability SLA doesn't help when the configuration driving access decisions has been compromised.

Entra recovery is also more than users and groups. Access decisions depend on device identities, Intune compliance state, Conditional Access dependencies, and custom security attributes. Restoring user objects without restoring the policy environment that governs their access may still leave the business unable to operate safely.

The more significant technical challenge in hybrid recovery is the sync boundary.

Directory synchronization is built to automate steady-state identity changes. It is not built to protect recovery integrity. In a real incident, AD and Entra are rarely recovered at the same moment or to the same point in time. If synchronization stays active during recovery, it can overwrite a clean restore with stale, compromised, or incomplete identity data before validation is complete. The failure patterns are consistent: a clean restore in one directory gets overwritten by the other; deletes, attribute changes, or privilege assignments replay unexpectedly; recovery appears successful while trust is silently broken.

In recovery, automation removes control. Sync must be explicitly managed: paused, isolated, deliberately resumed only after authority is re-established and validated. That's not the default behavior in most tools. It requires intentional design.

What safe recovery across AD and Entra actually requires: explicit sync control, clear authority boundaries (knowing what's authoritative for users, groups, privileges, and cloud-only attributes in each directory), sequenced recovery (restore, inspect, confirm trust, then propagate), isolation of failure domains so errors in one plane don't cascade into the other, and operator-visible decision points at the transitions where teams are tempted to just let it run.

Okta as tier-0 infrastructure

Okta has become a primary identity control plane in a significant number of enterprise environments. When Okta fails or is compromised, downstream applications fail regardless of whether everything else is healthy.

The shared responsibility model applies here as well. Okta ensures platform availability, not tenant-level data or configuration recovery. Without external protection, recovery from Okta incidents is manual, time-consuming, and largely absent from most recovery plans.

Prior Okta incidents reinforced a point that still doesn't get enough attention: even when infrastructure is online and available, the organization may need to audit and reconstruct identity state from scratch.

For most enterprises today, functional identity means AD, Entra ID, and Okta operating as one system, during normal operations and during recovery. Recovery plans that address only AD are not addressing hybrid identity recovery. They're addressing one component of a multi-plane problem.

The planning problem no one talks about

Tools and technical requirements consume most of the conversation around identity recovery. The organizational planning problem is where recovery programs actually fall apart.

Identity teams are very good at operating identity: provisioning users, maintaining roles, managing access requests, responding to MIM or Entra issues. That's what they're organized and staffed to do. Crisis recovery is a different activity entirely, and identity recovery is not a single-team problem.

When identity authority is lost or untrusted, recovery immediately crosses boundaries: security, infrastructure, application owners, legal, compliance, and often executive leadership. That's where friction concentrates, because decision rights are rarely defined in advance.

Ask yourself three questions:

• Who has the authority to declare identity untrusted?
• Who can approve suspending AD-Entra synchronization?
• Who decides when identity is clean enough to let applications back in?

Most organizations don't have clear answers. Most runbooks don't address these questions. They were written for systems recovery, not authority recovery.

Hybrid identity makes this worse. Active Directory, Entra ID, and SaaS identity systems act like one organism during both attack and recovery, but organizations plan for them separately. Recovery sequencing decisions are frequently undocumented. Sync boundaries are overlooked. The implications of "restore AD first, then let sync catch up" aren't captured anywhere.

Automation will also stop at some point during a real recovery. USN rollback, SYSVOL failures, sync conflicts: these conditions require human judgment. Pause, roll back, or proceed? If teams haven't rehearsed those decision points, confidence disappears at exactly the moment it matters most.

The hard part isn't bringing identity services online. The hard part is restoring trust. Because "the directory is online" and "the directory is trustworthy" are not the same thing. Business restart requires confidence in identity authority, not just availability of identity infrastructure.

Good planning accepts this upfront. It defines ownership. It sequences recovery decisions. It names the authority boundaries. And it rehearses failure, not just the clean path.

What good looks like

Treating identity recovery as a first-class program means three concrete shifts.

The first is protecting identity as tier-0. The same disciplines applied to crown-jewel data (isolated backups, tested restore procedures, clean recovery environments) apply equally to identity infrastructure. Forest recovery must be documented and exercised before an incident, not invented during one. Break-glass credentials must be pre-staged in a protected recovery envelope, because the vault can't be accessed until AD is functional again.

The second is detecting identity abuse, not just malware. Behavioral visibility into credential misuse, privilege escalation patterns, DCSync activity, and Conditional Access policy modifications enables early detection of identity-centric attacks. Both the Conti playbook and the Stryker incident involved activity that looked entirely legitimate to systems without identity-specific detection.

The third is recovering deliberately: isolate, validate, resume. Restore AD in isolation before re-enabling sync. Validate identity state before propagating it to dependent systems. Confirm trust before resuming operations. Restoring fast and letting automation catch up is how clean recoveries become re-infected environments.

Identity recovery is the gating function for everything that comes after an incident. WWT's approach starts with understanding the current state across AD, Entra ID, and SaaS identity providers, then building recovery programs with the sequencing, isolation, and governance controls that make recovery something teams have practiced, not something they work out under fire.