TL;DR: When identity systems fail, users cannot authenticate, applications cannot start, VPN access breaks, and broader business recovery stalls, according to Semperis. The message is clear: identity recovery is not an IT back-end task, but the first operational prerequisite for restoring the minimum viable company.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Semperis's blog post: Identity recovery underpins the Minimum Viable Company, and business recovery cannot begin until authentication services are restored.
Why it matters: It matters because IAM, PAM, and infrastructure teams need a recovery plan that treats identity as the first operational dependency, not a later restoration step.
Context
Identity recovery is the ability to restore authentication, authorization, and directory services to a reliable, secure state after an outage or cyberattack. In this article, that capability is presented as the foundation of the Minimum Viable Company because nearly every business service depends on identity before it can operate.
The article frames a simple but operationally important gap: many recovery plans still treat identity as a supporting system rather than the control plane for everything else. For IAM and infrastructure teams, that changes the order of recovery, the recovery architecture, and the people responsible for getting the business back online.
Semperis uses a fictional enterprise to show that identity recovery is only useful if it works during a real crisis, not just in a lab. The planning challenge is therefore not only technical restoration, but also governance, sequencing, and fault tolerance across the recovery path.
Key questions
Q: How should organisations design identity recovery for cyber incident response?
A: Start with the identity layer, not the application layer. Define the minimum set of services needed to authenticate users, support administration, and preserve forensic integrity, then prove you can restore those services independently of the compromised production environment. That sequence gives the rest of the business a trustworthy base to return online.
Q: Why does identity failure halt business recovery so quickly?
A: Because modern applications, admin workflows, VPN access, and even many recovery tasks require authentication before they can run. If identity is down, the organisation may still have infrastructure, but it cannot safely use it.
Q: What are the signs that an identity recovery plan is too fragile?
A: A plan is fragile when it assumes one restore path, depends on the original hardware, or cannot recover if a single domain controller fails. Those conditions make recovery stall exactly when the environment is most degraded.
Q: What should teams do when identity recovery must support a wider business restart?
A: Sequence recovery so identity comes online first, then the systems that authenticate through it, and only then the remaining applications and regional services. That order reduces the chance of restoring business services onto an unusable control plane.
Technical breakdown
Why identity is the control plane for business recovery
Identity services sit upstream of almost every other enterprise dependency. If users cannot authenticate, workloads cannot start, admin access is blocked, and downstream systems remain unavailable even when the infrastructure itself is still standing. In hybrid environments, that dependency usually begins with on-premises directory services and extends into cloud identity and SaaS access, which is why recovery has to start at the identity layer. The operational lesson is that restoration order matters more than raw infrastructure capacity.
Practical implication: Treat identity services as the first recovery domain, not one application among many.
Why bare metal recovery can reintroduce compromise
Traditional restore methods such as system state or bare metal recovery can bring back the same compromise you are trying to escape. If the underlying operating system or backup image still contains persistence, malware, or unsafe state, the recovery process becomes a reinfection path rather than a remediation step. A safer pattern is to rebuild identity infrastructure on clean systems and reintroduce services in stages, so the restored environment is not structurally dependent on the infected one.
Practical implication: Rebuild critical identity servers on clean operating systems rather than trusting old system state images.
How staged identity recovery supports the wider environment
A staged recovery model restores the minimum identity core first, then reintroduces additional domain controllers, regional services, and dependent workloads as stability returns. That approach assumes fault tolerance, multiple recovery paths, and clear ownership during each phase. It also reflects a practical reality: the whole environment rarely comes back at once, so identity recovery has to keep authentication available while the broader estate is still in transition.
Practical implication: Design recovery phases so authentication resumes before less critical systems are brought back online.
Threat narrative
Attacker objective: The attacker sought to disrupt business operations broadly by crippling the identity services that everything else depended on.
- Entry occurred through a destructive ransomware attack that disabled large parts of the IT environment and interrupted core business services.
- Credential and access services became unavailable when identity infrastructure failed, preventing users, applications, and administrators from authenticating normally.
- Operational impact spread across the enterprise as shop-floor automation stopped, employees could not log in, and dependent systems went offline.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity recovery is not a back-end support function, it is the operating condition for business continuity. The article is right to frame identity as the foundation of the Minimum Viable Company because nothing else can reliably recover while authentication is down. That is true across human access, machine access, and privileged recovery paths. The practitioner implication is that resilience architecture should start with identity service restoration order, not application lists.
Recovery plans that depend on the original operating environment create avoidable restoration risk. System state and bare metal recovery can preserve the very persistence and compromise that made the environment fail. That makes the recovery path part of the attack surface, not just the remediation process. The implication is that clean rebuild capability is a core resilience control, not an optional enhancement.
Fault tolerance in identity recovery is a governance requirement, not merely an infrastructure preference. The article’s emphasis on multiple domain controllers, isolated recovery capability, and staged reintroduction shows that single-path recovery is too fragile for a real crisis. A resilient programme has to assume that one recovery step may fail and that the identity plane still needs to stay available. The implication is that resilience testing must measure continuity under degraded conditions.
People and decision rights are part of identity recovery architecture. The RACI discussion matters because recovery fails when responsibility is ambiguous under stress. Identity recovery spans technical operators, incident responders, business owners, and executive decision makers, so the recovery model has to define who acts, who approves, and who is informed. The practitioner implication is to test governance as rigorously as technical restore procedures.
Identity recovery creates the floor for staged enterprise recovery, not the ceiling. Restoring authentication first allows applications, regional services, and business functions to return in a controlled sequence. That sequencing is what converts survival into stability. The practitioner implication is to map the wider recovery programme directly to the identity recovery baseline, rather than treating identity as one more dependency among many.
What this signals
Identity recovery planning is now a resilience design problem, not a restore ticket. Teams that still treat directory recovery as an infrastructure-only issue will continue to discover that business restart is blocked long before application recovery begins. The programme implication is to make identity the first recovery dependency in tabletop exercises, architecture reviews, and incident runbooks.
Minimum viable company thinking should reshape recovery priorities across the whole estate. Once the business defines the smallest operational state it can survive on, identity services become the gating control for every later phase. That means recovery sequencing, not just backup coverage, is what determines whether the organisation can move from outage to operating mode.
For practitioners
- Define the Minimum Viable Company around identity dependencies Map which authentication, directory, and privileged access services must recover before any other business function can safely return.
- Build isolated recovery capability for identity services Keep recovery tooling and restore paths independent of production infrastructure so identity can be rebuilt even when the main environment is compromised.
- Prefer clean rebuilds over stateful restore paths Recreate domain controllers and core identity components on clean operating systems instead of restoring system state or bare metal images from a compromised estate.
- Test staged restoration under degraded conditions Exercise the sequence that brings identity back first, then regional services, then downstream workloads, so the organisation can prove the order actually works.
- Assign explicit recovery ownership and approvals Document who is responsible, accountable, consulted, and informed for each recovery step so the team can act without delay during a crisis.
Key takeaways
- Identity failure can stop authentication, administration, and application startup before the wider infrastructure is even fully assessed.
- The article shows that recovery succeeds when identity is restored first, then expanded in stages to support the broader environment.
- A resilient plan needs isolated recovery capability, clean rebuilds, and explicit ownership for the identity layer before business services return.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Recovery planning here is about restoring identity safely after compromise and avoiding persistence in the old estate. |
| NHI-08 — Environment Isolation | The article stresses an isolated recovery environment to keep recovery independent of production compromise. | |
| Recommendation — Rebuild identity services so compromised state is not carried forward into recovery. Use isolated recovery environments so identity can be restored without relying on the breached production stack. | ||
| NIST SP 800-53 Rev 5 | CP-10 — System Recovery and Reconstitution | The article is fundamentally about restoring critical identity services after disruption. |
| Recommendation — Plan identity reconstitution first and validate it before restoring dependent services. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Executed | The piece centers on executing a recovery plan that brings the business back online in stages. |
| Recommendation — Exercise and refine recovery plans so identity restoration happens before business resumption. | ||
| MITRE ATT&CK | TA0040 — Impact | The ransomware incident caused operational disruption across authentication and business services. |
| Recommendation — Map ransomware-driven disruption to TA0040 and prioritize identity services that restore business operation fastest. | ||
Key terms
- Minimum Viable Company: Minimum Viable Company is the smallest level of identity and application capacity needed for the business to operate after a recovery event. It shifts the recovery question from whether a system is online to whether enough trusted access exists for critical services to function.
- Identity Recovery: Identity recovery is the process of restoring identity systems to a trusted state after compromise. It includes containment, forensic validation, removal of persistence, and confirmation that access controls and directory relationships no longer expose the environment.
- Isolated Recovery Environment: A separate recovery workspace used to rebuild critical services away from the compromised production environment. It reduces reinfection risk by keeping restoration activities and trust validation outside the attack surface that was affected during the incident.
- Staged recovery: A phased restoration method that returns critical systems first and reintroduces additional components later. For identity environments, staged recovery reduces restoration risk by allowing teams to validate trust, access, and dependencies before the full directory estate is placed back into service.
Deepen your knowledge
NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org