Air-gapped backup: what is actually cut

An air-gapped backup is a copy an attacker cannot reach from the system they have already compromised, because the path between the two has been cut. For tape, that path was a cable and the cut was literal — the cartridge sat on a shelf. For Microsoft 365, Google Workspace, Slack and Atlassian Cloud, nothing sits on a shelf. No copy of your SaaS data is ever physically disconnected from anything. What the market sells as an air-gapped cloud backup is a logical air gap, and the useful question is never "is it air-gapped" but which connection has actually been cut — and whether it is the one your attacker would have used.

The formal definition, and why no cloud backup meets it

The term is older than cloud backup and it has a precise meaning. The NIST glossary defines an air gap as:

An interface between two systems at which (a) they are not connected physically and (b) any logical connection is not automated (i.e., data is transferred through the interface only manually, under human control).

That definition is sourced to CNSSI 4009-2022, itself drawn from IETF RFC 4949. Note that it sets two conditions, and the second is the one everybody forgets: not merely disconnected, but not automatically connected. Data crosses under human control or it does not cross at all.

Measured against that, an automated backup of a SaaS tenant fails on both counts. There is no physical separation to speak of — it is one set of data centres talking to another — and the logical connection is emphatically automated, because automation is the entire point. A backup that depends on someone remembering to run it is a backup that gets skipped in the week you needed it.

So the honest position is this: nothing that backs up Microsoft 365 or Google Workspace on a schedule is air-gapped in the formal sense, and no vendor can make it so. That is not a scandal, and it is not a reason to dismiss the term. It means the word has been borrowed to describe something else — and the something else is genuinely worth having, provided you know what you are being sold.

What "logically air-gapped" means in practice

The borrowed meaning is isolation of the blast radius: the backup is placed somewhere that the credentials, permissions and administrative reach of the compromised environment do not extend to.

AWS Backup's logically air-gapped vault is a useful reference point here — not because AWS is one of the platforms we deal with, but because it is one of the few implementations where the design is documented in enough detail to see what the isolation is actually made of. AWS documents that this vault type:

• stores its backups in an AWS Backup service owned account — not in the customer's own account, which is the isolation itself;
• is always locked with a vault lock in compliance mode, where a standard vault only optionally has one;
• can be shared via AWS Resource Access Manager with individual AWS account IDs, including accounts in a different organization, so that a restore can be driven from somewhere the incident did not touch;
• can be integrated with multi-party approval, to enable recovery of backups even if the vault-owning account is inaccessible;
• enforces a minimum retention floor of seven days, so nothing can be written in with a retention period short enough to age out during an incident.

Read that list again as a list of cuts. Ownership of the storage account: cut. The ability of a local administrator to shorten retention: cut. The dependency on the compromised account being available to perform a restore: cut. None of it involves a shelf, and all of it narrows the blast radius. That is what the word means now.

The four connections an air-gapped backup has to cut

Strip the marketing away and there are four links between a live environment and its backup. A "logical air gap" is a claim that one or more has been severed — so ask which.

1. Identity. Does the backup authenticate with the same directory as the thing it is protecting? If a compromised global administrator can also administer the backup, identity is not cut, and identity is the connection ransomware actually travels down.
2. Control plane. Can the backup's retention, schedule or deletion settings be changed from inside the environment being protected? If yes, an attacker does not need to touch a single backup file — they change the policy and wait.
3. Storage ownership. Whose account holds the bytes? A copy living in the same tenant shares that tenant's fate: a compromise, a lapsed subscription, a billing dispute, a tenant-level failure.
4. The restore path. If recovering requires signing in to the environment you just lost, the copy is intact and useless. This is the connection most often left joined, and the one an incident exposes first.

The worked example: where Microsoft 365 Backup sits

Microsoft's own documentation makes this concrete, and to Microsoft's credit it is stated plainly rather than buried. Of the Microsoft 365 Backup add-on, Microsoft writes that "your data remains securely within your organization's tenant", and that "all data within Microsoft 365 Backup is stored within the customer tenant for any given service and follows the standard Microsoft 365 data storage guidelines by available geography."

For data residency, that is exactly what a European buyer wants to hear — the backup cannot drift outside the geography the tenant is committed to. For isolation, it is the opposite of an air gap, and the same page says why: "Microsoft 365 Backup works with and integrates into Microsoft 365. This means that the Microsoft 365 security capabilities — such as identity and app management — apply to Microsoft 365 Backup." The backup inherits the identity plane of the thing it is backing up. Connections one, three and four above are joined by design, and the second is only partly cut.

Microsoft does cut one of them, and it deserves credit for it. The documentation notes that because compliance tooling can destroy primary data, those destructive actions are administratively isolated from flowing through automatically — "compliance actions that automatically delete your primary data will not automatically delete data from your backups." That is a real logical gap. It is narrow, it addresses accidental and policy-driven destruction rather than a hostile administrator, but it is the genuine article, and it is more than the other three platforms offer.

The rest of the native picture is consistent with this. The OneDrive and SharePoint recycle bin lives inside the tenant and can be emptied by a sufficiently privileged account. Google Workspace's administrative restore window is an administrative function, available to administrators, and Vault states outright that it exports rather than restores — the four available routes are set out separately. A Slack or Atlassian export is a point-in-time file: whatever isolation it has is whatever you give the destination you put it on, which at least means the gap is yours to create.

Air gap and immutability are not the same control

These two words get used interchangeably in sales material and they answer different questions.

• Immutability is about enforcement: can this copy be deleted before its retain-until date, and by whom? We covered what the word does and does not guarantee in immutable backup.
• An air gap is about topology: where does this copy live, and what can reach it?

You can have either without the other, and both failure modes are real. An immutable copy inside the compromised tenant survives deletion but shares the tenant's fate. An isolated copy with no retention enforcement sits somewhere safe and can still be wiped by whoever administers the place it sits. The combination is what people mean when they say a backup is ransomware-resilient — and whether cloud backup protects against ransomware at all turns almost entirely on whether both are present.

Five questions that get you a real answer

1. Which of the four connections is cut? Ask for it in those terms. A vendor who answers "it's air-gapped" has not answered.
2. Whose account holds the data? If the answer is "yours", the isolation is organisational, not architectural.
3. Can I restore without the compromised environment? Have them describe the restore path on the assumption that your tenant is unavailable and your administrator account is untrusted.
4. Who can change the retention policy, and from where? If that can be done from inside the environment being protected, the control plane is joined.
5. When did you last test a restore that way? Not a restore — a restore under those conditions. The two are different exercises and only one of them tells you anything.

The fifth question is the one that separates a design from a capability. An isolated copy you have never restored from is an assumption, and an incident is a poor place to test an assumption.

Where we fit

We are not the platform and we do not run your tenant. What we do is establish what your actual recovery requirement is — which workloads carry real risk, how independent the copy genuinely needs to be, which of those four connections your threat model demands you cut, and what your compliance position requires on residency — then help you choose the right fit for your stack and get it deployed and running. You own and operate it from there.

If you would rather see where your backups sit on that map than take a vendor's word for the adjective, a recovery assessment walks your workloads, your current native windows and your restore path, and shows you which connections are still joined.