Logical air gap and physical air gap for backup repositories

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A physical air gap means at least one recovery copy is physically disconnected from network and management paths. Ejected media or a fully disconnected appliance can provide it. A powered-down host with a connected management controller, or storage that is merely unmounted, does not establish a physical gap. A logical air gap leaves the copy online. Ordinary production credentials, routes, and delete calls are supposed to fail, while a separate administration path can still write new backups and, later, read them back.

Those two labels are planning language. They are not terms defined by the sources below. What the sources do define is the outcome. The September 2023 #StopRansomware Guide from CISA, the FBI, the NSA, and the MS-ISAC says critical data should be kept as offline, encrypted backups, and that those backups should be tested, because many ransomware variants try to find accessible backups and then delete or encrypt them. NIST IR 8374r1 (June 2026) says backups should have a copy stored offline or otherwise kept so the attacker cannot reach them and ransomware cannot compromise them. The practical question is which of your copies meets that sentence, and which only meets it until someone reconnects the array for a faster nightly job.

This article is about that design choice. It does not describe how to rebuild an operating system, and it does not describe an Active Directory forest restore.

Why the label matters on the day you need the copy

Ransomware's business depends on making restoration harder than payment. The CISA guide states the mechanism directly: attackers look for accessible backups so that restoration is impossible unless the ransom is paid. If every copy a production identity can list is also a copy that identity can delete or encrypt, the backup programme has not created a recovery option. It has created another folder in the blast radius.

The failure is usually ordinary. A repository is called offline because its management interface sits on a backup VLAN, while the same hypervisor can still mount the datastore. The backup service account is a domain administrator, or can be reset by one. A cloud bucket has a retention lock in the same account as the identity provider the attacker already owns. Each of those can still be a sound control if you have named the remaining path and shown that the attacker you are planning for cannot use it. Calling all of them an air gap hides the path.

A copy that is truly disconnected is slower to update and slower to read. Teams then keep a nearer copy for the daily job and let that nearer copy become the only one anyone has restored. NIST SP 800-184 treats offline or off-site storage of records and media as a recovery-plan topic because ransomware encrypts data and withholds the key. The plan has to name which copy you will trust when the near copy is gone, and what recovery point that copy represents.

What the current guidance recommends

The CISA guide's preparation section tells organisations to maintain offline, encrypted backups of critical data and to test availability and integrity in a disaster-recovery scenario. It repeats the operational reason: backups must be maintained offline because ransomware tries to find and then delete or encrypt accessible backups. The guide also says some cloud vendors offer immutable storage that can protect data without a separate environment, and it tells you to use that option with caution. The stated reasons are regulatory fit and cost: immutable storage does not meet the compliance criteria of certain regulations, and misconfiguration can impose significant cost. The guide maps the offline-backup practice to its performance goal 2.R. This article did not open that goal document, so the mapping is the guide's.

NIST SP 800-61 Rev. 3 (April 2025) is the current incident-response profile. It marks CSF 2.0 outcome PR.DS-11, "Backups of data are created, protected, maintained, and tested", as high priority, and notes that backups matter especially when integrity or availability is hit. That note does not use the word offline. For how to recover, it points to SP 800-184. Rev. 2 of SP 800-61 was withdrawn on 3 April 2025.

The ransomware-specific profile is newer than SP 800-61 Rev. 3. NIST IR 8374 (February 2022) was withdrawn on 11 June 2026 and superseded by IR 8374r1. The withdrawn profile said backups should be stored offline so they cannot be corrupted or deleted. The June 2026 profile keeps the offline copy and adds an alternative. Its PR.DS-11 application says backups should have a copy stored offline or otherwise in a manner that prevents access by the attacker or compromise by ransomware. The executive actions in the same document say to secure and isolate backups of important data, and they map that action to PR.DS-11 and to RC.RP-03, the outcome that requires the integrity of backups and other restoration assets to be verified before use.

That "or otherwise" is the closest the current NIST ransomware profile comes to allowing a logical control. The manner still has to prevent attacker access and ransomware compromise. A retention lock that the same compromised administrator can unlock does not meet the sentence.

NIST also uses "immutable" for a different idea. IR 8374r1 says to store data in an immutable format so that the database does not automatically overwrite older data when new data arrives, and it maps that bullet to PR.DS-11. That is versioned data, not a statement that a cloud object-lock bucket is an air gap. Keep the two ideas apart. A database that retains prior rows can still be deleted by an administrator who can drop the instance. A bucket that refuses delete can still be useless if the account that holds the key is the account under attacker control, or if the regulation you must meet does not accept that control. CISA's caution on cloud immutable storage sits next to NIST's "or otherwise" clause. Together they say: an online control can be part of the design, and it is not a substitute you should assume is enough.

SP 800-184, still cited by the 2025 incident-response profile, asks the recovery plan to record where records or media are kept offline or off site. The plan item is a location and an arrangement, not a product name.

A physical air gap

In a physical air gap the recovery copy is not electrically or logically attached to the network the attacker is on. Examples, as design patterns rather than product endorsements:

• Tape or a removable disk that is ejected and stored in a place production systems cannot reach.
• A repository appliance whose only network cable is disconnected except during a staffed backup or restore window, and whose management port is not left on the production management network.
• Media held at a second site with no connected replication, data or management path. Remote location or absence of a mounted share alone is not a physical gap.

Malware that can already run as a backup administrator still cannot open a session to a disk that is not attached. The copy also ages from the moment you disconnect it. If the last disconnected copy is a day old, that is the recovery point for this tier, even if a connected repository took a snapshot minutes ago. If you have never attached that copy in a controlled way and read data back, you do not yet know that the gap is a recovery capability. CISA asks for tests of availability and integrity. NIST IR 8374r1 asks you to plan, implement, and test the strategy, not only to store the bytes.

Physical gaps fail in ways that look like good operations:

• A replication link left up "until the job finishes" stays up.
• The index that names the offline media lives only on the backup server that has just been encrypted.
• The offline media is readable only with a catalogue and keys that were online.
• Anyone with a cabinet key can close the gap. SP 800-61 Rev. 3 treats movement of equipment into and out of secure areas as part of finding adverse events. The procedure needs an owner.

Our recommendation, not a statement from CISA or NIST: if you claim a physical air gap, write down the last moment the copy was attached, who is allowed to attach it, and where the catalogue and keys live while it is detached. If you cannot answer those three, the gap is a hope.

A logical air gap

A logical air gap assumes the copy stays reachable by some system, because that is how you get frequent recovery points and a restore that does not start with a courier. The protection is then a set of denies:

• Production identities cannot list, alter, or delete the recovery copy.
• The backup platform's everyday administration role cannot shorten retention or turn the lock off.
• The network path from production subnets to the repository does not exist, except for the backup ingest path you have named.
• A separate identity, ideally issued from a directory the production domain does not control, is required to read the copy back during recovery.
• Retention or immutability is enforced by the store itself, so a stolen API key that can upload cannot also expire last month's objects.

NIST's June 2026 wording allows this class of control when it says "or otherwise in a manner that prevents access". CISA does not use that phrase. CISA's primary instruction is still offline copies, with immutable cloud storage described as a cautious option that does not replace a separate environment in every regulation. If you adopt a logical gap, you are closer to the 2026 NIST sentence than to the CISA lead sentence. Say that in the design record so an auditor does not think you have implemented "offline" when you have implemented "locked but online".

Logical gaps fail when any one deny is bypassed by a path you forgot:

• A hypervisor, storage administrator or cloud account owner may have a destructive path outside the backup role. Whether that path can override retention depends on the product and lock mode; some compliance locks restrict even account owners. Verify the actual deletion, key-management and account-lifecycle boundaries.
• The identity provider used for the "separate" break-glass account is the same tenant the attacker is inside.
• Immutability is a policy on the backup software, and the backup software's database is on a volume the attacker can encrypt. The objects may survive and the only map to them may not.
• A support tunnel, a "temporary" firewall rule, or a disaster-recovery test left a route in place.
• The lock is shorter than the time the attacker has already been inside. The CISA guide warns that ransomware often follows an earlier compromise, including access sold on after a dropper. A short lock then preserves copies taken after the attacker arrived. Isolation is not a clean recovery point. Catalogue triage has to answer that separately.

Paths that make a copy "accessible"

Use the CISA word. A backup is accessible when the attacker who already has a foothold can find it and then delete it, encrypt it, or alter retention. Walk the path from that foothold, not from a diagram that shows a firewall icon.

A copy can be strong on one row and absent on another. An unplugged tape still fails if you cannot identify it. For an object-lock bucket, verify account-closure and key-loss behaviour separately from object-retention enforcement; do not assume every root identity can bypass every lock. Score the copy by the weakest row your assumed attacker can reach. SP 800-184 makes the same point about roots of trust: a forgotten administrative account, or a management tool with agents still installed, lets the adversary persist after the restore. The repository is one of those roots.

Immutable storage is a third idea, not a synonym

Treat three phrases as different controls.

Offline or physically disconnected. The attacker cannot open a session because there is no session to open. This is CISA’s lead recommendation and the first half of the NIST IR 8374r1 sentence.

Isolated but online. A path exists and is fenced by identity, routing, and a store that refuses delete. This is the "or otherwise" half of the NIST sentence, and it is only as good as the fence.

Immutable format or retention. Older data is not overwritten when new data arrives. NIST attaches this phrase to databases. Cloud immutable storage, in the CISA guide, is a vendor feature that can protect data without a separate environment, with cautions about regulations and the cost of a wrong setting. A retention lock can support a logical air gap. It does not prove the copy is offline, and it does not prove the copy is free of attacker-written data.

Our recommendation, not a vendor claim: keep one copy that meets the physical test for the systems you cannot operate without, and use a logical control for a more recent point. Write the recovery point of each. If the business can afford to lose four hours and the disconnected copy is only nightly, the nightly copy does not meet that statement. Change the statement or change the copy. Do not let the online locked bucket become the unspoken answer to both.

What to write down

A design that cannot be checked will be redescribed under pressure. Before an incident, record the following for each recovery tier. This is a planning record, not a restore procedure.

1. The copy's location and whether it is attached right now.
2. The identities that can write, delete, shorten retention, and read. Name the directory that issues each identity.
3. The network paths that exist today, including management, replication, and support access.
4. Where the catalogue and the encryption keys are, and whether they survive encryption of the backup server.
5. The oldest and newest recovery points on that copy, and the last date someone read data back from it rather than trusting a success flag.
6. Who may attach or unlock the copy, and how they will be reached if email and single sign-on are unavailable. The CISA response checklist tells responders to use out-of-band methods such as phone calls once they suspect they are being watched. A procedure that starts with "email the storage team" is not available in that moment.
7. Which regulation or customer commitment, if any, refuses an online immutable store. CISA's caution is useless if you have not asked whether it applies to you.

State the attacker in one paragraph. A criminal who already holds a domain administrator and the backup console is a different problem from a laptop that encrypted its own profile. The CISA response checklist is written for the larger event: hunt for earlier droppers before you rebuild, then restore from offline encrypted backups onto a clean network. The air-gap claim should name which of those events it is built for.

Risks and limits

• NIST IR 8374 (February 2022) is withdrawn. Current ransomware wording is IR 8374r1. Procedures that still cite the 2022 line "stored offline" miss the 2026 alternative.
• SP 800-61 Rev. 3 does not itself require an offline copy. Use IR 8374r1 when the subject is ransomware.
• SP 800-184 dates from December 2016. SP 800-61 Rev. 3 still points to it. Its examples are scenarios, not measurements from your environment.
• No repository was built or attacked for this article. A vendor brochure is not evidence that your configuration meets the NIST sentence.
• Unplanned disconnection during active writes can interrupt a backup or damage its consistency. Media handling and disconnection require a coordinated procedure; this article supplies none.
• CISA says immutable cloud storage does not meet every regulation. This article does not interpret any particular statute.

Research and verification

This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.

Sources

Independently reopened 13 November 2026.

• CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.
• NIST IR 8374r1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile (June 2026). Supersedes NIST IR 8374.
• NIST IR 8374 (February 2022), withdrawn 11 June 2026. Cited only for the wording that was replaced.
• NIST SP 800-61 Rev. 3 (April 2025). Rev. 2 was withdrawn on 3 April 2025.
• NIST SP 800-184, Guide for Cybersecurity Event Recovery (December 2016).

This article was originally published on 13 November 2026.