Who is accountable when recovery controls fail during a double-extortion attack?

Why This Matters for Security Teams

Double-extortion changes the accountability problem because recovery is no longer just about restoring files. Attackers often target backup admins, identity stores, logging, and recovery tooling at the same time, so the failure point may sit outside the obvious incident response chain. That means ownership has to be explicit across identity, infrastructure, backup, and evidence retention, not assumed at the point of crisis. NHI governance is part of that answer, especially where recovery identities and privileged service accounts exist alongside human admin access.

This is not theoretical. NHIMG’s 52 NHI Breaches Analysis shows how often identity control failures become the path to broader compromise, and the same pattern appears in backup tampering and log deletion. External guidance from the NIST Cybersecurity Framework 2.0 reinforces that recovery is a governed capability, not a single control. In practice, many security teams discover accountability gaps only after attackers have already disabled recovery paths, rather than through intentional ownership review.

How It Works in Practice

Clear accountability starts by treating recovery as a chain of distinct controls, each with its own owner and review cadence. That typically includes the identity owner for break-glass and backup service accounts, the infrastructure owner for immutable storage and network segmentation, the backup owner for retention and restore testing, and the incident response owner for evidence preservation and escalation. When those roles are merged informally, attackers can pivot from one control plane to another and undermine the recovery path before any single team realises it.

For double-extortion scenarios, the practical goal is to reduce the number of standing privileges that can alter backups, delete logs, or revoke forensic access. Current guidance suggests using just-in-time access for administrative recovery tasks, strong separation between production and backup administration, and short-lived credentials for all recovery identities. That aligns with NHI governance patterns described in 230M AWS environment compromise and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

• Assign one named owner for each recovery identity, backup domain, and logging domain.
• Use separate administrative paths for backup management and production administration.
• Require immutable or offline copies for backups where feasible.
• Test restore, access revocation, and evidence retention as a single workflow.
• Review who can change backup policies before a crisis, not after a ransom note.

These controls tend to break down in environments where backup tooling shares the same identity provider, management network, and privileged group structure as production systems.

Common Variations and Edge Cases

Tighter recovery control often increases operational overhead, requiring organisations to balance speed of restoration against administrative friction. That tradeoff becomes sharper during active extortion, when teams want immediate access but still need reliable attribution for every privileged action. Best practice is evolving, not settled, for how much break-glass access should be pre-authorised versus issued at runtime, especially in hybrid and multi-cloud estates.

Edge cases matter. In some environments, the backup platform is owned by infrastructure while the evidence archive is owned by security operations, which creates ambiguity unless the escalation path is documented in advance. In others, managed service providers hold recovery credentials, so accountability extends into contract terms and access review evidence. NHIMG’s GitLocker GitHub extortion campaign and Ultimate Guide to NHIs — Key Challenges and Risks both reflect how quickly misuse of non-human access can turn a recovery problem into a governance failure. The practical answer is to document who approves, who executes, and who verifies every recovery action, because ownership gaps are what attackers exploit first.

Related resources from NHI Mgmt Group

• Who is accountable when workforce IAM controls fail during offboarding?
• Who is accountable when identity recovery workflows fail under attack?
• Who is accountable when recovery workflows fail during an outage?
• Who is accountable when breach readiness controls fail to contain an attack?