Immutable backup vs air gap: what it is and what to ask

Immutable backup and an air gap are not the same protection, even though the terms get used interchangeably. An immutable backup is a stored copy locked so it can't be altered or deleted for a period you set; an air gap is a copy separated from the network — usually from your admin credentials too — so an attacker with valid logins still can't reach it. Confusing the two matters, because a locked retention setting and a disconnected copy protect against different failure modes.

What is immutable backup?

"Immutable backup" describes a specific technical control, not a marketing claim. Azure, AWS, and Veeam each let you configure how long a stored recovery point must remain untouched — but whether that lock holds even against an administrator, not just an outside attacker, depends on the mode or state chosen, not on the feature name alone. Microsoft's documentation for Azure Backup puts it plainly: an immutable vault can help you protect your backup data by blocking any operations that could lead to loss of recovery points, and you can additionally lock the immutable vault setting to make it irreversible and use WORM (write once, read many) storage for backups, to prevent any malicious actors from disabling immutability and deleting backups.

Azure and AWS both use WORM (write once, read many) language — Azure ties it to the "Enabled and locked" state, and AWS describes Vault Lock as providing WORM (write-once, read-many) configuration for all the backups you store and create in a backup vault. Veeam's hardened-repository documentation doesn't use the term WORM, but describes the same result on its own terms. None of the three change who can log in to the console — they change what that console will let anyone do to recovery points already stored.

Immutable backup vs air gap: what's actually different

An air gap is a separate idea: a copy of your data disconnected — physically, logically, or by identity — from the systems and accounts that manage day-to-day backups. None of the three vendor pages we read for this post use the phrase "air gap" at all; it's an architecture decision layered on top of whichever immutability feature you're using, not a setting inside it.

The practical difference shows up in a compromised administrator account. Immutability protects locked recovery points against that account trying to delete them directly — AWS states that in any locked vault, regardless of mode, if any user (including the root user) attempts to delete a backup or change the lifecycle properties in a locked vault, AWS Backup will deny the operation. What immutability alone doesn't stop, in governance mode, is that same account removing the lock configuration itself — AWS says a vault locked in Governance mode can be managed or deleted by users who have the appropriate IAM permissions. An air gap closes that gap by putting the copy out of reach of the account entirely, not just out of reach of a delete command.

Immutable backup vs offline backup

"Offline backup" usually means the same thing as an air gap — a copy kept disconnected from a live network between jobs. None of the sources for this post address offline media directly; Azure, AWS, and Veeam's documentation all describe cloud- or disk-based immutability, not tape or disconnected removable storage. If a compliance requirement specifically calls for an offline or air-gapped copy, a locked cloud vault or hardened repository doesn't automatically satisfy it.

What Azure locks: immutable vault states and locking

Azure Backup's immutable vault setting has three states, and the difference is the whole point. "Disabled" means no immutability. "Enabled" blocks operations that could lose recovery points, but the setting itself is reversible: Enabling immutability is a reversible operation for a vault. However, you can choose to make the operation irreversible. The third state, "Enabled and locked," is the one Microsoft frames as protection against bad actors, not just accidents: locking exists to prevent malicious actors from disabling the vault and performing destructive operations, and once locked, the immutable vault setting is now locked and can't be disabled. Immutability locking is irreversible. Until that extra, deliberate step, an Azure immutable vault is a setting an administrator — or an attacker who has taken over that session — can still turn back off.

The retention restriction isn't limited to locked vaults — Microsoft ties it to immutability generally: any actions that reduce the retention period in a backup policy are disallowed on an immutable vault. You can still increase retention, and still stop protecting an item while keeping its recovery points until they expire. One exception: if immutability is enabled for a specific duration rather than tied to policy retention, retention can be reduced only up to the configured immutability duration, and not to a value lesser than it.

What AWS locks: Backup Vault Lock governance mode vs compliance mode

AWS Backup Vault Lock offers two modes, and they answer "who can shorten retention" differently. Governance mode is intended to allow a vault to be managed only by users with sufficient IAM privileges — a privileged administrator, or an attacker who compromised those credentials, can still remove the lock. Compliance mode is built for the opposite case: once created, AWS states it is immutable, meaning the lock cannot be removed, subject to a "cooling-off period" (grace time) of at least three days, during which you can still change or remove it. After grace time ends, AWS is explicit: the vault and its lock are immutable and cannot be changed or deleted by any user or by AWS. One caveat: a locked vault doesn't survive an unrecovered account closure — if a closed account isn't reopened within 90 days, AWS deletes the contents of your backup vault, even if AWS Backup Vault Lock was in place.

What Veeam locks: hardened repository immutability period

Veeam's hardened repository takes a similar approach on the storage side rather than the cloud-account level: you add a Linux server as a hardened repository and set an immutability time period, and during this period, backup files stored in this repository cannot be moved, modified or deleted, but can be copied. It also supports single-use credentials for setup, used only once to deploy Veeam Data Mover and not stored in the backup infrastructure — so that even if the Veeam Backup & Replication server is compromised, the attacker cannot get the credentials and connect to the hardened repository. That's Veeam addressing whether the immutable copy sits behind the same admin identity as your everyday backup server; Azure's and AWS's pages don't discuss credential separation in the same terms.

One version note if you run Veeam Backup & Replication 12: per Veeam's product lifecycle page, v12 (released February 2023) reached End of Fix in November 2025 and is scheduled for End of Support and Security Fix in February 2027. End of Fix means no further Updates, Patches or Hotfixes will be created for it, though the version is still fully supported until End of Support, when it will no longer be supported by Veeam and does not receive security updates anymore. Worth checking against your immutability retention windows if you're on v12.

An example of why the distinction gets tested

This isn't hypothetical. Infosecurity Magazine reported on September 24, 2026, that a newly identified ransomware group, n0n, tracked by researchers at CyberXTron, has explicitly threatened backup infrastructure: per the report, the group's attacks also make explicit threats to encrypt or destroy backups and shadow copies of data, alongside stealing and threatening to leak data. CyberXTron told the magazine that organizations should treat n0n as an active and credible double-extortion threat requiring prompt attention to credential hygiene, access monitoring, and backup isolation. One recent example, not a comprehensive threat assessment — but "backup isolation" is the air-gap half of this post's argument, not the immutability half.

Questions to ask your provider or team about any immutable backup solution

• Who can shorten retention, and under what mode? On an Azure vault that's "Enabled" but not locked, or an AWS vault in governance mode, someone with the right permissions still can.
• Is the lock itself irreversible, or just the retention it enforces? Azure's "Enabled and locked" state and AWS compliance mode, past its grace period, are described as irreversible. Governance mode and an unlocked Azure vault are not.
• Is there a copy reachable by a different admin identity than your main backup console? Veeam's single-use credential model exists so a compromised backup server can't reach the hardened repository. Azure's and AWS's documentation don't address credential separation in the same terms — ask directly where the immutable or air-gapped copy sits relative to the credentials that run your everyday backups.
• When was the last full test restore? None of the sources for this post address restore testing. See our companion post on restore testing for regulated environments.

The same questions tend to surface in cyber insurance underwriting — see cyber insurance readiness for the mid-market. And if "who can reach this" traces to your provider's own remote-management tooling, read what to ask your provider about RMM access — an immutable vault doesn't help much if the account managing it has tier-0 access to everything else.

Sources

• Microsoft Learn — Concept of Immutable Vault for Azure Backup (retrieved September 27, 2026)
• AWS Backup Developer Guide — AWS Backup Vault Lock (retrieved September 27, 2026)
• Veeam Help Center — Hardened Repository, Veeam Backup & Replication User Guide (retrieved September 27, 2026)
• Veeam — Product Lifecycle Policy (retrieved September 27, 2026)
• Infosecurity Magazine — "Emerging Ransomware Gang Uses Backup Destruction Threats to Pressure Victims," September 24, 2026 (retrieved September 27, 2026)

The 30-second version

Immutable backup and an air gap protect against different failure modes, and none of Azure's, AWS's, or Veeam's documentation uses the term "air gap" at all. Immutability locks a stored recovery point — Azure's "Enabled and locked" state, AWS Vault Lock in compliance mode past its grace period, or a Veeam hardened repository's immutability window — so it can't be deleted or modified through the normal management path, even by an administrator; weaker states and modes (Azure "Enabled," AWS governance mode) stay reversible by someone with the right permissions. An air gap separates the copy from the network and, ideally, from the same admin identity, which is what stops a fully compromised account from reaching it at all. Before trusting either one, confirm who can still shorten retention, whether the lock is actually irreversible yet, whether a copy exists outside your main admin identity, and when someone last proved it with a real test restore.

If you want a senior engineer to review how your current backup platform's immutability settings are actually configured — not just whether the feature is turned on — the project intake form takes about three minutes. We'll come back with scope and a fixed-fee range.

Pro IT NW helps regulated mid-market organizations design, implement, and test backup and disaster recovery for Microsoft 365, Azure, AWS, on-premises, and hybrid environments. Vendor-neutral, labor-only — we don't resell backup software. This post reflects Microsoft, AWS and Veeam documentation as read on September 27, 2026.