What is the difference between an immutable backup and an air-gapped backup?

Immutability is about what can be done to a copy; an air gap is about what can reach it. An immutable copy stays online and readable — which is what makes recovery from it fast — but the storage refuses to alter or delete it until retention expires. An air-gapped copy sits in an environment with no persistent network path to production, connected only briefly and under control while data replicates in. They defend against different things: immutability defeats deletion but not exfiltration, while an air gap defeats reachability but is only as strong as the discipline around the window when the gap closes. Serious designs use both, which is essentially what a cyber-recovery vault is.

What is the difference between object lock governance mode and compliance mode?

Governance mode locks an object against everyone except identities holding a specific bypass permission, who can shorten retention or delete the object outright. It is the right setting when the threat you are managing is accidental deletion. Compliance mode allows no one to shorten or remove the retention — not an administrator, not the root account — until the period expires. That is the setting that survives an attacker who has taken over privileged credentials, and it is the one a ransomware-resilience requirement means. The cost is that mistakes are permanent for the length of the retention, so an oversized or misdirected backup consumes capacity until the clock runs out.

Is WORM tape still relevant when object lock exists?

Yes, for a reason object lock cannot replicate: once written, the cartridge leaves the drive, and a shelf has no network interface. Tape gives you a genuinely offline copy with a physical write-once property, at a low cost per terabyte for data that is retained rather than frequently read, and it survives a compromise of the storage platform itself because there is no platform involved. The trade is recovery speed and operational effort — someone has to handle, label, transport and periodically verify the media. Most estates that take resilience seriously run both: object lock for the fast restore path, tape or removable media for the copy that leaves the building.

How long should the immutable retention period be?

Long enough to outlast the time it realistically takes your organization to detect an intrusion, which is usually longer than people assume — attackers frequently spend weeks inside an environment before they act. If retention is shorter than that dwell time, the immutable copies of the last known-clean state expire before anyone realizes they were the copies that mattered. Because locked data cannot be deleted early, the period is also a capacity commitment, so most estates tier it: a short window applied to everything for fast recovery, a longer lock on a smaller set of critical systems, and a separate archive path for anything with a formal records-retention obligation.

Does immutability mean we no longer need to test restores?

No — if anything it makes testing more important, because immutability guarantees that a copy still exists and says nothing at all about whether it can be turned back into a working system. The failures that surface only under test are the expensive ones: an application set that was never fully in scope, an encryption key held nowhere outside the environment that was encrypted, a restore that completes in four days against a recovery objective of eight hours. CISA's guidance pairs the two deliberately — maintain offline, encrypted backups and regularly test their availability and integrity. Treat an unverified copy as unproven, and record the timings, because that is what turns a recovery objective from an aspiration into a number.

Can ransomware encrypt an immutable backup?

It can encrypt the data on its way in, which is why the copy has to be created from a known-clean state and why detection timing drives the retention period. What it cannot do, where the control is configured correctly, is overwrite or delete the copies already written — the storage layer refuses the operation regardless of the credentials presented. The realistic risks are elsewhere: the lock was set in the bypassable mode, the retention was too short, the immutability policy was administered with the same credentials as the backup jobs, or the backups running into the repository were already carrying the malware. Those are configuration and separation-of-duties questions rather than cryptographic ones.

What Is an Immutable Backup?

By Uniqcli Team

An immutable backup is a backup copy that cannot be modified, overwritten, or deleted until a defined retention period expires — and, critically, one where that refusal is enforced by the storage layer rather than by permissions in the backup application. The distinction is the whole point. A backup an administrator can delete is protected by an access-control decision, and access-control decisions are exactly what an attacker who has taken over the environment gets to make. An immutable copy is protected by a rule the storage itself will not break, for anyone, until the clock runs out.

The reason this became a standard requirement rather than a niche feature is behavioral. Modern ransomware operators do not encrypt production and hope; they spend time inside the network first, and one of the first things they look for is the backup console, because destroying recovery options is what converts an incident into a payment. Backup repositories reachable with the credentials that also administer them are, in that scenario, part of the blast radius. Immutability is the control that takes recovery off the table as something the attacker can negotiate over.

Where immutability is actually enforced

Object lock is the most widely deployed mechanism today. It originated with the S3 API and is implemented by most on-premises and cloud object stores, and it applies a write-once-read-many rule to individual object versions. Two settings do the work: a retention period, which fixes a date before which the object version cannot be deleted or overwritten, and a legal hold, which blocks deletion indefinitely with no fixed end date until it is explicitly removed. The API also defines two retention modes, and the difference between them is the single most consequential configuration choice in this whole area — governance mode allows a sufficiently privileged identity to bypass the lock, while compliance mode allows no one to shorten or remove it, not even the account's root identity, until the retention period expires.

The other mechanisms predate it and are still in use. WORM tape cartridges are physically write-once, which makes them unusually difficult to argue with, and the media leaves the drive entirely once written. Hardened backup repositories apply filesystem-level immutability flags to backup files for a set period so that even root cannot remove them inside the window. Storage arrays and filesystems offer snapshot retention locks that prevent a snapshot from being deleted or rolled back early. And purpose-built recovery vaults combine several of these behind a controlled replication path. What all of them share is the property that matters: the refusal lives below the layer an attacker who owns the backup console can reach.

Immutable, air-gapped, offline: three different words

These terms are used interchangeably and should not be. An immutable copy is online and reachable but cannot be altered — you can read it at any time, which is what makes recovery fast, and you cannot destroy it, which is what makes it useful. An offline copy is unreachable because there is no live path to it at all: a tape on a shelf, a rotated drive in a safe, media in an offsite vault. An air gap is the architectural version of offline, in which the recovery environment has no persistent network path to production and is connected only briefly and under control while data is replicated in.

The confusion is worth resolving because the three fail differently. An immutable copy defeats deletion but not disclosure — an attacker cannot destroy it, but if they have read access they can still exfiltrate from it. An offline copy defeats both but is slow to recover from and depends on somebody physically doing something on a schedule. An air-gapped vault sits between them and is only as strong as the discipline around the window during which the gap is closed, since the replication path is also the path malware would travel. The term "cyber recovery vault" generally describes the combination: a separate environment, an operational air gap, immutable copies inside it, and separate credentials so that owning production does not confer any authority there.

How immutable copies stop being immutable

The most common failure is choosing the permissive mode. Governance-mode object lock is designed to be bypassable by an identity holding the bypass permission, which is entirely reasonable when the threat is accidental deletion and entirely useless when the threat is an attacker holding administrative credentials. Compliance mode is the setting that survives a hostile administrator, and its cost is real and should be understood before it is enabled: nothing can shorten the retention, so data written by mistake, or written at a retention length chosen carelessly, occupies capacity until the clock expires. That trade is the feature working correctly.

The other failures are quieter. Retention periods set shorter than the time it takes to notice an intrusion mean the immutable copies of the last clean state expire before anyone knows they were needed — and dwell time is routinely measured in weeks. A repository whose immutability is configured through the same console, with the same credentials, as the backup jobs is one compromise away from having its policy rewritten. Time is an attack surface of its own where retention is calculated from a clock an attacker can influence. And separate credentials are not separate if they are stored in the directory service that was compromised, or if the same administrator holds both. Immutability is a property of the whole arrangement, not of a checkbox in a job definition.

What the guidance actually says

The joint #StopRansomware Guide published by CISA and its partners is consistently direct on this point: maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of those backups in a disaster-recovery scenario, because many ransomware variants actively seek out and delete any backups they can reach. That single sentence contains both halves of the control — the copy has to be beyond the attacker's reach, and it has to be proven restorable before the day you need it.

On the storage side, NIST SP 800-209, Security Guidelines for Storage Infrastructure, treats immutability as a named capability — the ability to lock data after creation so it cannot be altered or deleted — alongside its recommendations on isolation, restoration assurance, and encryption for storage estates. For the recovery process itself, the NCCoE's NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events, is the practice guide that walks through recovering operating systems, databases, files, and configurations after data has been corrupted. None of these documents endorse a product, and that is the useful part: they describe the properties a design must have, which is the level at which a requirement should be written.

The capacity arithmetic nobody budgets for

Immutable retention changes how storage consumption behaves. Under ordinary retention, capacity is a rolling window and old data leaves as new data arrives. Under a retention lock, nothing leaves early — not test data written by mistake, not an oversized full backup taken during a migration, not the extra copies produced while somebody was tuning a job. The consumption curve is set by the retention period multiplied by the change rate, and it cannot be relieved by deleting things, which is the usual response when a repository fills.

The practical consequence is that the retention period is a budget decision as much as a security one. Too short and the immutable copies of the last known-good state expire before an intrusion is discovered. Too long, applied uniformly across every workload, and the storage cost is several times what anyone approved. Most estates end up tiering it: a short, aggressively immutable window on everything for fast recovery, a longer locked retention on a smaller set of genuinely critical systems, and a separate archive path for anything with a records-retention obligation, which is a different requirement wearing similar vocabulary.

Specifying it, and proving it

A requirement worth writing names four things: which mechanism enforces the immutability and at which layer, whether the mode is the bypassable one or the absolute one, how long the retention lock runs relative to your realistic detection time, and whose credentials govern the lock as distinct from the credentials that run the backups. A specification that says only "backups must be immutable" will be satisfied on paper by a governance-mode bucket that the compromised backup administrator can empty.

Then there is the part that is not a purchase at all. An immutable copy that has never been restored is an assumption, and the failure modes it hides — an incomplete application set, a missing encryption key, a restore that takes four days against a recovery objective of eight hours — surface only under test. Schedule restores, time them, record the results, and treat an unverified copy as unproven. On the hardware side, the shape of the answer is usually a dedicated backup target with object-lock support, a second media type, tape or offline media for the copy that leaves the building, and the capacity headroom the retention lock implies. Uniqcli quotes storage, tape, and the software licensing that governs them through authorized US distribution; sending the retention policy and the recovery objectives alongside the capacity number is what keeps the quote honest.

Key takeaways

An immutable backup cannot be altered or deleted until its retention expires, and the refusal is enforced by the storage layer — not by permissions in the backup application an attacker can take over.
Object lock applies a write-once-read-many rule per object version, with a retention period and an optional legal hold; WORM tape, filesystem immutability flags and snapshot retention locks do the same job at other layers.
Governance mode is bypassable by a privileged identity; compliance mode is not, even by the root account. That choice decides whether the control survives a hostile administrator.
Immutable, offline and air-gapped are different properties: immutable resists deletion while staying online, offline resists everything but is slow, and an air gap is only as strong as the window when it closes.
Retention shorter than realistic intrusion dwell time is the quiet failure — the immutable copies of the last clean state expire before anyone knows they were needed.
CISA's #StopRansomware guidance pairs offline, encrypted backups with regular restore testing; NIST SP 800-209 names immutability as a storage capability and SP 1800-11 covers the recovery process.

Shop it at Uniqcli

Storage arrays Seagate drives Western Digital drives Get a quote

Frequently asked

What is the difference between an immutable backup and an air-gapped backup?: Immutability is about what can be done to a copy; an air gap is about what can reach it. An immutable copy stays online and readable — which is what makes recovery from it fast — but the storage refuses to alter or delete it until retention expires. An air-gapped copy sits in an environment with no persistent network path to production, connected only briefly and under control while data replicates in. They defend against different things: immutability defeats deletion but not exfiltration, while an air gap defeats reachability but is only as strong as the discipline around the window when the gap closes. Serious designs use both, which is essentially what a cyber-recovery vault is.
What is the difference between object lock governance mode and compliance mode?: Governance mode locks an object against everyone except identities holding a specific bypass permission, who can shorten retention or delete the object outright. It is the right setting when the threat you are managing is accidental deletion. Compliance mode allows no one to shorten or remove the retention — not an administrator, not the root account — until the period expires. That is the setting that survives an attacker who has taken over privileged credentials, and it is the one a ransomware-resilience requirement means. The cost is that mistakes are permanent for the length of the retention, so an oversized or misdirected backup consumes capacity until the clock runs out.
Is WORM tape still relevant when object lock exists?: Yes, for a reason object lock cannot replicate: once written, the cartridge leaves the drive, and a shelf has no network interface. Tape gives you a genuinely offline copy with a physical write-once property, at a low cost per terabyte for data that is retained rather than frequently read, and it survives a compromise of the storage platform itself because there is no platform involved. The trade is recovery speed and operational effort — someone has to handle, label, transport and periodically verify the media. Most estates that take resilience seriously run both: object lock for the fast restore path, tape or removable media for the copy that leaves the building.
How long should the immutable retention period be?: Long enough to outlast the time it realistically takes your organization to detect an intrusion, which is usually longer than people assume — attackers frequently spend weeks inside an environment before they act. If retention is shorter than that dwell time, the immutable copies of the last known-clean state expire before anyone realizes they were the copies that mattered. Because locked data cannot be deleted early, the period is also a capacity commitment, so most estates tier it: a short window applied to everything for fast recovery, a longer lock on a smaller set of critical systems, and a separate archive path for anything with a formal records-retention obligation.
Does immutability mean we no longer need to test restores?: No — if anything it makes testing more important, because immutability guarantees that a copy still exists and says nothing at all about whether it can be turned back into a working system. The failures that surface only under test are the expensive ones: an application set that was never fully in scope, an encryption key held nowhere outside the environment that was encrypted, a restore that completes in four days against a recovery objective of eight hours. CISA's guidance pairs the two deliberately — maintain offline, encrypted backups and regularly test their availability and integrity. Treat an unverified copy as unproven, and record the timings, because that is what turns a recovery objective from an aspiration into a number.
Can ransomware encrypt an immutable backup?: It can encrypt the data on its way in, which is why the copy has to be created from a known-clean state and why detection timing drives the retention period. What it cannot do, where the control is configured correctly, is overwrite or delete the copies already written — the storage layer refuses the operation regardless of the credentials presented. The realistic risks are elsewhere: the lock was set in the bypassable mode, the retention was too short, the immutability policy was administered with the same credentials as the backup jobs, or the backups running into the repository were already carrying the malware. Those are configuration and separation-of-duties questions rather than cryptographic ones.

Keep reading

The 3-2-1 backup rule What is continuous data protection?RTO vs RPO What is RAID?Immutable backup and cyber-recovery hardware Immutable backup storage Ransomware recovery