Why do organisations with identity recovery plans still end up paying ransomware demands?

Why This Happens Even With Recovery Plans

Ransomware payments often follow identity failure, not just data loss. If attackers disable directory services, tamper with trust relationships, or encrypt the systems that issue access, a backup is not the same thing as a working recovery. The organisation may technically possess copies of identity data but still lack a fast, trustworthy way to re-establish authentication, authorisation, and administrative control.

This is why identity recovery has to be treated as a business continuity problem, not a narrow infrastructure task. The Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which matters because attackers often use those identities to move laterally long before encryption starts. Standards-based guidance such as the NIST Cybersecurity Framework 2.0 and current threat reporting from ENISA Threat Landscape both point to recovery as a resilience discipline, not a backup checkbox. In practice, many security teams discover their recovery gap only after domain admins, directory sync, or identity trust stores have already been taken offline.

What a Usable Identity Recovery Path Actually Requires

A workable plan restores the identity layer in the right order, with the right trust boundaries, and with enough isolation to avoid reintroducing attacker persistence. That usually means more than restoring a controller image. Teams need clean source-of-truth data, known-good administrative credentials, protected break-glass access, and a way to validate that group policy, federation, certificates, and privileged accounts are not already compromised.

The practical sequence is usually:

• Establish isolated recovery authority outside the compromised directory or tenant.
• Validate backup integrity and time-of-capture against known compromise indicators.
• Rebuild authentication services before reconnecting endpoints and workloads.
• Reset privileged credentials, service accounts, API keys, and federation trust objects.
• Confirm that access policies, MFA dependencies, and sync jobs are not reintroducing the attacker.

NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and only 5.7% have full visibility into service accounts, which helps explain why identity recovery frequently stalls on the very accounts attackers rely on most. The 52 NHI Breaches Analysis and the Cisco Active Directory credentials breach both illustrate a recurring pattern: once identity trust is poisoned, restoring systems without re-establishing identity integrity just recreates the compromise. These controls tend to break down when the directory, the backup platform, and the privileged access stack all share the same authentication plane because the blast radius becomes circular.

Where Recovery Plans Usually Fail in Real Environments

Tighter recovery controls often increase operational overhead, requiring organisations to balance rapid restoration against the risk of restoring attacker access. The hard tradeoff is speed versus assurance, and there is no universal standard for this yet. Some environments can tolerate a staged rebuild, while others need near-immediate access for safety, operations, or regulatory reasons.

Common failure points include over-reliance on online backups, weak separation between production and recovery credentials, and incomplete treatment of non-human identities. When service accounts, secrets, and federation keys are not covered by the recovery plan, the organisation may restore user logons but still fail to restart applications, automation, and third-party integrations. That is often where ransom pressure increases, because core business services remain unavailable even though the backup set exists.

The most defensible approach is to align recovery planning with identity lifecycle governance, not just infrastructure restoration. Current guidance suggests testing recovery for privileged identities, service accounts, and secrets with the same seriousness as data restore tests, because attackers increasingly target the trust fabric first. The Top 10 NHI Issues is useful here because it frames the control gaps that turn a recoverable event into an extortion decision. Best practice is evolving toward regular identity-only restore exercises, but many organisations still do not rehearse the one thing that matters most: clean administrative control after compromise.

Related resources from NHI Mgmt Group

• How do organisations use identity-level context to speed up investigation and containment after an access incident?
• Why do identity programmes still end up with orphaned accounts and excess access?
• Why does locale handling matter in identity workflows for international organisations?
• Which identity controls should organisations pair with passwordless to reduce the risk of impersonation and unsafe fallback access?