Air-gapped recovery copies matter because ransomware can encrypt or corrupt production data and then move into connected backups if there is no separation. Isolated, immutable copies preserve a clean restore point and reduce the chance that recovery is blocked by the same attack. In multi-cloud environments, the control must be physical or logical, geographically sensible, and regularly tested.
Why air-gapped copies are the difference between recovery and re-compromise
Air-gapping creates a separate trust boundary between production and restore data. That matters because ransomware does not just encrypt active systems, it also tries to reach backup targets, snapshot management planes, and shared credentials so that recovery options disappear at the same time as the primary outage. In practice, the air gap is what keeps “we have backups” from becoming “we have only encrypted backups.”
The important distinction is that isolation is not only about where the copy lives, but about whether the attacker can reach, alter, or delete it through the same control plane used for day-to-day administration. In multi-cloud environments, that means the recovery copy must be separated from routine identity paths, management permissions, and network routes that ransomware can reuse after the initial compromise.
A useful way to think about this is survivability under hostile assumptions. If an attacker obtains admin access in one cloud, the backup strategy should still leave a restore path that is not reachable through that same compromise. That usually means immutable storage, independent accounts or tenants, strong separation of duties, and a recovery process that can be executed without trusting the compromised environment.
Why multi-cloud makes backup isolation harder, not easier
Multi-cloud can improve resilience, but it also expands the number of places where backup trust can fail. Each cloud provider has its own IAM model, APIs, snapshot semantics, retention tools, and cross-account sharing patterns. If those layers are loosely coupled, ransomware only needs one weak bridge, such as overly broad replication rights, shared admin credentials, or synchronized deletion permissions, to turn a backup copy into another encrypted target.
Connected backup designs are especially fragile when operators assume that “different cloud” automatically means “different compromise domain.” It does not. If backup access is federated, scripted, or centrally managed without separate recovery controls, an attacker who reaches the orchestration layer can often touch every copy. A real multi-cloud resilience design therefore treats provider diversity as one layer, and isolation of the recovery copy as another.
The restore point also has to be geographically and operationally sensible. A copy that is so isolated that it cannot be restored under incident pressure is not resilient, it is merely dormant. The practical goal is a copy that is hard for ransomware to reach, but still testable, discoverable, and usable during a crisis.
What “air-gapped” should mean for ransomware resilience
In modern backup programs, air-gapped often means logical rather than purely physical separation. The copy may be on separate storage, in a separate account or tenant, with separate credentials, stricter approval paths, object lock or immutability, and no standing write access from production. The exact implementation can vary, but the security property must remain the same: the attacker should not be able to use the same access path to destroy production and recovery data together.
For ransomware resilience, the most important control qualities are immutability, independence, and recoverability. Immutability prevents quick tampering after compromise. Independence reduces the chance that one stolen identity or one misconfigured pipeline can erase every copy. Recoverability proves the backup is not just isolated, but actually restorable within the recovery time the business expects.
Testing is part of the control, not an extra. If restore drills are rare, the organization may discover only during an incident that the “air gap” was vulnerable through automation, that retention policies were misapplied, or that the clean copy cannot be mounted or decrypted in the alternate environment.
Risk and Threat Considerations
Ransomware resilience fails when backup isolation is weaker than production access. The most common failure mode is shared privilege: the same identity, automation path, or management plane can reach both live systems and the recovery copy, allowing the attacker to encrypt, delete, or age out backups before defenders can restore.
Failure mechanism: Attackers exploit connected storage, shared credentials, synchronized administration, or over-permissive replication to corrupt the last known good copy and remove the defender’s recovery option.
Impact: Recovery is delayed or blocked, downtime expands, and organisations may be forced into a full rebuild or negotiation because no trustworthy restore point remains.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | Ransomware backup isolation exists to support reliable recovery after an incident. |
| PR.DS-10 — Data in Transit is Protected | Air-gapped copies rely on separating backup transfer paths from routine production access. | |
| PR.DS-11 — Data at Rest is Protected | Immutable recovery copies protect stored backup data from encryption and deletion. | |
| Recommendation — Test restore procedures so clean recovery remains possible after ransomware. Separate backup transfer paths from production administration channels. Apply immutability and retention controls to backup data at rest. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | The subject is fundamentally about preserving recoverable copies against ransomware. |
| CIS-3 — Data Protection | Protecting backup copies from corruption and deletion is a core data-protection concern. | |
| Recommendation — Keep tested, offline-capable recovery copies that resist tampering. Protect backup data with isolation, immutability, and access restriction. | ||
Practitioner Guidance
What to prioritise: Protect the backup plane as if it were a separate production environment. If a backup copy can be deleted, overwritten, or re-encrypted through the same administrative path as source data, treat it as exposed rather than protected.
What to verify: Confirm that the recovery copy has independent access control, immutable retention, and a restore workflow that does not depend on compromised credentials or a compromised orchestration layer. Then test the full restore path, not just the backup job status.
What good looks like: Production can fail, cloud accounts can be rotated, and the organisation still has a clean, bounded, and restorable copy that ransomware cannot silently alter before incident response begins.
Practitioner takeaway: Multi-cloud improves resilience only when the recovery copy is isolated enough to survive the same compromise that took down production, and simple enough to restore under pressure.
Related resources from NHI Mgmt Group
- What breaks when multi-cloud backup is treated as the same thing as recovery?
- Why do multi-cloud backup and recovery environments create governance and access risks?
- What breaks when cloud recovery environments are not air-gapped from production systems?
- How should security teams design cyber resilience for multi-cloud environments without creating new recovery gaps?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
