An administrator at a mid-sized manufacturing company answers the ransomware question in one sentence: „we have immutable copies on the array”. The follow-up question is always the same: does the account he uses to manage production allow the retention period of those copies to be shortened? If it does, the mechanism protects against an operator’s mistake, not against the attacker who took that account over three weeks ago and has been quietly looking around ever since.
This text separates three things that blur into one in backup conversations: a property of the medium, an administrative boundary and a recovery procedure. Every claim about the mechanism is backed by a document with a publication date, because the difference between „it cannot be deleted” and „it cannot be deleted with this account” decides whether the company gets back to work. We do not compare products — we describe a mechanism that looks the same at every vendor and is merely named differently.
How does an immutable copy differ from a snapshot and from an offline copy?
In three respects: where it sits, whose authority it answers to and how quickly it is reachable. A snapshot is a point in time inside the same storage system — it shares its hardware, its console and usually its administrative accounts as well. It is the fastest way to undo a change and the weakest protection against someone who holds rights to that console.
An offline copy has no network path to the production environment, so malicious software cannot reach it. The #StopRansomware Guide (CISA, FBI, NSA and MS-ISAC, version 3.0 of October 2023) opens its list of practices with the recommendation to „maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario”. The price is obvious: the medium has to be attached, and that costs time in the hour when there is none.
An immutable copy is the compromise between the two. It is reachable over the network like a snapshot, yet locked against change like a tape in a safe. NIST, in publication SP 800-209 „Security Guidelines for Storage Infrastructure” (October 2020), defines immutability as follows: „Immutability involves the ability to lock data after it has been created, thereby preventing it from alteration or deletion”. The definition speaks about the data — not about the policy that governs the lock, and that is the whole difficulty of this subject.
Box: a snapshot protects against an error in the data, an offline copy against network access, an immutable copy against deletion. Those are three different threats. Picking one of the three as „the best one” is a badly posed question — they complement one another rather than substitute for one another.
What exactly does the immutability mechanism block?
It blocks writing to and deleting the data within the declared retention window — and nothing more. Technically this is implemented by the WORM family (write once, read many), by object locking in object storage and by retention policies in backup software. NIST SP 1800-11 „Data Integrity: Recovering from Ransomware and Other Destructive Events” (final version, September 2020, NCCoE) describes secure storage as a capability that „provides the capability to store data with additional data protection measures, such as Write Once Read Many (WORM) technologies or data encryption”.
What the mechanism does not block is a change to the policy itself. A retention period is a configuration, and configuration is managed by someone. Recommendation IS-SS-R10 in NIST SP 800-209 lists immutable storage — retention locking, vault locking, immutability policies — as a measure that „could help further isolate and protect recovery data”. The word „further” is the crucial one here: the publication places it as the tenth recommendation after nine concerned with isolation, not instead of them.
There is a single design consequence. The question „do we have immutable copies” is about a product feature; the question „who, and from which account, can shorten retention” is about security. The answer to the first is often yes in companies where the answer to the second is „the domain administrator”.
Why does a copy inside the same authentication domain not protect against ransomware?
Because the attacker does not break the mechanism — he logs into it. The #StopRansomware Guide records this plainly: „Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions; they also use publicly available exploits to target unpatched backup solutions”.
NIST SP 800-209 answers this with recommendation IS-SS-R2, the sharpest sentence in the whole publication on this matter: „Storage systems that store cyber-attack recovery copies should be managed from designated management systems, which are separated from the production environment, and any other system connected to production (including data protection mechanisms). It should not be possible to access such management systems with regular credentials (including production and regular backup)”.
Recommendation IS-SS-R3 spells out why: „This ensures that if the credentials of an IT admin are compromised, the attacker cannot use those credentials to access the cyber-attack recovery copies”. This is not an aesthetic postulate — it is the only property that distinguishes a copy resistant to an attack from a copy resistant to a failure. The same conclusion underpins zero trust architecture: NIST SP 800-207 (August 2020) states in its third tenet that „authentication and authorization to one resource will not automatically grant access to a different resource”.
Which layers have to be separated for immutability to mean anything?
Three, and NIST SP 800-209 names them as separate recommendations. The first is the medium and the system: under IS-SS-R1, „cyber-attack recovery copies should be created on designated separated storage environments. In private clouds, this implies physically separated storage systems. In public clouds, this implies separate accounts (or equivalent)”. The second is the management console (IS-SS-R2, discussed above). The third is credentials (IS-SS-R3): access to recovery copies belongs to a narrow group using credentials other than those used for day-to-day duties.
Two further recommendations are the ones projects forget most often. IS-SS-R4 requires that „cyber-attack recovery copies should be stored off-site rather than where the production data is stored”. IS-SS-R5 forbids recovery copies from depending on production baseline data — which cuts straight through the popular pattern in which an entire incremental history hangs on a single full backup standing next to production.
There is one more layer that no diagram shows: the way restoration is performed. Under IS-SS-R7, „cyber-attack recovery copies should not be mounted, exported, or mapped to a host or application, and they should be restored (pushed) onto an isolated staging (or air-gapped) environment rather than directly onto the target hosts or applications”. An immutable copy mounted as a disk on an infected server stops being isolated, even though it remains immutable.
Who can shorten the retention period, and why is that the right question?
Because it is the only question whose answer can be verified rather than declared. An immutable repository is worth exactly as much as its administrative boundary — the same conclusion we noted when writing about Veeam’s acquisition of Object First, where assessing an appliance comes down to who can change the policy and from where, not to what the mechanism is called.
In a typical deployment there are three answers, and they differ by an order of magnitude in risk. Retention may be shortened by the production domain administrator account — in which case the protection is illusory. It may be shortened by a separate account in the backup system authenticated in the same domain — in which case protection ends the moment the domain controller is taken over. Or nobody may shorten it before the deadline, and changing the policy requires two people holding credentials from outside production — and only that matches recommendations IS-SS-R2 and IS-SS-R3.
The question applies to the supplier as well: if the copy sits in the cloud, the administrative boundary is the account in that cloud; if it sits in an appliance in the server room, it is the vendor’s service account. A design that does not describe those paths describes only part of the arrangement. Designing that boundary and the recovery procedure falls within the scope of comprehensive backup services.
Is an air gap the same thing as immutability?
No, even though both words appear in the same sentence of a proposal. Recommendation IS-SS-R8 in NIST SP 800-209 distinguishes two levels: „Strict implementations of air-gapping should provide full physical and network-level separation”, whereas „certain storage technologies also introduce less strict isolation technologies, also referred to as ‘air-gapping’ that enable shutting down data ports and opening them during a limited time for the periodic sync with the production system”.
The difference is practical, not terminological. An air gap takes away the attacker’s path of access for most of the time window; immutability takes away his right to change the data at the moments when he does have a path. A mechanism with periodically opened ports combines both weaknesses if the synchronisation window is driven from production.
The publication recommends weighing the effectiveness of each technique „based on the value of the data and the capabilities of the adversary”, and for strict implementations it lists threats that are easy to forget: signalling channels, wireless transmission capabilities of the equipment and exposed data ports. Separately, on why detaching copies from production infrastructure is a requirement in its own right, we write in the text about the 3-2-1 backup rule.
What does immutability not solve?
Three things, each of which can wreck a recovery. First — data leakage. An immutable copy guarantees that the data will be there, not that it will not be copied out. The double-extortion model, in which the attacker first exfiltrates and only then encrypts, is entirely indifferent to immutability.
Second — time. Immutability does not shorten restoration; it can even extend it if the copy sits in low-cost object storage with low read throughput. Recommendation RA-SS-R4 in NIST SP 800-209 states that the ability to meet recovery time objectives „should be examined holistically, including all dependent and related components” — rather than being measured by the speed of the medium alone.
Third — the cost of a configuration error. The #StopRansomware Guide frames this as a warning: „Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost”. A retention lock set to three years instead of thirty days is irreversible by definition — and billed every month. We break the bill for the recovery itself into line items in the text on how much ransomware costs a company.
What else has to be in the copy for recovery to be possible at all?
Considerably more than user files and databases. Recommendation RA-SS-R1 lists the elements that must be protected for post-attack recovery to be feasible — in the original these are „storage volumes, critical file systems, databases, software images, certificates, encryption keys, startup files, catalog info, ACLs, virtualization settings, and configuration files”.
RA-SS-R2 adds dependent components — it names „Active Directory and DNS, external key management systems” explicitly — without which restoring the data does not restore a working service. This is the most frequent gap we see during reviews: the copy covers the business data and does not cover what makes it possible to authenticate and address that data.
RA-SS-R9 adds a requirement that changes how the design is drawn: „The data should be separated from the application to allow for the data to be restored without restoring infected code or software”. A copy of a virtual machine image from before the attack is sometimes a copy of an already compromised machine — and then recovery restores the attacker’s starting position.
How do you check in your own environment whether the copies are genuinely immutable?
In four steps, none of which requires a project or board approval — a maintenance window and two people are enough. This is the procedure we run on entry to reviews of backup environments, before the question of a target architecture is even raised.
Step one: attempt to shorten retention. From a production environment administrator account, try to change the retention policy on the copy repository. If the operation succeeds, or even merely appears as available in the interface, the mechanism does not satisfy IS-SS-R2 and protects against a mistake, not against an attack.
Step two: a test restore into an isolated environment. RA-SS-R5 requires a periodic test restore confirming that it completes successfully and fits within the required timeframe. Push the copy into a staging environment, not onto the production target (IS-SS-R7), and measure the time — do not copy it from a datasheet.
Step three: a check of the full set of dependencies. Using the lists from RA-SS-R1 and RA-SS-R2, verify that the copy covers the directory service, DNS, keys and configurations. Restoring a database without authentication restores a file, not a service.
Step four: copy hygiene. RA-SS-R11 recommends scanning recovery copies with anti-malware and analytics tooling and, where the full set is too large, scanning a subset while keeping a record of which copies were scanned. Without that step there is no way to know which version to restore. That same restore test is at once the hardest piece of audit evidence — we write about it in the text on ransomware prevention strategies.
How often should isolation and the health of the copies be verified?
At least once a year, and more often for sensitive data. Recommendation IS-SS-R9 requires periodic isolation reviews at least once per year; for sensitive and high-value storage systems it states that they „may require at least a quarterly audit, and after every major change - whichever comes first”. The results of the review are to be documented.
The health of the copies runs on a separate clock. RA-SS-R8 requires periodic confirmation that the copies are in good health — no relevant logged errors, media in a healthy state — no less than once per year, and as a starting point it proposes „keeping the sample ratio around 1 – 1.5 orders of magnitude lower than the frequency of backup”.
It is worth setting this against the requirement of CIS Critical Security Control 11 „Data Recovery”, which at the level of its objective is short: „Establish and maintain data recovery practices sufficient to restore in-scope enterprise assets to a pre-incident and trusted state” (CIS website, read on 18 September 2026). The word „trusted” does all the work here: restoring the pre-incident state is not enough if that state already contained the attacker’s implant.
Where should you start, depending on what you already have?
By recognising which of the levels below your current arrangement sits on. The table that follows is a decision tool: the middle column describes an observable state rather than a vendor’s declaration, so every row can be checked within a single maintenance window.
| Current state | How to recognise it without a project | First step | Source recommendation |
|---|---|---|---|
| Copies with no lock | retention policy editable from the backup console with no additional authentication | enable a retention lock on the recovery copy repository | IS-SS-R10 |
| Lock in place, shared accounts | the domain administrator account sees the repository and can change the policy | separate the management console and the credentials from outside production | IS-SS-R2, IS-SS-R3 |
| Accounts separated, no test | nobody can give the date of the last test restore | schedule a restore into an isolated environment and measure the time | RA-SS-R5, IS-SS-R7 |
| Test in place, scope incomplete | the copy is missing the directory service, DNS or the keys | extend the scope to dependent components and repeat the test | RA-SS-R1, RA-SS-R2 |
| Everything above works | there is a date for the isolation review and for the scanning of copies | set a review cadence and document the results | IS-SS-R9, RA-SS-R8, RA-SS-R11 |
The order matters. Enabling a retention lock while accounts remain shared gives a sense of security without adding any, and along the way it can lock up capacity for years. Only the full set — the lock, separated accounts and a measured test — turns the sentence „we have immutable copies” into a claim defensible before an auditor and before an attacker.
Closing box: the one question to ask tomorrow is: from which account and from which console can our retention be shortened today? „I don’t know” is an answer too — and it is the most common one.
Designing the administrative boundary around the copies, selecting the mechanism and running the restore test is a single engagement within our backup and disaster recovery services. Immutability mechanisms in a Veeam environment are covered separately in the text on the Veeam Backup & Replication platform — that one is about the implementation at a single vendor, this one about a property of the arrangement that is independent of the product name.
Sources cited in this text: NIST SP 800-209 „Security Guidelines for Storage Infrastructure” (October 2020); NIST SP 1800-11 „Data Integrity: Recovering from Ransomware and Other Destructive Events” (final version, September 2020, NCCoE); NIST SP 800-207 „Zero Trust Architecture” (August 2020); #StopRansomware Guide (CISA, FBI, NSA, MS-ISAC, version 3.0, October 2023); CIS Critical Security Control 11 „Data Recovery” (read on 18 September 2026).
Frequently asked questions
What is an immutable backup and what does it actually protect against?
It is a copy written in such a way that, once created, it cannot be altered or deleted before the declared retention period expires. NIST, in publication SP 800-209 „Security Guidelines for Storage Infrastructure" (October 2020), defines it as follows: „Immutability involves the ability to lock data after it has been created, thereby preventing it from alteration or deletion". That protects the copy from deletion — but only to the extent that the person or process able to shorten retention is separated from the production environment. If one and the same account manages production and the retention policy, the mechanism protects against a mistake, not against an attacker.
Is an immutable copy in the cloud enough to stop worrying about ransomware?
No. The #StopRansomware Guide (CISA, FBI, NSA and MS-ISAC, version 3.0 of October 2023) warns: „Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost". The same guide records that ransomware actors „often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions". Immutability is one of the conditions, not the whole answer.
Are an air gap and immutability the same thing?
No. NIST SP 800-209, in recommendation IS-SS-R8, distinguishes two levels: „Strict implementations of air-gapping should provide full physical and network-level separation", while „certain storage technologies also introduce less strict isolation technologies, also referred to as 'air-gapping' that enable shutting down data ports and opening them during a limited time for the periodic sync with the production system". An air gap takes away the attacker's path of access; immutability takes away the right to change data he can reach. The same recommendation requires weighing the effectiveness of each technique „based on the value of the data and the capabilities of the adversary".
How do I check whether the copies in my company are genuinely immutable?
The shortest verifiable test is an attempt to shorten retention from a production administrator account — if it succeeds, the mechanism does not protect against that account being taken over. The second step is a test restore, because NIST SP 800-209 in section 4.8 requires organisations to verify that critical data assets „can be restored faithfully, consistently, and completely" — not merely that copies are being produced. The third is checking whether the copy covers dependent components: the directory service, DNS, encryption keys and configuration files. Without them, restoring the data does not restore the service.
