Azure Backup immutable vault protects backups from ransomware and admins

In 2024 I'd call Azure Backup immutable vault essential for any serious Azure backup strategy. In most tenants I look at, protecting backups from targeted ransomware, and from accidental or malicious admin actions, is now high on the list. Classic soft delete doesn't cut it anymore if you need certainty that a compromised account or a careless operator can't wipe your backups. The controls are now widely available in Recovery Services vaults, so it's time to actually use them. As always, though, you should understand what you're switching on.

An immutable vault protects for good and can trap you in costs

The main feature here is the Azure Backup immutable vault setting. In the Recovery Services vault (Properties → Immutability) you can enable a mode that makes backups truly undeletable and unmodifiable, even for someone with Owner rights. Enabling Immutability is only the first step, though. Once you "lock" the vault, you can't go back. Against ransomware or compromised admin accounts, that's a very strong defense. The catch is that retention periods become permanent, and so do the storage costs. Lock immutability before you've carefully reviewed and stress-tested your retention configuration, and your Azure bill can get out of hand fast.

The simplified flowchart below shows how the different protection mechanisms fit together:

flowchart TD
    Admin["Admin"] -->|"Delete backup"| Vault["Recovery Services vault"]
    Vault -->|"Soft delete on"| SoftDelete["Soft Delete"]
    Vault -->|"Immutable vault on"| Immutable["Immutability"]
    Admin -->|"MUA required"| ResourceGuard["Resource Guard"]
    ResourceGuard -->|"Approval"| Vault
    Vault -->|"Monitor alert"| Alert["Azure Monitor"]

Figure: Layers that protect Azure backups from deletion, from soft delete and immutable vault to MUA and alerts

Enhanced soft delete with always-on closes the soft delete gap

Soft delete has been the baseline for a long time. A deleted backup stays recoverable in the vault for 14 or 30 days, depending on the workload. The weakness is obvious once you think about it: a compromised admin can just disable soft delete and then purge everything. Enhanced soft delete with always-on mode addresses exactly that. With always-on enabled, soft delete can't be turned off, and retention can't be reduced below a mandatory minimum. Microsoft's documentation on enhanced soft delete has the details.

I still come across plenty of Recovery Services vaults, older ones in particular, where enhanced soft delete was never switched on. An audit is worth the few minutes it takes: Portal → Vault → Properties → Soft Delete. If you want the safest setup, turn on always-on and document that you did. Keep in mind that after you've locked immutable vault, you can't lower retention (and with it the cost) without Microsoft support.

Multi-user authorization requires a second approver through Resource Guard

Multi-user authorization (MUA) is one of the best protections against rogue or compromised admins. With MUA in place, sensitive actions such as deleting backups, changing the vault or enabling immutability need approval from a second user. This works through a Resource Guard, which ideally lives in a separate subscription or even a different Azure AD tenant. In my projects I usually set up Resource Guard accounts with their own approval workflows, so no single admin can bring down the whole backup strategy.

Clean RBAC separation and alerts keep operators in check

Role separation in RBAC gets overlooked a lot. On a Recovery Services vault, the default Contributor role has too many rights, including deleting backups and changing settings. Backup Operator can manage and restore backups but can't delete them or change vault settings. For day-to-day operations that split is usually enough. On top of that I set up Azure Monitor alerts for every backup deletion and every change to the soft delete settings. You'll find these in the vault's "Alerts" section. If you want them in your SIEM, route the alerts to your central monitoring or an Azure Monitor Action Group.

Practical tip: Before you lock immutable vault, model a full year of backup growth and retention in detail. You don't want to be stuck with costs and retention you can't live with.

Cross region restore needs more than a ticked box

Preventing deletion covers only half of the problem. Cross region restore lets you recover backups to another Azure region after a disaster, but only if you chose geo-redundant storage when you created the vault. I've seen vaults where the option was checked by default and nobody actually knew how a restore would play out. Proper documentation and a restore test at least once a year are essential.

More security brings more responsibility

I think Azure Backup immutable vault and the features around it should be standard for every backup admin who takes resilience seriously, whether the threat is an attacker or plain human error. The stronger the protection, though, the more carefully you have to plan retention and cost. Put soft delete, enhanced soft delete always-on, MUA and immutable vault together with a clear retention policy and you can sleep well. Switch everything on and lock it without thinking it through, and you'll have your backups but maybe not your budget. I cover how to keep Azure spending predictable in Azure cost control: Budgets, tags, advisor.