Why a Resilience Plan Without Identity Recovery Isn't a Resilience Plan
A commentary piece published on Dark Reading by Todd Thiemann, Principal Analyst at Enterprise Strategy Group (Omdia), makes a case that enterprise resilience planning routinely overlooks its own prerequisite: identity infrastructure recovery. The argument is simple but easy to miss in practice — a well-rehearsed plan for restoring data and applications is worthless if the teams responsible can't authenticate into anything because the identity provider itself is down.
Key Points
| Attribute | Value |
|---|---|
| Published by | Dark Reading, October 12, 2026 |
| Author | Todd Thiemann, Principal Analyst, Enterprise Strategy Group (Omdia) |
| Core thesis | Identity resilience is a prerequisite for cyber resilience, not a downstream concern |
| Case study | Maersk / NotPetya (2017) — nearly all Active Directory domain controllers wiped |
| Scale cited | Enterprises running roughly 1,200 applications, often across multiple identity providers |
| Recommendation | Map the identity estate, monitor for configuration drift, and validate recovery against real business priorities |
The Argument
Thiemann grounds the piece in the well-known 2017 NotPetya attack on Maersk, where the destructive malware wiped or rendered unusable nearly all of the shipping giant's Active Directory domain controllers, bringing global port and shipping operations to a halt. Maersk's recovery hinged on a stroke of luck rather than design: a single domain controller in a Ghana office survived, because a power outage had disconnected that office from the network at the moment the malware spread. That one surviving controller became the seed from which Maersk rebuilt its entire global identity environment. Had that office not been offline at exactly the wrong — or right — moment, the argument goes, Maersk's path back to operations would have looked very different.
The piece argues this is no longer a purely on-premises Active Directory problem. As identity infrastructure has shifted from AD to cloud-based identity providers, the complexity of recovery has grown rather than shrunk: modern enterprises typically run on the order of 1,200 applications, frequently split across multiple identity providers — separate stacks for workforce identity and customer-facing (CIAM) identity being a common pattern. That multiplies the dependency graph a recovery team has to reason about under pressure, well beyond what a conventional backup-and-restore runbook typically covers.
Thiemann also points to an organizational gap: identity teams and IT operations / business continuity and disaster recovery (BCDR) teams both care about identity resilience, but tend to approach it from different angles — identity teams thinking in terms of directories, federation, and access policy; BCDR teams thinking in terms of recovery time objectives and failover sequencing. Without deliberate collaboration, each side can assume the other has identity recovery covered.
The piece recommends three concrete practices for closing that gap:
- Map the full identity estate and its dependencies — which applications rely on which identity provider(s), and in what order they'd need to come back online
- Maintain real-time observability into configuration drift — so the environment you'd be recovering into during an incident actually matches what's documented
- Validate recovery processes against business priorities and compliance requirements — rather than testing restoration in the abstract, disconnected from which systems actually need to come back first
Why This Matters
- "We have backups" is not the same as "we can recover." An organization can have flawless data and application backups and still be unable to use them if nobody can log in to the systems needed to restore them.
- Identity sprawl is now the norm, not the exception. Running multiple identity providers across workforce and customer-facing use cases means a single IdP outage no longer has a single, well-understood blast radius — recovery sequencing has to account for all of them.
- Tabletop exercises that skip identity are incomplete. A disaster-recovery test that assumes authentication "just works" in the background is testing a scenario that doesn't match how real outages unfold.
- Lucky breaks aren't a strategy. Maersk's recovery depended on an unrelated power outage sparing one domain controller — a useful war story, but not something any organization should plan around repeating.
- This is a cross-team problem that needs a cross-team owner. Where identity and BCDR functions operate in separate silos with separate assumptions, closing that gap is itself the actionable first step, ahead of any specific tooling investment.