Physical Air Gap Storage and Ransomware Protection
Ransomware crews now attack backups deliberately, not incidentally. This explainer sets out the modern kill chain, why a copy has to predate compromise, and what physical disconnection actually changes about the outcome.
- Written by
- Mark Fermor, Co-Founder, Firevault
- Technical review
- Firevault architecture team
- First published
- 18 November 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 was written from publicly available guidance from CISA, NCSC and NIST on ransomware behaviour and backup resilience, cross-checked against the mechanics of how physical disconnection works at the storage layer. No vendor claims, percentages or incident statistics have been invented; every figure is either qualitative or sourced.
Every serious piece of ransomware guidance now says the same thing in different words: keep an offline backup copy. The advice sounds simple, but the reasoning behind it is often skipped, which leaves buyers unable to tell a genuine physical air gap from a marketing description of one. This explainer works through why physical disconnection changes the outcome of a ransomware incident, using the mechanics of a modern attack rather than a sales pitch.
It covers what a physical air gap means in practice, how the current ransomware kill chain treats backup infrastructure, why reachability rather than access control is the decisive factor, and how recovery time and recovery point objectives interact with an offline copy. It closes with the specific guidance published by CISA and NCSC, and where Firevault fits against these principles.
What a physical air gap actually is
A physical air gap exists when there is no electrical or optical connection between a piece of storage hardware and any network, at the point in time being described. Nothing is listening on a port because there is no port connected to anything. There is no IP address to scan, no service to authenticate to and no credential that can create a network path that does not physically exist.
This is a narrower claim than "isolated" or "protected". Isolation is often achieved through firewall rules, access control lists or virtual network segmentation, all of which are logical constructs sitting on top of a network connection that still exists. A physical air gap removes the connection itself, which means the isolation does not depend on any rule continuing to be correctly configured and enforced.
- Physical air gap
- No network connection exists to the storage at the point of description.
- Logical isolation
- A network connection exists, and a policy or rule restricts what may use it.
- Immutability
- A logical control preventing deletion or modification for a defined retention period.
- Reachability
- Whether any traffic, authorised or not, can arrive at the storage at all.
The modern ransomware kill chain
Ransomware is rarely a single event. It is the final stage of an intrusion that typically follows a recognisable sequence, documented across CISA advisories and NCSC incident guidance. Understanding the sequence explains why backup protection has to be designed against the attacker's later stages, not just the initial breach.
The critical detail is stage three. Deleting or degrading backups happens deliberately, and before encryption, because a victim who can restore quickly has far less reason to pay. A defence strategy that only considers stage four, the encryption event itself, is designed against the wrong stage of the attack.
Why backup repositories are targeted first
Backup infrastructure is an efficient target because it concentrates the victim's recovery options into a small number of systems. If those systems are reachable over the same network as everything else, and protected by the same identity layer that has already been compromised, the return on effort for an attacker is high.
- Concentration of value. A single backup platform typically holds the recovery path for many production systems, making it worth prioritising.
- Shared identity plane. Backup consoles and repositories are commonly administered through the same directory service as the rest of the estate, so a compromised administrator account often extends directly to backup control.
- Retention and immutability can be reconfigured. If an account with sufficient privilege can create a retention policy, the same privilege can usually shorten it, disable it or delete the underlying objects.
- Network reachability is assumed. Cloud backup consoles, snapshot APIs and hardened repository appliances are, by design, reachable from the management network, which is also where lateral movement occurs.
What this means for buyers: A backup platform's resilience claims should be read against this stage of the kill chain specifically. The relevant question is not whether the platform offers immutability, but whether an attacker who already has administrative access to the environment can reach and alter it.
Reachability versus access control
Reachability is the more fundamental of the two concepts. Access control assumes a network path exists and restricts who may use it through authentication, authorisation and policy. Reachability asks whether any path exists at all, regardless of who or what is attempting to use it.
- Depends on credentials remaining uncompromised
- Depends on retention policy remaining correctly configured
- Depends on the identity provider remaining trustworthy
- A privileged account can reconfigure or delete it
- No IP address to route traffic to
- No credential can open a connection that does not exist
- Not dependent on identity provider integrity
- Requires physical access to alter, not remote privilege
Every logical control, however well designed, operates on top of a reachable network. A physical air gap removes that layer entirely for the duration the storage is offline, which is why it is treated differently from immutability in guidance from NIST and NCSC.
Dwell time and why a copy must predate compromise
Dwell time is the interval between an attacker's initial access and the point at which the intrusion is detected. Published incident data varies attack by attack, and this explainer does not assign a specific figure to it, but the consistent theme across CISA and NCSC advisories is that dwell time is frequently long enough for an attacker to explore the environment, identify backup infrastructure and prepare its removal well before encryption takes place.
This has a direct implication for what counts as a trustworthy recovery copy. A backup taken during the dwell period, while the attacker already has a foothold, cannot be assumed clean even if it was not directly targeted, because it may already contain a persistence mechanism or exfiltrated credential artefacts. A copy is only reliably trustworthy if it predates the point of compromise, or if it has been verifiably isolated throughout the period in question.
What this means in practice
- Retain more than one generation of offline copy, not just the most recent
- Treat the most recent online backup as potentially compromised until proven otherwise
- Keep at least one copy that was disconnected before any known indicator of compromise
- Verify integrity of an offline copy before restoring from it after an incident
Recovery time versus recovery point
Two separate objectives determine whether a backup strategy is fit for purpose, and they are frequently conflated. Recovery point objective (RPO) describes the maximum acceptable data loss, expressed as the time since the last usable copy. Recovery time objective (RTO) describes the maximum acceptable duration of the restoration process itself.
| Objective | Question it answers | What affects it |
|---|---|---|
| Recovery point objective (RPO) | How much data can we afford to lose? | Frequency of the offline copy, and how far back the last verified clean copy sits |
| Recovery time objective (RTO) | How long can restoration take? | Restore throughput, the size of the estate, and how the connection window is scheduled |
An offline copy that is refreshed too infrequently satisfies neither objective well: the recovery point is poor because too much data would be lost, and if restore throughput is also limited, recovery time suffers as well. The correct refresh interval and restore design depend on the organisation's tolerance for each, not on a single industry-wide figure.
What CISA and NCSC guidance says
Both the US Cybersecurity and Infrastructure Security Agency and the UK National Cyber Security Centre publish guidance recommending that organisations maintain a backup copy that is offline, in addition to online and immutable backups.
The CISA StopRansomware guide recommends maintaining offline, encrypted backups of critical data and regularly testing the restoration process, alongside broader controls covering identity, patching and network segmentation. The NCSC guidance on mitigating malware and ransomware attacks makes the same point directly, stating that a backup copy should be kept offline and not reachable from a network that may be compromised. NCSC has also written specifically on the distinction between an offline copy and one that is merely access-controlled, in Offline backups in an online world.
NIST SP 1800-11 sets out a practice guide for building a recoverable architecture following a destructive event, including the use of isolated backup copies as part of a layered recovery strategy. The Recover function of NIST CSF 2.0 frames backup and restoration planning as a distinct discipline from prevention and detection, which reflects the reality that a well designed offline copy is a control against the failure of every other control.
Distinctions people get wrong
A number of terms get used loosely in vendor marketing, which makes it harder for buyers to compare products fairly.
- Immutable is not the same as offline. Immutability prevents modification within a policy window. Offline means there is no network path at all. A reachable immutable store is still exposed to the reachability risks described above.
- Air gapped is not the same as segmented. Network segmentation, VLANs and firewall rules are logical controls that reduce, rather than remove, reachability. They are useful, but they are not equivalent to physical disconnection.
- Backup is not the same as recovery. Having a copy of the data is not the same as having a tested, timed process for restoring it. RTO failures are common even when RPO is well met.
- Cloud is not inherently insecure, and offline is not inherently sufficient. The two models address different risks and are usually complementary rather than substitutes for one another.
A practical decision checklist
When evaluating whether a backup architecture will hold up against the kill chain described above, the following questions are a reasonable starting point.
- Does at least one copy have no network interface active while offline?
- Is that copy administered on a separate identity and management plane from production?
- Does the refresh cycle keep pace with the organisation's RPO tolerance?
- Has a full restore been tested end to end within the target RTO?
- Is more than one generation of offline copy retained, to cover dwell time uncertainty?
- Is there a documented, auditable trail of when the copy was last connected and by whom?
- Does the design assume the identity provider itself could be compromised?
Limits and failure modes
A physical air gap is not a complete ransomware strategy on its own, and it is worth being precise about what it does not do. It does not detect an intrusion, prevent initial access, or protect systems that must remain online. It also introduces an operational cost: a connection window has to be created to refresh the copy or perform a restore, and that window has to be managed carefully so it does not itself become a reachable surface.
An offline copy can also fail to help if it is refreshed too infrequently, if the connection window is poorly controlled, or if the restore process has never been tested at the scale required during a real incident. None of these are arguments against physical disconnection as a principle; they are arguments for treating the connection window, refresh cadence and restore process as carefully designed parts of the system, not afterthoughts.
How Firevault applies these principles
Firevault provides Offline Secure Storage® as a physically disconnected recovery copy, intended to sit alongside an organisation's existing online and immutable backup tiers rather than to replace them. The storage has no network interface enabled while offline, so it presents no reachable surface to the kill chain described in this explainer.
Connection windows for refreshing or restoring the copy are scheduled and identity verified, following the Disconnect to Protect® approach, with a tamper evident record of every connection and disconnection event. Firevault Control manages that switching process on a management plane that is kept separate from production identity systems, so that a compromise of the production directory does not extend to the storage. Firebreak® describes the boundary this creates between an active estate and the disconnected copy.
A copy an attacker cannot reach changes the shape of the whole incident
Ransomware outcomes are decided long before the ransom note appears, at the point where the attacker either can or cannot reach a clean, recent copy of the data. Logical controls such as immutability and retention policy reduce that risk but do not remove it, because they still depend on a network path and an identity layer that can, in principle, be compromised.
A physical air gap removes the network path itself. It does not replace monitoring, identity hygiene or fast operational backup. It answers a narrower and more absolute question: if everything else fails, is there a copy the attacker was never able to touch.
Frequently Asked Questions
Straight answers on how Offline Secure Storage® behaves in practice.
Sources and further reading
- CISA, StopRansomware Guide
US federal guidance on ransomware prevention, response and the role of offline, encrypted backups.
- NCSC, Mitigating Malware and Ransomware Attacks
UK guidance recommending offline backup copies that are not reachable from a compromised network.
- NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events
Practice guide on building a recoverable architecture, including isolated and immutable backup copies.
- NIST Cybersecurity Framework (CSF) 2.0
Recover function guidance on backup, restoration and recovery planning.
- NCSC, Offline Backups in an Online World
Explains why an offline copy needs to be genuinely unreachable rather than merely access-controlled.
Related Firevault guides