Air Gap vs Immutable Backup: How They Differ and Combine
Object lock and WORM retention are powerful, but they are not the same control as a physical air gap. This explainer sets out what immutability actually protects, what it does not, and how the two belong together in a resilient backup architecture.
- Written by
- Mark Fermor, Co-Founder, Firevault
- Technical review
- Firevault architecture team
- First published
- 22 September 2025
- Last reviewed
- 27 August 2026
- Review cycle
- At least annually, or following material changes to NIST, NCSC or ISO guidance.
How we built this explainer: This explainer draws on published guidance from NIST, NCSC UK and CISA on ransomware resilience and backup architecture, together with documented incidents involving immutable and cloud backup platforms. No vendor performance claim, percentage or statistic appears unless it can be traced to a named, checkable source.
Immutable storage and air-gapped storage are frequently discussed as though they solve the same problem. They do not. Immutability is a promise about what can happen to data that remains reachable. An air gap is a statement about whether the data is reachable at all. Confusing the two leads organisations to believe they have covered a risk that, in fact, remains open.
This explainer sets out what immutable storage mechanisms such as object lock and WORM actually do, where their protection stops, and how to combine immutability with a genuine physical air gap so that neither gap in coverage is left unaddressed.
What is immutable storage?
Immutable storage is storage configured so that, once written, an object cannot be modified or deleted until a defined retention period has elapsed. The guarantee is enforced by the storage platform's software, typically at the object or volume level, and is intended to stop both accidental and malicious alteration of backup data during the protected window.
The storage remains connected to the network throughout. Backup jobs need to reach it to write new data, and administrators need to reach it to manage retention settings, which means the protection depends on the software enforcing it and the identity system authorising access to it, both of which remain part of the attack surface.
WORM, object lock and retention locks explained
- WORM
- Write once, read many. Data can be written once and subsequently only read, not altered, for a defined period. The underlying mechanism behind most immutable storage.
- Object lock
- A cloud storage feature, common in S3-compatible platforms, that applies a WORM-style retention date to individual objects.
- Governance mode retention
- A retention lock that certain privileged accounts or roles can override, shorten or remove before expiry.
- Compliance mode retention
- A stricter retention lock that cannot be shortened or removed by any account, including the owner, before the retention period expires.
The distinction between governance mode and compliance mode matters considerably. A retention lock that can be overridden by a sufficiently privileged account offers weaker protection against an attacker who has obtained that privilege than a lock that genuinely cannot be altered by anyone until it expires.
What is a physical air gap?
A physical air gap means the storage has no active network interface while it is meant to be isolated. There is no address to reach it at, no listening service to authenticate to, and no software process on the connected estate that can bring it back online by itself. Reconnection is a distinct, separately controlled and auditable event.
Where immutability is a policy statement enforced by software that remains reachable, a physical air gap removes the reachability itself. The two controls answer different questions: immutability asks "can this data be changed while I can still reach it", and a physical air gap asks "can this data be reached at all".
Air gap versus immutable, side by side
Cannot be altered, remains reachable
- Protects the object from modification during retention
- Enforced by platform software and configuration
- Depends on the account and identity system holding
- Governance mode can be overridden by privileged roles
Has no network path to reach
- Protects the copy by removing reachability
- Enforced by the absence of an active interface
- Unaffected by compromise of the connected account
- Reconnection is a separate, audited event
What immutability actually protects
Immutability is a genuinely effective control against a specific, common set of failure modes, and should not be dismissed because it has limits.
- Accidental deletion by an authorised user during normal operations
- Malware or ransomware that only encrypts or deletes files, without reaching the backup account itself
- A rogue or careless script that attempts to overwrite backup data within the retention window
- Basic insider actions from an account that does not hold elevated administrative privilege
What immutability does not protect against
The limits of immutability are not a flaw in the technology. They are the natural consequence of the storage remaining reachable, which it must be for backups to be written to it in the first place.
Four failure modes immutability alone does not close
- Credential compromise. An attacker who obtains sufficiently privileged credentials to the backup or cloud storage account can alter configuration that sits outside the immutability lock itself, including access permissions and future retention settings.
- Retention policy manipulation. Where retention is configured in governance mode rather than compliance mode, a privileged account, legitimate or compromised, can shorten or remove the lock before it expires.
- Provider-plane attacks. Attacks that target the cloud provider's control plane, billing account or organisation-level settings, rather than the individual storage object, can affect data that the object-level lock was never designed to defend against.
- Deletion of the whole account. Object Lock protects individual objects. It does not, on its own, prevent deletion of the entire bucket, account or subscription by an actor with sufficient privilege at that higher level, depending on the specific platform and configuration.
How standards and guidance frame the two
NIST SP 800-209 treats immutability, access control and isolation as separate storage security layers, each closing a different gap rather than one substituting for another. NIST SP 1800-11 discusses the need for an isolated, trusted recovery source specifically because software controls on the production or backup network cannot be assumed to hold under a determined attack.
ISO/IEC 27040 addresses WORM and retention mechanisms alongside isolation as complementary storage security controls, rather than presenting either as a complete answer on its own. NCSC UK guidance and the CISA StopRansomware guide both recommend maintaining at least one offline backup copy in addition to immutable, network connected copies, precisely because the two address different parts of the threat model.
When each control is appropriate
The right choice depends on the specific failure scenario a given backup copy is meant to survive, not on which control sounds more modern.
| Scenario | Immutable storage alone | Physical air gap |
|---|---|---|
| Accidental deletion by a normal user | Sufficient | Not required for this scenario |
| Ransomware limited to endpoints and file shares | Usually sufficient, if correctly configured | Provides additional assurance |
| Attacker with domain administrator access | Not sufficient on its own | Required for a trusted last copy |
| Compromise of the backup platform's own account | Not sufficient on its own | Required for a trusted last copy |
| Cloud provider control-plane incident | Not sufficient on its own | Required for a trusted last copy |
How to combine air gap and immutable backup
Combining the two is not complicated in principle, though it requires treating them as distinct layers in the recovery architecture rather than as alternative products competing for the same budget line.
Where each fits in the 3-2-1-1-0 rule
The 3-2-1-1-0 rule extends the classic 3-2-1 backup rule with one additional offline copy and a requirement of zero errors on recovery testing. Immutable, network connected storage can satisfy the offsite copy requirement, but it does not satisfy the offline requirement, because it remains reachable throughout. A physical air gap is what the offline requirement in the rule is describing.
- Reachable over the network throughout
- Protected from deletion within the retention window
- Still exposed to account and identity compromise
- No network path while in its isolated state
- Unaffected by compromise of the connected estate
- Satisfies the offline element of 3-2-1-1-0
How Firevault applies these principles
Firevault's Offline Secure Storage® is designed to provide the physical air gap layer described in this explainer, alongside, rather than instead of, whatever immutable backup platform an organisation already runs. Storage hardware has no active network interface while offline, and scheduled, identity verified connection windows are controlled from a management plane separate from the customer's own estate, so compromise of that estate, including its identity systems and backup consoles, has no path to the offline copy.
Firevault does not position Offline Secure Storage® as a replacement for immutable, network connected backup. Immutable storage continues to do the job it does well: fast, everyday recovery. Offline Secure Storage® exists for the copy that needs to survive the day the rest of the estate, including the account controlling that immutable storage, has been compromised.
Immutability protects the object. A physical air gap protects the copy from the account holding it
Immutable storage is a genuine, valuable control that stops data being silently altered or deleted while it remains reachable on the network. It does not, on its own, protect against compromise of the account, identity system or provider control plane that governs it. A physical air gap addresses exactly that gap by removing the network path entirely. The resilient answer is not to choose between them but to use immutable storage for fast recovery and a physical air gap for the copy that must survive everything else failing at once.
Frequently Asked Questions
Straight answers on how Offline Secure Storage® behaves in practice.
Sources and further reading
- NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events
Practice guide covering isolated, trusted recovery sources and the limits of protections that remain on a reachable network.
- NIST SP 800-209, Security Guidelines for Storage Infrastructure
Guidance on storage security controls including immutability, access control and isolation as distinct layers.
- ISO/IEC 27040:2024, Storage Security
International standard addressing WORM, retention and isolation controls within a storage security programme.
- NCSC UK, Offline Backups Guidance
Recommends at least one backup copy that is genuinely offline, distinct from immutable copies that remain network reachable.
- CISA, StopRansomware Guide
Federal guidance recommending both immutable and offline backup copies as part of a layered ransomware defence.
Related Firevault guides