Immutable Backups: What They Protect—and What They Do Not

An immutable backup prevents ordinary alteration or deletion during a defined retention period. It is a valuable ransomware control, but it does not prove that the backed-up data is clean, that the backup identity is secure, or that the organization can restore within its required timeframe.

What immutability actually protects

Immutability protects a recovery point against modification after it has been written. The control is most useful when the retention policy cannot be shortened by a compromised production administrator and when the storage account, encryption keys, and management plane have separate protections.

Microsoft's ransomware guidance combines immutability with soft delete, multifactor authentication, separate authorization, and monitored backup operations. CISA likewise recommends offline or cloud-to-cloud backups and regular testing rather than relying on one online copy.

The four controls that complete the design

Separate identities and MFA

Backup administrators should not reuse privileged production accounts. Use least privilege, multifactor authentication, and additional approval for destructive operations. A backup stored in a strong vault can still be exposed if an attacker controls the vault's management identity.

Soft delete and retention locks

Soft delete provides a recovery window after accidental or malicious deletion. A retention lock restricts policy changes. These controls overlap, but they are not identical: one preserves recently deleted objects, while the other limits changes during the retention period.

An offline or isolated copy

Maintain a copy outside the production failure domain. Isolation must include credentials and management paths, not merely a different folder on the same cluster. The familiar 3-2-1 approach remains useful: three copies, two media types, and one copy offsite or offline.

Routine restore validation

A successful backup job only confirms that data was written. It does not confirm application consistency, usable encryption keys, clean operating-system images, or an achievable recovery time. Test representative restores in an isolated network and record the observed RPO and RTO.

What immutable backups do not prevent

They do not stop ransomware from encrypting production data before the next backup. They may preserve an already compromised image if the attacker was present before encryption became visible. They also do not replace endpoint protection, identity security, segmentation, monitoring, or an incident-response plan.

During an incident, isolate affected systems, preserve logs, protect the backup management plane, and identify a recovery point that predates initial compromise—not merely the visible encryption event. Restore into a clean environment, rotate exposed credentials, validate dependencies, and reconnect services in stages.

Sources

• Microsoft Azure: Ransomware protection
• Microsoft Azure: Backup plan to protect against ransomware
• CISA: StopRansomware Guide

Sources verified on September 4, 2026.

Frequently Asked Questions

Can an immutable backup contain encrypted files?

Yes. Immutability prevents changes to the recovery point; it does not classify its contents. Retain enough history to recover from a point before compromise.

Is cloud backup immutable by default?

No. Cloud services provide relevant controls, but administrators must configure retention, permissions, MFA, soft delete, and policy locks correctly.

Does a snapshot count as an independent backup?

Usually not by itself. A snapshot commonly shares storage, credentials, or management infrastructure with production and may remain inside the same failure domain.

How often should restores be tested?

Set a schedule based on business criticality and system change rate. Test again after major application, infrastructure, identity, or backup-policy changes.