We've configured Azure immutable backups across multi-region environments to defend against ransomware that targets backup data first. Here's how they work, when to lock them, and where Eon's CBPM automates immutability across every cloud.
What is an Azure immutable backup?
An Azure immutable backup is a recovery point stored in write-once, read-many (WORM) storage that prevents deletion or modification during its retention period.
The protection lives at the storage layer, below Azure's permissions model, so even users with administrator-level access cannot remove the backup before retention expires.
How Azure immutable backups work: Vaults vs Blob Storage
Azure immutable backups operate across two distinct architectures, each enforcing immutability at a different layer.
Recovery Services vaults and Backup vaults apply immutability at the vault level. Every recovery point inside inherits the vault's lock state, and Azure Backup manages the recovery points directly.
These vaults cover Azure VMs, SQL Server on Azure VMs, SAP HANA on Azure VMs, Azure Files, Azure Database for PostgreSQL, and Azure Kubernetes Service workloads.
Immutable Blob Storage applies immutability at the container level, governing data that application code writes directly to blob containers. Two policy types control how long objects stay protected:
- Time-based retention blocks deletion and modification for a fixed duration. Once locked, the period can only be extended (up to five times), never shortened.
- Legal hold has no fixed duration. Objects stay immutable until the hold is explicitly removed, which suits audit and litigation workflows where the timeline is open-ended.
The two architectures can run together: vault immutability for managed backups, blob immutability for direct application writes.
The three immutability states
Azure immutable vaults move through three states. Each state has a distinct operational profile and a distinct level of attacker resistance.
Disabled
Immutability is off. Every operation that could reduce retention or delete recovery points is allowed. This is the default state for new vaults and provides no protection against deletion attacks.
Enabled (reversible)
Immutability is on. An administrator can still turn the setting off, which makes this state reversible. The vault blocks operations that would reduce retention or delete recovery points.
The protection ends if a compromised admin disables the setting and then proceeds with deletion. Use this state to test workflows.
Enabled and Locked (irreversible)
Immutability is on, and the setting cannot be turned off. WORM storage is in effect for supported workloads in supported regions. No user, regardless of privilege, can delete recovery points before retention expires, and no one can disable immutability to work around the lock.
The transition from Enabled to Locked is one-way. Once locked, the vault is committed to its current retention rules for the lifetime of every recovery point inside it.
Pair the right state with layered defenses. The strongest configuration combines an irreversible setting (Enabled and Locked immutability, or always-on soft delete) with multi-user authorization (MUA). Microsoft classifies this as the "Excellent (Maximum)" security tier.
Each layer protects against a different attack vector: soft delete catches accidental deletions, immutability blocks intentional deletes during retention, and MUA blocks the change request that would weaken either of the other two.
The lock decision: What locking commits you to
A common misconfiguration is locking a vault with the default 99-year yearly retention still in place. Once locked, there is no path to reduce it. The vault runs at full storage cost for the duration, and Microsoft Support has no override.
Once applied, the following operations block for the lifetime of every recovery point in the vault:
- Disabling soft delete on the vault
- Disabling immutability on the vault
- Reducing the retention period for any backup item
- Removing protection while deleting backup data
- Modifying policies that would shorten retention
The lock state is universally available across Azure regions, but the underlying WORM storage enforcement is not. In regions or workloads without WORM support, the lock applies at the policy level only; the storage layer does not yet enforce it.
Vaults in unsupported regions will transition to WORM-enabled storage automatically once the feature reaches general availability locally, with no user action and no data movement required.
For compliance-critical workloads, confirm both region and workload support before relying on the locked state for audit attestation.
Best practices for Azure immutable backups
These patterns separate teams operating immutability cleanly from teams stuck with retention configurations they cannot undo:
- Test in the reversible state for at least 2 to 4 weeks before locking: run real backup, restore, and policy-modification workflows. Confirm that the retention values match your compliance framework's exact retention requirements before you commit them.
- Change yearly retention before locking: Azure defaults to long yearly retention values. Set yearly retention to what compliance requires (typically 7-10 years) before locking, or you commit to a multi-decade obligation.
- Pair immutability with multi-user authorization: MUA requires approval from a separate security administrator before any disable-immutability or soft-delete operation. This protects against the scenario where a single privileged account is compromised.
- Leave soft delete enabled: Soft delete protects against accidental deletion within the immutability window. Locked immutability (or always-on soft delete) paired with MUA is what Microsoft classifies as the "Excellent (Maximum)" security tier. Keeping soft delete on adds accidental-deletion coverage on top.
- Verify region and workload support before relying on WORM for compliance: The locked state applies universally. Storage-layer WORM is only generally available in specific regions and workloads, so audit attestation should align with GA coverage.
How Eon makes immutability automatic across every cloud
Azure handles immutability one vault at a time, configured manually per workload. At enterprise scale across 50 subscriptions and three regions, that's 150 places where immutability must be enabled, tested, and correctly locked, each carrying an irreversible retention commitment.
Eon's approach is different. Logically air-gapped, immutable backups are the default protection model. Every resource is immutable from the moment it's onboarded, with no per-vault enablement step and no lock decision to manage.
Cloud Backup Posture Management (CBPM) classifies every cloud resource by data type and applies the appropriate immutability policy across AWS, Azure, and Google Cloud from a single console.
The recovery model changes the operational story most. When a ransomware incident occurs, granular recovery lets us restore a specific file, database row, or table directly from the immutable backup, without rehydrating the entire environment. SoFi cut recovery time from a full day to minutes, reporting over 100% ROI in the first year.
Incremental-forever backups with global deduplication reduce cloud backup spend by 30–50% compared to native tools. NETGEAR cut backup costs by 35% and recovered a 10TB SQL Server database 88% faster after switching to Eon.
Native Azure immutability remains the right fit for Azure-only environments small enough to manage per vault, or for compliance frameworks that require Azure-native WORM attestation specifically. Eon fits when scale, multi-cloud spread, or recovery granularity push past what native can sustain.
See how Eon handles immutability across every cloud
Managing immutability across 50 subscriptions and three clouds, without a single irreversible misconfiguration, is harder than it looks. Book a demo and see how Eon applies logically air-gapped, immutable backups by default across AWS, Azure, and Google Cloud, with no per-vault lock decisions and granular recovery when it counts.
Frequently asked questions
What's the difference between an enabled and locked immutable vault in Azure?
The difference between an enabled and locked immutable vault is reversibility. An enabled vault blocks deletion operations while remaining reversible by administrators. A locked vault uses WORM storage in supported regions and cannot be reverted once applied.
Can I delete an Azure immutable backup before retention expires?
No, you cannot delete an Azure immutable backup before retention expires when the vault is in the Enabled and Locked state. WORM storage prevents the deletion at the storage layer, and Microsoft Support has no override path for compliance reasons.
What's the difference between Azure soft delete and immutability?
Azure soft delete and immutability cover different threats. Soft delete retains deleted items for 14 to 180 days to catch accidental deletions. Immutability prevents deletion during the retention period, including by compromised credentials with administrator-level access.
What happens to immutable Azure backups when retention expires?
Immutable Azure backups are automatically deleted when their retention period expires, unless a legal hold is applied. The deletion is determined by the policy under which the backup was created and occurs automatically without administrative action.
Does Eon support immutability across AWS, Azure, and Google Cloud?
Yes, Eon applies the same logically air-gapped, immutable backups across AWS, Azure, and Google Cloud through Cloud Backup Posture Management. Granular recovery, cross-cloud restore, and drift detection work uniformly.
.png)