TL;DR: 83% of successful attacks compromised identity infrastructure, while 76% of victims needed more than a day to return to normal operations and 52% of attacks landed on weekends or holidays, according to Semperis’ 2025 ransomware research. Recovery integrity, not just prevention, has become the board-level control that decides outage duration and business continuity.
At a glance
What this is: This is a Semperis analysis arguing that ransomware resilience depends on restoring identity systems to a trusted state, not just blocking initial compromise.
Why it matters: It matters because IAM, PAM, and NHI teams need recovery objectives, testing, and coverage plans that treat identity infrastructure as a business continuity dependency.
By the numbers:
- 83% of successful ransomware attacks compromised identity infrastructure.
- 76% of ransomware victims needed far more than a day to return to normal operations.
- 52% of ransomware attacks hit on a weekend or holiday.
Context
Ransomware becomes a business outage when attackers reach identity infrastructure, because identity is the control plane every application, user, and service depends on. In this article, Semperis argues that recovery planning for Active Directory and Entra ID should sit alongside prevention, not after it.
The core governance gap is not whether organisations have plans on paper. It is whether they can return identity systems to a trusted state fast enough, during the staffing gaps and operational distractions that ransomware crews deliberately exploit.
Key questions
Q: What breaks when identity visibility is missing during a ransomware attack?
A: Containment becomes guesswork. Security teams cannot tell which accounts are active, what they can reach, or which privileged paths they unlock, so they often default to broad shutdowns or partial revocation that leaves access open elsewhere. The result is longer outages, more manual work, and higher risk that attackers keep moving while teams investigate.
Q: Why does ransomware recovery need identity governance, not just disaster recovery?
A: Because identity is the first control plane attackers target and the dependency every other system uses. Disaster recovery can restart infrastructure, but identity governance determines whether access, privilege, and trust have actually been restored to a defensible state. Without that layer, organisations may recover availability while leaving the conditions for reinfection or continued abuse in place.
Q: What are the signs that an identity recovery programme is failing?
A: Long restore times, unclear ownership, untested AD or Entra ID procedures, and no validated path back to a trusted state are all warning signs. If teams can describe recovery in theory but cannot prove clean-state validation, the programme is not ready for ransomware conditions. Fragmented coordination and weak out-of-band communication make the failure worse under pressure.
Q: How should boards evaluate ransomware readiness for identity systems?
A: Boards should ask for identity-specific RTO and RPO targets, evidence of recovery testing, and proof that restoration returns the directory to a trusted state. They should also look for low-coverage response plans for weekends, holidays, and major corporate events, because those are when attackers are most likely to strike and response speed matters most.
Technical breakdown
Why identity infrastructure becomes the outage point
Active Directory and Entra ID are not just directories. They are authentication, authorization, and policy dependencies for access to applications, workloads, and operational systems. When an attacker compromises identity infrastructure, the issue is not limited to credential theft. Trust collapses across dependent systems because access decisions, group membership, and administrative control all sit in the same plane. That is why identity recovery is a distinct discipline from server recovery or data restore. You can bring infrastructure back online and still remain effectively out of business if identity is not restored to a trustworthy state.
Practical implication: Treat identity recovery as a separate restoration stream with its own runbook, owners, and test criteria.
Why clean state recovery matters more than simple restore
A restore that brings back corrupted, altered, or partially remediated identity data does not solve ransomware risk. Clean state recovery means returning directories, privilege assignments, and trust relationships to a state the organisation can defend as trustworthy, not merely operational. That distinction matters because ransomware response often leaves persistence mechanisms, stale admin paths, or unvalidated changes behind. In identity environments, speed without integrity is dangerous: if the recovered state is not trusted, downstream systems inherit the compromise or the uncertainty. Recovery therefore has to include verification, not only restoration.
Practical implication: Validate identity integrity after restore, including privileged group membership, trust relationships, and administrative access paths.
How weekend and holiday coverage gaps change the threat window
The article links attack timing to weekends, holidays, and major corporate events because those periods reduce coverage, slow decision-making, and expand dwell time before containment. That is not only a SOC staffing issue. It is an identity governance issue, because recovery authority, escalation paths, and out-of-band communications must still function when normal teams are absent. If the organisation cannot convene the right decision-makers quickly, the recovery timeline extends even when technical tooling exists. Ransomware crews exploit that delay as part of the attack chain.
Practical implication: Pre-authorize recovery decisions and ensure out-of-band escalation coverage for low-staff periods and major corporate events.
Threat narrative
Attacker objective: The attacker seeks to convert identity compromise into prolonged business disruption by delaying trustworthy recovery.
- Entry begins when ransomware actors compromise identity infrastructure such as Active Directory or Entra ID, turning the identity plane into the initial foothold and control target.
- Escalation follows when attackers exploit identity trust, privileged access, or recovery gaps to keep control even after defenders attempt remediation.
- Impact occurs when the organisation cannot restore identity to a trusted state quickly, extending outage duration across applications, operations, and business processes.
NHI Mgmt Group analysis
Identity recovery is now a business continuity control, not a backup exercise. When Active Directory or Entra ID fails, the organisation does not merely lose authentication services. It loses the ability to re-establish trust across the systems that depend on identity for access decisions. That makes clean state recovery a board-level resilience metric, not a narrow infrastructure task. The implication is that recovery planning must be owned as part of identity governance, not left to disaster recovery alone.
Recovery integrity is the control gap ransomware teams exploit. This article shows that many organisations can imagine a restore, but far fewer can prove that the restored identity state is trustworthy. That gap is what turns technical remediation into prolonged outage. In practical terms, the decisive question is not whether identity can come back online, but whether the recovered state can be defended as clean enough for business resumption.
Clean state identity recovery is the named concept this market now needs. It captures the shift from restoring availability to restoring defensible trust in identity infrastructure. That concept matters because attack success, recovery speed, and business continuity are now tied together in the same control problem. Practitioners should treat clean state identity recovery as a distinct governance domain with measurable recovery objectives and validation steps.
Weekend and holiday exposure is a governance problem, not only a staffing problem. The article's timing data shows that attackers align with low-coverage periods and material corporate events because those are moments when escalation slows and decisions fragment. That means crisis authority, out-of-band coordination, and identity recovery ownership must survive abnormal operating conditions. The implication is straightforward: identity resilience fails when governance only works during business hours.
The security programme assumption that 'we can restore later' no longer holds. That assumption was designed for environments where identity recovery could follow containment without materially changing the outage curve. It fails when ransomware turns identity itself into the business dependency, because delay in restoring trust becomes the outage. The implication is that recovery sequencing must move ahead of many traditional remediation instincts.
What this signals
Clean state identity recovery: Recovery maturity should now be judged by whether the directory can be returned to a trusted state, not merely restarted. That changes the programme conversation from resilience as uptime to resilience as verified trust, which is a better fit for ransomware conditions than simple restore metrics.
The practical programme shift is to treat identity outage as a business continuity event with its own governance, escalation, and validation steps. Organisations that still bury identity recovery inside generic disaster recovery will continue to discover that technical availability and operational trust are not the same thing.
For practitioners
- Define clean state identity recovery Document what it means for Active Directory and Entra ID to be trusted again, including validation of privileged groups, trusts, and administrative access paths.
- Test identity recovery separately from infrastructure recovery Run recovery exercises that restore identity services as a distinct workstream and measure whether downstream applications can authenticate against a validated identity state.
- Set identity RTO and RPO targets Make identity recovery time objective and recovery point objective board-visible metrics, and align them to the downtime impact of identity failure.
- Pre-authorize low-coverage period response Create weekend, holiday, and material-event escalation paths with named decision thresholds, out-of-band communications, and clear recovery authority.
- Measure posture before the next incident Use a current identity posture baseline to track remediation progress and prove whether recovery gaps are shrinking quarter over quarter.
Key takeaways
- Ransomware turns identity infrastructure into the outage point because every dependent system inherits its trust state from directory services.
- The hardest part of recovery is not restart speed but proving that the restored identity environment is clean and trustworthy.
- Boards should insist on identity-specific recovery objectives, tested procedures, and low-coverage response plans before the next incident.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Identity recovery gaps often leave stale accounts and trust paths in place after ransomware. |
| NHI-05 — Overprivileged NHI | The article stresses privileged identity paths as a ransomware recovery bottleneck. | |
| Recommendation — Verify that recovery procedures remove stale identity state before restoring access. Review privileged identity paths and reduce excess access before recovery testing. | ||
| NIST CSF 2.0 | RC.RP — Recovery Planning | The article is centered on restoring identity services in a trustworthy state after an incident. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity recovery must restore permissions and authorizations to a defensible baseline. | |
| Recommendation — Build and test recovery plans that return identity systems to a trusted state. Validate entitlements and authorizations after recovery before resuming business access. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article describes ransomware as a path from identity compromise to business outage. |
| Recommendation — Map ransomware recovery gaps to credential access and impact tactics in detection planning. | ||
Key terms
- Clean Identity Recovery: Clean identity recovery means restoring directory and identity services to a verified trustworthy state after compromise. The key distinction is between bringing systems back online and restoring confidence in authentication, authorization, and administrative control without reusing tainted changes or stale trust paths.
- 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.
- Trusted State: An identity environment that has been validated as free from known malicious changes, stale privilege, and hidden persistence. In ransomware recovery, trust is the condition that makes restored access safe to use, which is why verification matters as much as availability.
- Recovery Integrity: The degree to which a restored environment can be trusted to operate without carrying forward attacker modifications or hidden access. It combines technical restoration with validation of trust relationships, privilege state, and synchronisation, which is why it matters more than simple uptime.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org