What Immutable Backup Protects and What It Does Not

An immutable backup protects recovery data from being changed or deleted for a defined period, even after an attacker or careless administrator reaches the backup environment. That can preserve a route to recovery after ransomware, but it does not ensure the backup is clean, available or restorable. The crucial question is who can still bypass or remove the protection, and by what route.

That is the problem an immutable backup is designed to address. Once a backup enters its protected period, its recovery data should not be alterable or deletable until that protection expires. Not from the ordinary backup console. Not through a storage administrator’s routine permissions. In stronger implementations, not even by the cloud account’s most powerful user.

It is useful protection, but suppliers stretch the term freely. A backup is not meaningfully immutable because a product has a retention setting, sits in a different folder, or is protected by company policy. The question is less glamorous: which identities can still destroy this recovery point, by what route, and for how long?

The incident scenario that matters

Imagine a mid-sized organisation where a phishing compromise has become domain-wide administrative access. The attacker encrypts virtual machines, steals data, then turns to the backup platform. Restoring is the victim’s quickest path back to normal, so the attacker tries to delete restore points, remove repositories and reduce retention before the security team notices.

With ordinary backups, the outcome may depend largely on whether the attacker has found credentials that administer both the backup software and the place where the backup files live. That is not exotic. Backup systems are valuable targets precisely because they hold broad access to the estate.

With immutability correctly configured, a valid restore point already inside its immutable window remains readable but cannot be altered or removed. The attacker can still cause plenty of trouble: stop future jobs, remove the backup server, damage the catalogue, lock accounts or consume capacity. But they should not be able to erase the protected data retrospectively.

That is the point. Immutability is a destructive-action control, not a synonym for resilient backup.

What “immutable” actually prevents

At its strongest, immutability applies a write-once, read-many (WORM) rule to a backup object or file. During the specified period it can be read for a restore, but not overwritten or deleted. A later backup normally creates a new object or version rather than rewriting the older protected one.

Amazon S3 Object Lock is a familiar example. It applies retention to individual object versions and supports a stricter compliance mode and a more flexible governance mode. In compliance mode, AWS says a protected object version cannot be overwritten or deleted by any user, including the account root user, before the retention date. Governance mode is deliberately different: an identity with the relevant bypass permission can override protection. That may suit operational needs, but it is not the same security boundary. AWS’s Object Lock documentation is commendably clear about the difference.

Azure Blob Storage offers time-based retention and legal holds under its immutable storage capability. A time-based policy prevents modification and deletion for the selected interval; a legal hold remains until an authorised person removes it. Microsoft also distinguishes between a policy that is configured and one that is locked. An unlocked policy may be altered or removed, while a locked time-based policy cannot be deleted and its period cannot be shortened. That is not a paperwork detail. Microsoft’s immutable Blob Storage guidance is worth reading before treating an Azure setting as a ransomware control.

There are appliance and repository approaches too. Veeam’s hardened Linux repository model, for example, aims to prevent protected backup files being moved, modified or deleted during the configured period, while keeping routine storage credentials away from the backup server. That is useful where a compromised backup server is part of the threat model, but it remains a product-specific implementation, not a universal definition of immutability. Veeam’s current hardened repository documentation sets out its model and limits.

Don’t buy the word. Establish the enforcement mechanism.

Retention, WORM, immutability and air gaps are related, but not interchangeable

Air-gapping and immutability solve different problems. An air-gapped copy is difficult to reach in the first place. Immutability assumes somebody may reach it, but denies destructive actions for a period. The stronger designs often use both: an immutable copy in a separately controlled environment.

Nor does a snapshot automatically count. Storage snapshots can be excellent for fast operational rollback, but their safety depends on who controls the storage system and whether snapshot retention can be changed or the whole system destroyed. Calling every snapshot “immutable” is the sort of shortcut that produces unpleasant surprises later.

Where ransomware protection stops

Immutability narrows a common ransomware route: deleting the evidence of recoverability before demanding payment. It also helps with accidental deletion and malicious insider action, especially when the person making the mistake has broad backup-platform privileges but cannot break the storage lock.

It does not guarantee a clean recovery. An attacker may have been present long enough for encrypted or tampered data to enter the backups. They may have stolen encryption keys, deleted the backup configuration database, disabled jobs, damaged network connectivity, changed identity infrastructure or exhausted the immutable repository’s capacity. A locked object offers limited comfort if the only clean restore point is too old to meet the organisation’s recovery needs.

Immutability also has a clock. Once the retention period expires, deletion is possible again unless another policy, hold or backup copy continues protecting the data. A seven-day immutable window is not a 30-day ransomware detection window just because both numbers look reassuring in a slide deck.

Backup products add their own wrinkles. A protection period may apply to a chain of data blocks rather than neatly to the restore-point dates shown in a console. Some implementations extend effective retention to accommodate their internal block-management model. That may be safer than expected, but it can increase storage consumption. Read the product’s retention calculations, not just the label beside the tick box.

UK guidance is refreshingly grounded here. The National Cyber Security Centre advises organisations to maintain up-to-date backups, know how to restore them and test that restoration works as expected. Its ransomware mitigation guidance does not suggest that a protected copy removes the need for those disciplines.

The controls that make an immutable copy worth having

A credible implementation is less about a feature switch than making it hard for a single compromise to undo the arrangement. These checks expose most weak claims.

For cloud object storage, permissions deserve particular attention. AWS governance mode can be bypassed by identities granted s3:BypassGovernanceRetention; AWS documents that plainly. If a ransomware operator can obtain that permission through an over-privileged role or compromised administrator, the protection is weaker than the word “immutable” implies. Compliance mode brings a stronger restriction but needs careful testing, because its operational consequences are deliberately hard to reverse. AWS’s Object Lock considerations explain the bypass behaviour and the fact that Object Lock itself cannot simply be disabled once enabled on a bucket.

Microsoft makes the same practical point in its own way: test before locking a time-based Azure policy. A locked retention policy is intended to stop you shortening it later. Excellent when resisting an attacker; inconvenient when someone configured the wrong scope or duration. The technology is doing its job in both cases.

Do not confuse protected data with a recovery strategy

Immutable backup should have an important but bounded role in resilience planning. It protects recovery data against alteration and deletion. It does not decide which services return first, provide a clean identity environment, define acceptable downtime, arrange replacement hardware or tell staff how to operate during a prolonged outage.

This matters particularly for organisations running a mix of on-premises systems, Microsoft 365, cloud workloads and line-of-business applications. A recoverable database is not automatically a recoverable service if its application tier, DNS, credentials and upstream integrations remain unavailable. For the wider planning question, read Why Your Backup Is Not Yet a Disaster-Recovery Strategy.

Immutable storage features are not identical across every managed service. Azure SQL long-term retention is a useful example of why wording and scope need scrutiny: the available immutability options differ between Azure SQL Database and Azure SQL Managed Instance. Our separate look at immutable long-term retention for Azure SQL Database and Managed Instance covers that specific distinction.

A sensible buying and design decision

If your organisation can lose every backup because one domain administrator, cloud administrator or backup administrator is compromised, immutable backup is a high-value improvement. Prioritise a design in which protected recovery data has a separate administrative boundary and the lock is enforced below the backup application.

If a supplier’s “immutable” option can be disabled by the same account that runs day-to-day backups, it may still reduce accidental deletion. It is governance protection, not the strongest answer to a full administrative compromise. That is not necessarily a reason to reject it. It is a reason to describe it accurately and add a separately protected copy where the risk warrants it.

The honest conclusion is pleasingly unmarketable: immutable backups are not unchangeable in every imaginable sense, forever. They are recovery data protected from particular destructive actions, through particular controls, for a defined time. When those controls are independently administered, monitored and regularly tested through real restores, that is extremely useful protection when somebody tries to take your backups away.