What happens when an attacker with stolen admin credentials tries to delete your backups? If the answer is “nothing, because they can’t,” you have immutability. If the answer is “they’re gone,” you have a very expensive lesson. The difference between those two outcomes comes down to specific configurations, and the examples below show what they actually look like in practice.
Backup immutability means backup data cannot be altered or deleted during a defined retention period, even by someone with full administrative rights. That last clause is the whole point. Traditional backups protect against hardware failure. Immutable backups protect against the person holding the keys.
Why “Admin-Proof” Is the Only Definition That Matters
Most ransomware playbooks now target backups first. Attackers escalate privileges, find the backup console, and wipe recovery points before encrypting production systems. A backup that a domain admin can delete is not a real backup in this threat model. It is a second copy of the problem.
The practical test is simple: can the person with the highest level of access delete this backup before the retention clock runs out? If yes, it is not immutable. This distinction separates genuine protection from marketing language, and it is worth applying ruthlessly when vendors demo their products.
It also explains why air-gapped copies, offline tapes, and object-lock storage keep appearing in the same conversations. They all share one property: a layer of separation between the person and the delete button.
Example 1: S3 Object Lock in Compliance Mode
Amazon S3 introduced Object Lock in late 2018, and it remains the reference implementation for cloud-native immutability. You enable it at bucket creation, then apply a retention period to individual objects. In compliance mode, no user, including the root account of the AWS organization, can delete or overwrite a locked object until the retention date passes. Governance mode is weaker because users with special permissions can bypass it.
A typical configuration looks like this in practice:
| Setting | Typical value | Why it matters |
|---|---|---|
| Retention mode | Compliance | No bypass, not even by root |
| Retention period | 30 to 90 days | Covers the window between compromise and detection |
| Legal hold | Off by default | Used for investigations, not routine backup |
| Versioning | Enabled | Required for Object Lock to function |
The common mistake here is setting a 7-day retention because it feels safer for costs. Ransomware dwell time often exceeds that. If an intrusion sits undetected for three weeks, a 7-day lock expires before you need it. Security teams generally recommend retention windows that comfortably exceed your realistic detection time.
Example 2: Azure Immutable Blob Storage
Microsoft’s equivalent lives in Azure Blob Storage under immutable storage policies. Two variants exist: time-based retention, which blocks modification for a set number of days, and legal hold, which persists until someone clears it explicitly. Both operate at the container level, which makes them straightforward to apply across an entire backup repository.
A pattern that works well: one container per workload, a time-based policy of 60 to 180 days, and a locked policy that prevents anyone from shortening the retention period after the fact. That last step matters. A policy with locking disabled can be edited by a privileged user, which quietly reintroduces the exact risk you were trying to eliminate.
Practical tip from teams running this at scale: test the policy on a non-production container first. Locking a policy is intentionally irreversible, and organizations have locked themselves out of deleting test data they genuinely needed to remove.
Example 3: Google Cloud Storage Bucket Lock
Google Cloud takes a slightly different route. You apply a retention policy to a bucket, then use Bucket Lock to make that policy permanent. Once locked, objects cannot be deleted or replaced until their retention period expires, and the policy itself cannot be removed or reduced. (Write once read many (WORM))
The nuance worth knowing: Bucket Lock is a one-way door. Google’s documentation is explicit that locking cannot be undone. That makes it excellent for compliance-driven retention and dangerous for teams experimenting without a plan. The safe sequence is to set the policy, run it with locking disabled for a trial period, verify your lifecycle rules and costs behave as expected, then lock.
Example 4: Hardened Backup Repositories in Enterprise Platforms
Vendors like Veeam, Rubrik, and Cohesity all market immutable repositories, and the mechanics differ enough that the label alone tells you little. Veeam’s hardened repository approach uses Linux-based storage with immutability flags set per job, combined with single-use credentials so the backup server cannot delete its own data. Rubrik and Cohesity build immutability into their appliance architecture, often with a retention lock enforced below the administrative layer.
The evaluation question to ask each vendor: which account, exactly, would have to be compromised to delete a recovery point early? If the answer is “the one our backup admins use daily,” the immutability is partial. If the answer is “nobody, until the date passes,” you have the real thing.
Example 5: The 3-2-1-1-0 Rule as a Design Pattern
The classic 3-2-1 rule (three copies, two media types, one offsite) has been extended to 3-2-1-1-0: three copies, two media types, one offsite, one offline or immutable, and zero errors on restore verification. That fourth “1” is where immutability enters the architecture conversation.
In practice, a mid-sized organization might run:
- Production data on primary storage.
- Nightly backups to an on-premises repository with a 30-day immutable window.
- Weekly copies to cloud object storage with Object Lock in compliance mode for 90 days.
- Quarterly archive to tape, stored offline, rotated offsite.
Each layer assumes the previous one might fall. That redundancy of protection, rather than redundancy of copies alone, is what makes the design resilient. For teams also protecting personal or creative archives, the same logic applies at smaller scale, and the approach in these best photo backup solutions follows similar principles of multiple independent copies.
Where Immutability Fits in a Broader Backup Stack
Immutability is one control, not a strategy. It pairs naturally with offline media, tested restores, and segmented credentials. The CISA StopRansomware Guide recommends maintaining offline, encrypted backups and testing restoration procedures, which is a useful reminder that an immutable backup nobody has ever restored is an unverified assumption.
Hardware choices matter too. Teams running local infrastructure often pair immutable cloud repositories with on-site power and storage resilience, and the considerations in this guide to the best home generators for reliable backup power apply to small offices protecting the same data. For remote or off-grid sites, solar generators for home backup power cover a similar need. Physical storage still matters as well, and these picks for the best external hard drives for backup are relevant for the offline copy in a 3-2-1-1-0 design.
Automation is the other half. Increasingly, teams use tooling to verify immutability settings continuously rather than trusting a one-time configuration. The same trend shows up in operational monitoring, where AI agent examples and applications increasingly include automated compliance checks that flag a repository whose lock has silently expired.
Common Mistakes That Undo Immutability
Several failure patterns show up repeatedly across organizations that believed they were protected:
- Governance mode chosen by default. It is easier to administer and offers far weaker protection. Compliance mode exists for a reason.
- Retention shorter than detection time. A 14-day lock against a 30-day dwell time is decoration.
- Immutability applied to the wrong layer. Locking the storage but leaving the backup catalog editable means an attacker can orphan every recovery point without deleting a single object.
- Credentials shared between production and backup. Single-use or segregated accounts are not optional extras; they are the mechanism that makes immutability meaningful.
- No restore testing. Immutable data that fails to restore is a very secure pile of unusable bytes.
The pattern behind all five is the same: immutability was treated as a checkbox rather than an architectural property. The organizations that get it right design the whole chain, from credential separation to restore drills, around the assumption that the attacker will eventually hold admin rights. (NIST Cybersecurity Framework)
How to Verify Immutability Actually Works
Configuration is not proof. The only convincing evidence is a test in which someone with elevated privileges attempts to delete a protected recovery point and fails. Run that test deliberately, document the result, and repeat it quarterly.
A practical verification checklist:
- Attempt deletion from the backup administrator account. It should fail with a clear retention error.
- Attempt deletion from the cloud root or global admin account. In compliance mode, it should also fail.
- Attempt to shorten or remove the retention policy. It should be blocked.
- Restore a sample workload from the immutable copy and record the time taken.
- Confirm alerting fires when a deletion attempt is blocked, because that signal often reveals an active intrusion.
That fifth point is underrated. A blocked deletion attempt is one of the clearest early indicators of compromise available, and many teams never wire it into their detection pipeline.
Conclusion
Backup immutability is less about a product feature and more about a single design question: who can delete this data before the retention date, and why should they be able to? S3 Object Lock in compliance mode, Azure immutable blob policies, Google Cloud Bucket Lock, and hardened enterprise repositories all answer that question differently, but the good configurations share one trait. They remove the delete button from everyone, including the people who built the system.
Start with a retention window longer than your realistic detection time. Separate the credentials. Lock the policy only after testing. Then prove it works by trying to break it yourself, on purpose, before someone does it for you.
Frequently Asked Questions
What is backup immutability in simple terms?
Backup immutability means stored backup data cannot be changed or deleted for a set period, even by an administrator with full access. It protects recovery copies from ransomware attackers who compromise privileged accounts and try to destroy backups before encrypting production systems.
Is compliance mode always better than governance mode?
For ransomware defense, yes. Compliance mode cannot be bypassed by any account, including the cloud root user, until retention expires. Governance mode allows users with special permissions to delete data early, which reintroduces exactly the risk immutability is meant to remove. Governance mode suits testing and development environments.
How long should an immutable retention period be?
Long enough to exceed your realistic detection time, which for many organizations means 30 to 90 days rather than the 7 to 14 days teams often choose for cost reasons. If an intrusion can sit undetected for three weeks, any lock shorter than that provides no protection at the moment it matters.
Does immutability replace air-gapped or offline backups?
No. They solve overlapping but distinct problems. Immutability blocks deletion through software controls, while offline and air-gapped copies remove network access entirely. A strong design uses both, alongside tested restores, because each layer assumes the previous one might fail.
Can immutability be undone once it is enabled?
It depends on the platform. Google Cloud Bucket Lock and locked Azure retention policies are intentionally irreversible until the retention period ends. AWS Object Lock in compliance mode cannot be shortened either. This is why teams should run trial periods with locking disabled before committing to a retention policy.
What is the biggest mistake organizations make with immutable backups?
Treating it as a checkbox. Common failures include choosing governance mode by default, setting retention shorter than detection time, leaving the backup catalog editable, and never testing a restore. Immutability only works as part of a designed chain that includes credential separation and regular verification.
