Azure Backup Hardening: Immutability and Resource Guard

If one over-permissioned admin can change your backup vault in the middle of the night, it isn’t a recovery strategy. This runbook gives you a practical sequence for Azure Backup immutability and Resource Guard, so you can harden a vault with minimal disruption and a clear rollback path.

Why Azure Backup immutability matters now

Microsoft’s Azure Backup guidance stresses three layers that work best together: soft delete, immutability and multi-user authorization (MUA) with Resource Guard. Together they limit the damage from accidental deletion, rushed changes and malicious actions against recovery points.

One caveat up front: immutability and MUA protect against destructive control-plane actions. They don’t replace restore testing, runbooks or identity hygiene.

Layered vault protection

Protected workloads
VMs, databases and files back up to the vault.
Soft delete
Recovers from accidental deletion.
Immutability
Blocks destructive changes to retained recovery points.
Resource Guard
Adds a second approval boundary for critical operations.

What this runbook configures

  • Provider registration and vault prerequisites.
  • Vault immutability, with a plan for when to lock it.
  • Resource Guard MUA for critical operations.
  • A controlled test to prove the guardrails work.

Preflight checklist

CheckTarget stateWhy it matters
Resource providersMicrosoft.RecoveryServices and Microsoft.DataProtection registeredMUA and vault operations can fail when providers are missing.
Role separationThe backup admin doesn’t hold Resource Guard permissionsMUA is meaningless if one identity can approve itself.
Region alignmentResource Guard and vault in the same regionRequired for the supported MUA configuration.
Change windowApproved test and rollback window documentedPrevents half-configured controls nobody can support.

Step-by-step hardening

Diagram: three layers of Azure Backup protection: soft delete, vault immutability and Resource Guard multi-user authorization, plus the verification test flow
The three protection layers this runbook configures, and the test that proves they work.

1. Confirm soft delete

Microsoft enforces soft delete by default on Recovery Services vaults as part of its secure-by-default approach, with configurable retention. Confirm the vault setting and document the retention period for audit and operations.

2. Enable immutability on the vault

Enable immutability and confirm workload support in your region. Locking immutability is irreversible, so plan when to do it, for example after two successful restore drills. Immutability blocks operations that would delete recovery points early.

3. Deploy Resource Guard

Create Resource Guard under a security-admin identity, separate from the backup admin. Microsoft recommends separation of duties and allows stronger isolation by placing Resource Guard in a separate subscription or tenant; the same-region requirement still applies.

4. Associate the vault and protect critical operations

Associate the vault with Resource Guard and review the protected operations. Keep mandatory operations protected and avoid exclusions unless there’s a documented, approved business reason.

5. Run a controlled verification test

  • Attempt a protected operation from a backup-admin account without Resource Guard access.
  • Confirm the operation is blocked.
  • Grant just-in-time approval through your process, for example Entra PIM.
  • Re-run it and confirm it succeeds only after approved elevation.

Common pitfalls

  • The same team is Contributor on both the vault and Resource Guard. That isn’t MUA; it’s paperwork.
  • Immutability is on, but no restore drill has run. You’ve protected retention without proving recovery.
  • Provider registration was skipped, burning change-window time on avoidable failures.

Operations handoff

Record these in your runbook before calling it done:

  • Vault name, subscription, region and workload scope.
  • Immutability status and the date of the lock decision.
  • Resource Guard owner group, approval workflow and emergency path.
  • Protected operations, with any approved exceptions.
  • Last successful restore drill: date, scenario, RTO and RPO.

Azure Backup immutability and Resource Guard pair well with Azure Resource Locks for the vault resource itself, and with Azure Chaos Studio drills to prove recovery.

Check the vault settings from the command line

After each step, confirm the vault’s security settings instead of trusting the portal blade you just closed. This Azure CLI query shows the immutability and soft delete state for a Recovery Services vault:

az backup vault show --name rsv-prod --resource-group rg-backup \
  --query "properties.securitySettings" -o json

Look for an immutability state of Unlocked while you test and Locked once you commit, and confirm soft delete is enabled with the retention period you documented. Property names can vary slightly between API versions, so check the full output if a field looks missing. Save the output with your change record.

Troubleshooting

  • A protected operation went through without approval. Either the vault isn’t associated with the Resource Guard, or that operation isn’t selected in the Resource Guard’s list of protected operations. Check both, then repeat the verification test.
  • The backup admin can change the Resource Guard. Separation of duties is broken. The Resource Guard should sit in a subscription, or tenant, where the backup admin has no standing role, with access granted only time-bound through PIM.
  • You can’t turn immutability off. If the state is Locked, that’s by design and can’t be reversed. If it’s still Unlocked, it can be disabled. That’s exactly why the runbook says to lock only after successful restore drills.
  • Retention changes fail after enabling immutability. Immutability blocks changes that would delete recovery points early, such as shortening retention. Plan retention before you lock the vault.

FAQ

Does immutability stop ransomware deleting my backups?

It stops recovery points being deleted before their retention ends. Attackers usually try to disable protection first, which is where soft delete and Resource Guard come in. The three layers work together. No single setting covers every path.

How long does soft delete keep deleted backup data?

Retention is configurable, up to 180 days with enhanced soft delete. Choose a period longer than the time it would realistically take you to notice an attack, and document it.

Do I need a separate tenant for the Resource Guard?

Not always. A separate subscription with different administrators is a solid start. A separate tenant gives the strongest isolation, so consider it for your most critical vaults.

How often should we re-run the verification test?

After any change to roles, PIM settings or vault configuration, and at least once a quarter as part of your restore drills.

Last reviewed: October 2026

Sources


Discover more from Cloud Osprey

Subscribe to get the latest posts sent to your email.

Cloud Osprey
Cloud Ospreyhttps://cloudosprey.com/about/
Hands-on Microsoft cloud practitioner writing practical, source-checked guides on Microsoft 365, SharePoint, Copilot, Entra ID, Power Platform and Azure. Formerly the author of SP Monkey, the SharePoint and Microsoft 365 blog, since 2016. Every guide links its sources and carries a "Last reviewed" date.

Recent Articles

Related Stories