Why do backups fail during ransomware incidents even when they exist?

Why Backups Still Fail When the Identity Plane Is Exposed

Backups are only resilient when the identity used to administer them is isolated from the same blast radius as production. Ransomware operators rarely need to “break” backup software if they can authenticate as an admin, reach snapshot controls, or revoke restore permissions after privilege escalation. That is why the real failure is not storage capacity, but trust-domain overlap between production, backup tooling, and the secrets that bind them.

This pattern shows up repeatedly in incident reporting. NHIMG has documented how exposed credentials and tokens become the first step in broader compromise, including the Cisco Active Directory credentials breach and the Codefinger AWS S3 ransomware attack. The common thread is not just data loss, but control-plane loss. Once restore authority lives beside production authority, ransomware can target both in one pass.

Vendor research points in the same direction. Entro Security found that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and sometimes as quickly as 9 minutes. That speed makes “we have backups” a misleading comfort if the backup identity is reachable by the same attacker. In practice, many security teams discover backup compromise only after restore testing fails during the incident, rather than through intentional control isolation.

How Recovery Works in Practice

Real recovery depends on separating the identity used to create backups from the identity used to restore them, then reducing what each identity can do. Current guidance suggests treating backup control as a privileged workload identity problem, not a storage problem. That means backup operators, automation jobs, and API keys should sit behind tightly scoped RBAC, PAM, and JIT controls, with short-lived secrets and explicit approval paths for destructive actions.

At minimum, the backup plane should be isolated by account, tenant, or trust boundary; its credentials should not be reusable in production; and restore rights should be protected with intent-aware approval or at least dual control. For autonomous tooling, best practice is evolving toward workload identity and just-in-time credentials so that a backup job receives only the permissions it needs for the task, then loses them automatically. That model aligns with the broader identity lessons captured in NHIMG’s 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Why NHI Security Matters Now, both of which show how non-human access becomes the real attack surface.

• Keep backup administration in a separate identity domain from production administration.
• Use JIT access for restore operations and require re-authentication for destructive changes.
• Prefer short-lived secrets, not long-lived API keys or embedded credentials.
• Log and alert on deletion, retention changes, snapshot lock events, and permission drift.
• Test restores from an isolated environment that production admins cannot modify mid-incident.

Anthropic’s report on the first AI-orchestrated cyber espionage campaign also reinforces a broader lesson: once attackers can chain tools and identities, they act faster and more adaptively than static controls anticipate. These controls tend to break down when backup systems inherit the same cloud account, directory trust, or privileged token set as production because one stolen credential can govern both recovery and destruction.

Where Backup Strategy Breaks Down Under Real Attacks

Tighter backup isolation often increases operational overhead, requiring organisations to balance recoverability against administrative convenience. That tradeoff becomes visible in hybrid estates, small IT teams, and cloud-native environments where “temporary” exceptions slowly become permanent access paths. The best practice is evolving, but there is no universal standard for this yet: some teams implement immutable storage, others use air-gapped copies, and many combine both with separated restore authority.

Edge cases matter. Snapshot immutability helps, but only if attackers cannot reach the identity that changes retention or disables the lock. Offline copies help, but only if restore procedures are tested and the key material is protected off the production trust path. In AI-operated or highly automated environments, static role assignments are especially brittle because the system may need to initiate recovery, fail over, or quarantine data without human timing. That is why intent-based authorization and real-time policy evaluation are becoming more relevant than pre-defined access rules. Anthropic’s campaign analysis is useful here because it shows how fast, tool-chaining adversaries exploit weak trust boundaries once they gain a foothold.

For ransomware resilience, the question is not whether backups exist. It is whether backup identity can survive the same compromise that hits production. If the answer is no, the backup is operationally present but functionally unavailable.

Related resources from NHI Mgmt Group

• Why do secrets stay dangerous even when they are no longer actively used?
• Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
• How should organizations respond to OAuth token abuse incidents?
• What did the incidents in ServiceNow reveal about support operations?