Azure Backup: soft delete, immutable vaults and multi-user authorisation against a compromised admin

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Azure Backup has three controls for this threat, and they do different jobs. Soft delete delays permanent deletion. A locked immutable vault blocks the operations that would remove recovery points early. Multi-user authorisation (MUA) requires a second person's access before critical settings change.

Against a compromised backup administrator you generally want all three, with the MUA control held outside that administrator's reach. Microsoft is explicit that its logical separation of backup data does not replace controls over the identities that manage the vault.

The commands below come from Microsoft's published reference and were not run in a lab for this article.

Why it matters

Backups are often the first thing an attacker with administrative access goes after, because removing them turns an incident into a negotiation. Vaulted data sits in a Microsoft-managed subscription and tenant, separate from production. That helps against a compromised workload. It does nothing about a compromised account that can legitimately ask the vault to delete things.

So the useful question is not whether the backups are isolated. It is which operations a stolen administrator credential can still complete.

What a compromised administrator can try

The built-in Backup Contributor role can do every backup management operation except delete the vault and grant access to others. Backup Operator cannot remove backups or manage policies. That split helps only if accounts actually hold the narrower role.

This table maps each attack to what stands in its way. It is an editorial summary of the restricted operations and critical operations pages, for a Recovery Services vault.

The last row deserves attention. Restore is listed as a critical operation, but its default value is Disabled. Unless you turn it on, MUA does not gate an attacker reading your data out through a restore.

Soft delete: a delay with an end date

Deleted backup data stays recoverable for a configurable 14 to 180 days, with 14 as the default. After the retention period, the item is permanently deleted and cannot be restored. Microsoft states plainly that soft delete does not provide indefinite retention.

Fourteen days of soft-delete retention carry no cost for vaulted backups, and additional days attract regular backup charges. Microsoft's billing example applies the free period to the last 14 days of a longer retention, so a 60-day setting pays for the first 46. The free period does not apply to soft-deleted operational disk backups or VM snapshots, which continue to bill at the cost of the resource.

Three details matter during an incident:

• The retention active at the time of deletion governs that item. You can change the setting at any time. So shortening it first and deleting second gives a shorter window. Changing the duration is not named in Microsoft's list of critical operations. That inference is editorial, so test it in your own tenant.
• Undeleting restores the item to a stopped state, Stop protection with retain data. Backups do not resume until someone selects Resume backup.
• Recovery points removed by a policy change can take up to 24 hours to show as soft deleted. Microsoft also says soft delete of recovery points does not cover SQL Server and SAP HANA log recovery points.

Is it actually enforced in your region?

Microsoft's pages disagree, so check rather than assume. The feature page lists Recovery Services vaults as generally available in all public regions and national clouds, while also saying enforcement is "currently in preview" for them. The same page has a note that you can't disable soft delete in the regions where secure-by-default assurance is in preview or general availability, which sits against the older-API exception described below. The older configuration page names only West Central US as generally available.

For Backup vaults, the feature page lists Australia East as generally available. In other regions you can still disable soft delete from the portal.

The client version also matters where enforcement is in preview. Older clients can bypass it. This table applies to disabling soft delete during preview. Where enforcement is generally available, Microsoft says it is not allowed from any client or API version.

Microsoft notes that in preview regions you can still use older API versions to disable soft delete immediately and delete backup items. An attacker can choose an old API version too. That is the practical reason not to rely on preview enforcement alone.

Read the current state of a Recovery Services vault with this command:

az backup vault backup-properties show --name <vault> --resource-group <rg>

Soft delete has an edge

Soft delete extends to disk operational backups and VM snapshots used for instant restore. Unlike vaulted data, those snapshots can be directly accessed and deleted before the soft-delete period expires. Treat them as a convenience for fast restores, not as protected copies.

Immutable vault: blocking the operation

Immutability has three states:

WORM means write once, read many. While only enabled, the protection is reversible, so anyone with Backup Contributor on the vault can switch it off unless MUA also guards that operation.

On a Recovery Services vault with immutability based on backup policy, it blocks stop protection with deletion of data, and any policy change that would reduce retention. You can still stop protection and retain the data, change a schedule or increase retention.

There are two ways to set the duration:

• Based on backup policy, the default. Points stay immutable for as long as the policy keeps them.
• For a specific duration. Points are immutable for a fixed number of days, then remain until policy expiry but can be deleted. With 180 days of retention and 30 days of immutability, the last 150 days of each point's life are not protected by immutability. Retention can be reduced only down to the configured immutability duration, and a replacement policy with lower retention is accepted on the same terms.

The specific-duration option suits cost control, but note that the window applies uniformly to every recovery point in the vault and is locked along with the setting.

That changes the threat picture. Our reading, which Microsoft does not state in these words, is that a compromised administrator with no MUA in the way can cut that example's retention to 30 days with one policy change, even on a locked vault. The 150-day tail is then gone, subject to soft delete.

Boundaries that catch people out

• Immutability applies to all data in the vault. You cannot exempt one workload, so workloads with different retention needs may need separate vaults. That last step is editorial.
• It does not apply to operational backups of blobs, files and disks.
• It cannot be locked during vault creation. Enable it first and lock it later in vault properties.
• For Backup vaults, specific-duration immutability is supported only in Australia East, North Europe and West Central US.
• A retention increase can't be applied if any item has its backups suspended.

What WORM means in Australia

For Recovery Services vaults, the published list of regions with WORM storage generally available includes Australia Central 2, but not Australia East, Southeast or Central on the date this was checked.

In regions and workloads not yet listed, locked immutability is still enforced by the backup service, and backups move to WORM-backed storage automatically once it arrives. If a contract or auditor specifies WORM media, check the list for your region. For Backup vaults, Microsoft lists WORM as generally available in all public regions and not in national clouds, for Azure Kubernetes Service, Azure Database for PostgreSQL and Azure Cosmos DB workloads.

Multi-user authorisation: a second key

MUA uses a separate Azure resource called a Resource Guard. For a critical operation to succeed, the caller needs sufficient permission on the guard as well as on the vault.

Microsoft sets two conditions for it to function as intended: a different user must own the Resource Guard, and the vault administrator must not have Contributor, Backup MUA Admin or Backup MUA Operator on it. Those roles override the MUA protection.

Where the guard sits decides what it protects against

Microsoft ranks three layouts:

The guard should be in the same region as the vault.

Consider who could reach the guard in each layout. A Global Administrator can elevate to User Access Administrator at root scope, which allows them to assign access in any subscription in the tenant. The conclusion is editorial: a guard in the same tenant does not stand up to a compromised Global Administrator of that tenant, and a separate tenant does better.

Setting it up

The security administrator creates the guard, using the documented command:

az dataprotection resource-guard create --location "<region>" \
  --resource-group "<guard-rg>" --resource-guard-name "<guard-name>"

The security administrator then grants the backup administrator Reader on the guard, which is needed to enable MUA on the vault. The backup administrator associates the two:

az backup vault resource-guard-mapping update \
  --resource-group <vault-rg> --name <vault> \
  --resource-guard-id <guard-resource-id> --tenant-id <guard-tenant-id>

The --tenant-id option is required when the guard is in a different tenant. Confirm the mapping with az backup vault resource-guard-mapping show.

Operations can be excluded from protection, except the mandatory ones. Exclusions apply to all vaults associated with that guard, so sharing one guard across vaults means sharing its exclusion list.

The approval flow is the weak point

Grant the Backup MUA Operator role only, and only temporarily. It permits the protected operations without allowing deletion of the guard. Contributor or Backup MUA Admin would also give delete rights over it.

Microsoft recommends Entra Privileged Identity Management for the temporary grant. Note that the default setup may have no approver configured. If none is set, Microsoft says requests are automatically approved without review, which defeats the second person. Add reviewers in the role settings, and consider multifactor authentication and a mandatory ticket.

MUA also has a stated limit. It covers vaulted backup operations only. Actions taken directly on the protected resource are out of its scope.

Encryption keys are a separate route

If a vault uses customer-managed keys, the key becomes a target. Microsoft requires soft delete and purge protection on the key vault holding the key. Keep "Modify encryption settings" protected by MUA, and control who can administer that key vault. Whether the same people should manage both is an editorial question, and the safer answer is no.

Detection

Azure Backup sends alerts by default through Azure Monitor for scenarios including backup data deletion, without a Log Analytics workspace. Microsoft's guidance routes such alerts to a notification channel using an action rule. Point it at a mailbox or system the backup administrator cannot alter. That placement is editorial.

Azure also publishes a security level for protected items:

It is a useful inventory check. It does not tell you where the Resource Guard sits or who can reach it.

What to choose and why

These are editorial recommendations.

Use this as a design and validation checklist. Agree each protection change separately; locking has an irreversible outcome:

1. Set soft-delete retention long enough to outlast your realistic time to detect a compromise.
2. Move day-to-day accounts to Backup Operator where possible.
3. Create the Resource Guard in a subscription or tenant the backup administrators cannot reach, and add PIM approvers.
4. Enable immutability without locking it, using this documented state value: --immutability-state Unlocked.
5. On a test vault, try a retention reduction and a stop-with-delete, and confirm they fail. Try disabling soft delete without the MUA role.
6. Run a restore, and prove that a soft-deleted test item can be undeleted.
7. Review the retention, existing recovery points, regional WORM support and whole-period cost. A qualified owner must approve the irreversible lock only after an isolated rehearsal and successful restores. This source-only article does not provide a production locking runbook.

Risks and limits

Warning: locking immutability is irreversible. With immutability based on backup policy, retention cannot then be reduced. With a specific duration, it can be reduced only down to that duration. Microsoft's advice is to lock only after you are satisfied with the impact. An error in policy retention could leave you paying for that retention until the points expire. That cost consequence is editorial.

Warning: the commands here change protection on live vaults. Test on a non-production vault, and do not use Locked until the sequence above has passed.

• Stopping a backup and retaining per policy keeps the last hardened and latest points forever, until you delete them manually. Allow for that cost.
• Undeleting a vault does not bring back everything. Managed identities and private endpoints must be reassigned or recreated, and items must be undeleted separately.
• Resource locks do not replace these controls, in this article's view. A cannot-delete lock stops deletion of the locked resource only, and the same lock on the resource group Azure Backup creates makes backups fail, because the service cannot clean up restore points.
• Availability differs by vault, workload and region, and several related features remain in preview, including threat detection and cross-tenant restore.
• None of this helps if clean recovery points have already expired. Retention must exceed the time an intruder can remain undetected.

Sources

Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.

• Azure Backup security overview
• Secure by default with soft delete
• Configure and manage soft delete
• Immutable vault concepts
• Manage immutable vault operations
• Multi-user authorisation concepts
• Configure multi-user authorisation
• Backup RBAC roles
• Backup best practices
• Encryption with customer-managed keys
• Elevate access for a Global Administrator
• Lock your resources
• az backup vault
• az backup vault backup-properties
• az backup vault resource-guard-mapping

This article was originally published on 10 November 2026.