1.8K Almost every storage and backup product sold today claims immutability. Very few of them mean the same thing by it, and the differences are close to invisible until the day they matter — at which point they are the only thing that matters. Immutability is not a feature you can verify by reading a datasheet, because the word describes an outcome rather than a mechanism. Two products can both be immutable and differ completely in who can turn it off, what happens beneath the API, and whether the protection survives a compromised administrator. Those differences are the entire subject. This guide covers the definition, then spends most of its length on the part that is actually hard: telling enforced immutability apart from the marketing version. What is immutable storage? Immutable storage is storage where data, once written, cannot be modified or deleted for a defined retention period — including by an administrator. The retention period is the operative part. Immutable does not mean permanent; it means unchangeable for a stated duration, after which normal lifecycle rules resume. The implementation pattern is write once, read many — WORM: Write once — data is stored as a new object or version rather than edited in place Read many — the data stays readable for the whole retention period Retention enforcement — the system refuses deletes and overwrites until retention expires The third point is where products diverge. Every vendor implements the first two. What separates them is what enforces retention, and who can override it. The immutability spectrum: five implementations, five different guarantees “Immutable” is applied to all five of the approaches below. They are not equivalent, and the gap between the top and bottom rows is the difference between a recoverable incident and an unrecoverable one. ImplementationEnforced byBackup admin can bypassStorage root can bypassSurvives credential compromiseBackup software immutability flagThe backup applicationYesYesNoFilesystem permissions + snapshotsOS access controlSometimesYesNoWORM appliancePurpose-built hardwareNoNoYes, within its ecosystemS3 Object Lock — governance modeStorage layerOnly with a specific privilegeDepends on implementationPartiallyS3 Object Lock — compliance modeStorage layerNoNoYesThe question that separates the rows is not “is it immutable” but “who retains the authority to make it mutable again.” A useful reframing: immutability is not a property of the data. It is a statement about who holds delete authority. When a vendor says immutable, the follow-up question is always the same — immutable against whom? The four bypass paths Immutability fails in a small number of well-understood ways. Each of these has been enabled, configured and reported as working right up until it was tested. 1. Enforcement lives in the application, not the storage The backup software has an immutability setting. It is enabled. But the underlying repository is an ordinary bucket or filesystem with no retention configured, and the only thing preventing deletion is the backup application declining to issue the delete. An attacker with backup admin credentials does not need to defeat immutability — they turn the setting off. The test: disable the backup software entirely and try to delete an object directly against the storage API. If it deletes, the immutability was a UI checkbox. 2. Governance mode when compliance mode was assumed S3 Object Lock has two retention modes and they offer materially different guarantees. Governance mode blocks deletion by ordinary identities but allows override by an identity holding a specific bypass permission. Compliance mode allows no override by anyone, including the account root, for the duration of retention. Governance mode is the sensible default for operational flexibility and the wrong choice for a copy whose entire purpose is to survive a compromised administrator. A great many deployments run governance mode believing they have compliance-mode protection. 3. Below the API This is the one most evaluations miss. Object Lock is enforced at the S3 API. If the platform underneath is a general-purpose filesystem on general-purpose servers, then a storage administrator with root on those nodes is not bound by the S3 API at all. They can operate on the files directly, or on the metadata that records the retention state. API-level immutability is necessary and it is not sufficient. What sits beneath it determines whether the lock is a wall or a sign. 4. The replica that isn’t locked Retention has to travel with the data. If the primary is locked and the replication target is an ordinary bucket, the architecture’s weakest copy sets its real protection level — and an attacker who has done any reconnaissance will find it. The same applies to tiering: an object that ages out to a cheaper tier without carrying its retention has quietly become mutable. Defense in depth: why one layer is never the answer Bypass paths two through four all describe the same structural problem: a single enforcement point, positioned at one layer, with everything below it unprotected. The response is to protect at more than one layer, so that defeating any single one is not sufficient. Scality’s CORE5 framework is one way of formalising that, and it is a useful evaluation lens whichever vendor you are assessing. It protects at five levels: API level — S3 Object Lock immutability applied the moment a backup is written Data level — identity and access management plus cryptographic controls, aimed at exfiltration rather than deletion Storage level — advanced erasure coding that leaves data indecipherable to anyone reading the underlying media directly, which is the answer to bypass path three Geographic level — multi-site copies, so a single data center cannot be the whole blast radius Architecture level — hardening the system’s own attack surface The point is not the branding. It is that a credible immutability story has an answer at every layer, not just the API. If a vendor’s answer to “what stops a storage admin with root” is a restatement of their Object Lock support, they have answered a different question. We have written up the reasoning in more depth in the five levels of an unbreakable cyber-resilient framework. Immutable storage vs immutable backup The terms get used interchangeably and they describe different things. Immutable storage is a platform capability: the system can enforce WORM retention. Immutable backup is an operational outcome: your backup copies are actually tamper-resistant. The mechanism does not produce the outcome by itself. You can run immutable storage and still not hold a single immutable backup — if retention was never applied to the bucket the backup jobs write to, if it was applied in governance mode, or if the copy that matters is the unlocked replica. The capability is a precondition. The outcome requires configuration you have verified. Immutable storage vs snapshots Snapshots are frequently assumed to be immutable. They are useful and they are a different control. Snapshots are good at short-term rollback, operational recovery from mistakes, and fast restores of recent state. Against a deliberate attacker they have three structural weaknesses: the interval between snapshots is an exposure window; snapshots are usually deletable by the same privileged identity that administers production; and snapshot management typically shares a control plane with the systems being protected. An attacker who owns that control plane owns the snapshots. Keep snapshots. They earn their place. Do not let them stand in for policy-enforced retention on an independent control plane. What actually goes wrong without immutable backups The risk is usually described as “an attacker deletes your backups.” That is one failure mode and not the most common. The realistic ones: Retention gets shortened, not deleted. Quieter than deletion and it does not trigger the alerts deletion does. By the time anyone notices, the restore points have aged out on their own. Backups are encrypted in place. Jobs keep completing. Dashboards stay green. The repository contains the right number of files and none of them restore. The catalogue is targeted instead of the data. The backups survive and the index that makes them usable does not. Every surviving copy predates the compromise by less than the dwell time. Nothing was deleted. Everything is intact. All of it is poisoned. Immutability addresses the first two directly and the fourth only if retention is set correctly — which is the next section. Retention has to outlast your detection gap Retention duration is normally inherited from a compliance requirement. For ransomware the governing number is different: it is dwell time, the interval between initial compromise and detection, which routinely runs to weeks. If retention is 14 days and the intruder was present for 30, every immutable copy you hold may already contain the compromise. Immutability worked exactly as specified. It preserved the wrong state, perfectly, and refused to let you delete it. A workable retention ladder, set against risk rather than storage cost: 7 days — operational rollback, everyday mistakes 30 days — incident recovery window 90+ days — coverage for realistic ransomware dwell time 1 year+ — compliance and archive The same reasoning applies to slow-burn compromise generally — see zero-day attack recovery. How to evaluate immutable storage: seven questions Ask these of any vendor, including us. What matters is not whether they say yes but whether the answer is specific. Can any administrator delete protected data during retention? A good answer names the mode and the identity. A vague yes-we-support-immutability is a no. Is enforcement in the storage layer or the application? Ask them to describe what happens when the backup software is bypassed entirely. What stops someone with root on the storage nodes? This is the question that separates real architectures from configured ones. Encoding and encryption below the API are legitimate answers. “Object Lock” is not. Does retention survive replication and tiering? Get it confirmed for every copy and every tier, not just the primary. Is retention configuration visible, audited and alerted on? Policy drift is silent otherwise, and shortened retention is the most common real-world failure. How is integrity proven? Checksums, end-to-end verification, periodic validation. Immutable and intact are separate claims. How fast does it restore at your scale? A vault you cannot empty inside your RTO has protected the data and not the business. See ransomware recovery speed for how to put a number on that. Where immutable storage fits The common deployments, roughly in order of how often they justify the effort: Backup repositories — VM, NAS and database backups. The highest-value target in most environments and the usual starting point. Cyber recovery vault — a logically isolated repository with long retention, strict policy and separate access, sitting behind a logical air gap. Compliance archive — regulated retention, legal records, medical imaging. Where WORM originated and still the cleanest fit. Logs and audit trails — security events and audit evidence, where the value of the record depends on nobody having been able to edit it. Operating it well Three practices separate deployments that hold up from deployments that look the same on paper. Keep retention classes few. Four is plenty. Complexity in retention policy produces gaps nobody can see, and the gaps are always discovered in the wrong circumstances. Split the credentials. No single identity should control backup configuration, storage configuration and retention override. If one account can do all three, immutability is decorative — the attacker only has to compromise that account. Consider customer-managed keys held in a hardware security module where the separation needs to be enforceable rather than procedural. Test restores, not backups. Job success is a write-path signal. It says nothing about whether the data restores. Test full restores, partial restores and timed restores at scale, on a schedule, and treat the resulting numbers as the real status of the system. Frequently asked questions Is immutable storage the same as WORM storage? WORM is the implementation pattern; immutable storage is the category. Nearly all immutable storage relies on WORM-style retention enforcement, but “WORM appliance” usually refers to a specific class of purpose-built hardware, whereas immutable storage today more often means S3 Object Lock on object storage. Can ransomware encrypt immutable storage? Not the protected objects, during retention. Ransomware can only encrypt what it can write to, and an object under active retention rejects both modification and deletion. The caveats are the bypass paths: if enforcement is application-level, or governance mode is in use, or the attacker has root beneath the API, the protection may not hold. What is the difference between governance mode and compliance mode? Governance mode blocks deletion but permits override by an identity holding a specific bypass permission. Compliance mode permits no override by anyone, including account root, until retention expires. Governance mode suits operational flexibility; compliance mode is what you want for a copy that must survive a compromised administrator. Do I need object storage for immutability? No — WORM appliances and some filesystem-based approaches provide it. S3-compatible object storage with Object Lock has become the common choice because it integrates with essentially every modern backup platform, scales without a forklift, and enforces retention through a policy layer rather than through file permissions. Is immutable storage enough on its own? No. It protects a copy from being changed. It does not isolate the path you use to reach that copy, tell you which restore point is clean, or make the restore fast enough to matter. Immutability is one of four properties a recovery architecture needs, alongside isolation, restore parallelism and validation. The short version Immutable storage is the most effective single control available for protecting recovery data. It is also the control most often claimed and least often verified, because the claim is easy and the verification requires asking who holds delete authority at every layer of the stack. The organizations that get this right treat immutability as a system rather than a setting: enforced at the storage layer, unbypassable below the API, carried across every replica, retained longer than the attacker is likely to sit undetected, and proven by restores that someone actually ran. Everything else is a checkbox that has never been tested. Scality builds S3 object storage with immutability enforced from the API down through the architecture. See how CORE5 works, or browse the glossary for the terms used in this guide.
