Snapshots and cross-account copies can still sit inside the organisation’s primary security domain, so they may be reachable with the same credentials or workload access that compromised production. If an attacker can manipulate the right administrator account or workload, both the live data and the backup copy can be altered. True resilience requires a separate recovery boundary.
Why snapshots and cross-account backups do not create a separate recovery boundary
Snapshots and cross-account copies often improve durability, but they do not automatically change who can reach the data. If backup administration lives in the same cloud tenant, the same IAM design, or the same administrative workflow as production, an attacker who gains those privileges can often touch both the live environment and the backup layer. That is a resilience problem, not just a storage problem.
The practical issue is control-plane overlap. A backup can be protected from accidental deletion and still remain reachable through the same identity paths that were abused in production, especially when cross-account trust, delegated administration, or broad role assumption exists. The backup may be a different copy, but it is not necessarily a different trust domain.
That is why a separate recovery boundary matters more than the storage primitive itself. A true boundary changes who can authenticate, who can authorize recovery actions, and what level of compromise is required before an attacker can tamper with both copies. In cloud ransomware scenarios, the design goal is not only to keep data copied elsewhere, but to make backup modification materially harder than production compromise.
What cloud ransomware attackers exploit in backup designs
Ransomware operators look for the shortest path to irreversible impact, and backup systems are attractive because they can neutralise recovery as well as production. If backup deletion, snapshot management, replication settings, or cross-account access are controlled by the same powerful identity set, the attacker does not need to defeat a second security model. They only need to reuse the access already available in the environment.
This is where overprivilege, role chaining, and weak separation of duties become dangerous. A backup account that can assume production-adjacent roles, or a production admin that can manage backup copies, creates a shared blast radius. Even when the copy itself is immutable, the surrounding control plane may still allow changes to retention, permissions, or restore paths.
Cloud resilience therefore depends on whether the backup path resists the same compromise class as production. The Cloud PAM and CIEM Guide is useful here because the decisive issue is often not whether a backup exists, but whether the effective permissions around it are narrower than the permissions that were abused in the first place.
What organisations need to change to make recovery real
A resilient backup architecture should assume production compromise and still preserve a restore path. That means separating backup administration from daily production administration, reducing standing privilege, and making destructive actions harder to carry out quickly. It also means testing restores from the perspective of a compromised production identity, not from the perspective of a healthy administrator.
Cross-account backup is only helpful when the target account is governed as an independent recovery domain. If the destination account can be reached through broadly trusted roles, shared break-glass access, or recycled credentials, it is still vulnerable to the same attack chain. The Cloud Workload Identity Guide is relevant because keyless, tightly scoped workload access is one of the ways to reduce the chance that backup and production share the same reusable secret or credential path.
For environments with multiple clouds, the same principle applies to workload and service identities as to human admins, because ransomware actors often target whatever can change storage state, not just whatever can log in interactively. The 52 NHI Breaches Report shows why identity compromise in machine paths can have the same downstream effect as a direct console takeover: the backup is only as safe as the identities that can reach it.
Risk and Threat Considerations
Backups that share identity boundaries with production create a false sense of safety. The main risk is not that the copy disappears immediately, but that the attacker can alter retention, revoke access, or delete restore points before defenders realise the backup layer was never independent.
Failure mechanism: The same compromised account, role, or workload that reached production can also assume backup administration or cross-account write access, so the attacker can tamper with both environments without defeating a second control boundary.
Impact: Recovery time grows, restoration may fail entirely, and the organisation can be forced into paying ransom or rebuilding from stale data because the backup path was reachable from the same blast radius as production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Backup access must be narrowly scoped to reduce cross-account tampering risk. |
| IA-5 — Authenticator Management | Shared or long-lived credentials can let the same compromise reach production and backups. | |
| CP-9 — System Backup | The question is about whether backups remain recoverable after ransomware impact. | |
| Recommendation — Limit backup administration privileges to the minimum required for recovery tasks. Rotate and tightly manage credentials that can alter backup and restore systems. Design backups so they remain restorable after a production compromise. | ||
Practitioner Guidance
What to verify: Confirm whether backup deletion, retention changes, snapshot management, and restore permissions require an account or workflow that is not used for ordinary production administration. If the answer is no, treat the backup as part of the compromised domain, not as a recovery boundary.
Decision rule: If a production identity can modify the backup target, the design is not ransomware-resilient enough for critical systems. Separate the administrative plane first, then evaluate immutability, retention lock, and restore testing.
What good looks like: A defender should need a different set of credentials, a different trust path, and ideally a different operational process to alter or destroy recovery copies than to manage the live workload. Restore tests should succeed even after production credentials are assumed compromised.
Practitioner takeaway: In cloud ransomware planning, backup existence is not the control, recovery boundary separation is. If an attacker can reach both the live data and the copy through the same privilege path, the backup reduces inconvenience, not risk.
Related resources from NHI Mgmt Group
- Why do native cloud email controls still leave organisations exposed to advanced phishing and account compromise?
- Why do cloud backups still leave organisations exposed if the recovery process is too slow or too broad?
- Why do MFA controls still leave organisations exposed to ransomware?
- When does multi-factor authentication still leave organisations exposed to account takeover?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
