Backup security

Can immutable backups be deleted?

The honest answer is: not through the front door, and that is exactly the door attackers stopped using. Immutability, enforced through object lock or WORM retention, genuinely prevents stored objects from being altered or removed through the storage interface for the retention period. If ransomware reaches your backup repository with ordinary file access, immutable copies survive. That is real protection and this page is not an argument against it.

The doors that remain

The repository enforcing immutability is itself a system, and systems have surfaces. Four matter in practice. The management plane: consoles and APIs can, depending on product and configuration, shorten retention, detach storage, or decommission the repository entirely, and an intruder holding administrative credentials inherits those abilities. The retention clock: immutability expires by design, and intruders who dwell in networks for weeks can simply wait, encrypting production only after the clean copies age out. The firmware and platform layer: the promise is only as strong as the software stack enforcing it, and that stack takes updates. And configuration: compliance-mode settings that nobody can override are frequently softened in deployment because operations teams want an escape hatch, and the escape hatch works for attackers too.

None of this is theoretical. The public CVE record for storage appliances that implement software-defined WORM includes authenticated command injection, path traversal, SQL injection and hard-coded credentials, all found in the management layer that operates the immutability rather than in the locked data itself. The vendors involved disclosed and patched responsibly, which is to their credit, but the pattern is the point: wherever immutability is enforced by software, the software enforcing it is an attack surface.

What the incident data keeps showing

Post-incident reports repeat one finding: ransomware crews go after recovery infrastructure first, because destroying it is what forces payment. When immutable storage fails in the field it is rarely because the lock was broken. It is because the intrusion operated above the lock, with credentials, consoles and patience. The question to ask is not whether your storage is immutable but what an intruder holding domain admin can still reach.

The layer behind immutability

A physically disconnected vault answers the surfaces immutability leaves open, by not having them. The disk is unreachable by any protocol at all times, data enters through a one-way optical transfer, and restoring requires standing in front of the device. There is no console to capture, no retention clock to outwait and no firmware to subvert from the network, because there is no software attack surface at all. It is not a replacement for immutable storage, which handles routine restores and bulk coverage. It is the copy of last resort behind it, scoped to the critical core your organisation needs to restart. The two layers fail differently, which is the point. See the three layers of recovery assurance for the full taxonomy.

Can ransomware delete immutable backups?

Not through the storage interface during the retention period. But intrusions that capture administrative credentials can, depending on product and configuration, shorten retention, detach or decommission the repository, or simply wait until retention expires before encrypting production. Immutable copies are usually lost from above, through the management plane, not through the lock itself.

What should sit behind immutable storage?

A recovery copy with no management plane at all. A physically disconnected vault is unreachable by any protocol, receives data only through a one-way optical transfer, and is restored from in person, so the credential-based attacks that defeat repositories cannot address it. It holds the critical core needed to restart, while immutable storage handles day-to-day coverage.