Require independent authorization for destructive Azure Backup operations

A backup administrator who can also remove the backup’s protective controls creates a concentrated failure path. Azure Backup multi-user authorization can require separately governed access for protected operations, but the separation must exist in identities, roles, subscriptions or tenants, and operating practice—not only in the diagram.

Source fact:

Microsoft’s Azure Backup configuration guidance describes multi-user authorization, or MUA, for critical operations on Recovery Services vaults and Backup vaults. MUA uses a separate Azure resource called Resource Guard. When an operation is protected, a backup administrator without the required Resource Guard role cannot complete it.

Microsoft recommends locating Resource Guard in a different subscription or tenant from the protected vault for greater isolation, while requiring the guard and vault to be in the same Azure region. The guidance says the backup administrator must not hold Contributor, Backup MUA Admin, or Backup MUA Operator access on the Resource Guard. It documents just-in-time access using Microsoft Entra Privileged Identity Management as one authorization method and recommends testing after MUA is enabled to confirm that protected operations are blocked as expected.

Boundary

Supported vault types, regions, protected-operation lists, roles, cross-tenant prerequisites, clients, and procedures can change. Verify the current documentation for the deployed service and interface. Resource Guard does not prove that backups run, remain complete, meet retention requirements, resist every identity or platform compromise, or can be restored. It protects only the operations placed in scope. A separate tenant can improve administrative isolation while adding identity, emergency-access, provider-registration, and recovery dependencies.

Applicability questions

• Which Recovery Services and Backup vaults hold data needed for each recovery objective?
• Which currently supported operations could delete recovery data, weaken protection, reduce retention, or remove MUA?
• Are Resource Guard owners genuinely independent from routine backup administrators and subscription-wide privileged roles?
• Can the chosen subscriptions or tenants meet the documented same-region and resource-provider prerequisites?
• How will an authorized emergency request be approved if ordinary identity, email, ticketing, or the primary tenant is impaired?

DSE recommendation:

Inventory vaults, protected workloads, owners, recovery objectives, role assignments, and critical operations. Define a security-administration group that does not report through or share standing credentials with routine backup administration. Select Resource Guard placement from the organization’s threat model and Microsoft’s current prerequisites. Keep the guard description and runbook clear enough to direct an administrator to the approved access process without exposing credentials.

Protect every supported operation that the risk decision requires; document any excluded operation and owner. Use eligible, time-limited access and approval through PIM or another controlled method appropriate to the environment. Require a ticket or incident reference, reason, target vault, exact operation, duration, and approver. Monitor Resource Guard mapping, exclusions, role changes, activation, protected-operation attempts, and removal of MUA through a channel independent of the backup operator.

In nonproduction, enable MUA and first prove that a normal backup administrator cannot perform each protected operation. Then exercise the approved path, including cross-tenant authentication if used, role expiration or removal, and an emergency-access scenario. Separately perform a representative restore test; authorization protection and recoverability are different proofs.

Verification and evidence

Keep the vault-to-guard register, current Microsoft prerequisites, tenant and subscription placement, role exports, selected protected operations, exclusions, approval design, blocked-attempt logs, authorized test transcript, role-removal evidence, alert results, and independent restore record. Do not retain access tokens or recovery credentials in the evidence package. Recheck after Azure feature, role, tenant, subscription, ownership, PIM, or vault changes.

Official references

• Microsoft Learn: Configure MUA using Resource Guard in Azure Backup
• Microsoft Learn: Azure Backup security best practices