Role-Based Access Control for Azure Backup

The most common ransomware playbook now includes targeting backups. Before encrypting production data, attackers identify and delete the backup infrastructure. If your Azure Backup permissions allow the same accounts that run your applications to also modify or delete backup policies and recovery points, your backup is not protected.

RBAC for Azure Backup is how you separate the people who can read and restore from backup from the people who can delete it. This guide covers the built-in roles, how to apply them, and the security controls that matter most.

The three built-in backup roles

Azure provides three pre-built roles specifically for backup operations:

Backup Contributor grants full backup management rights: create and manage backup policies, create backup instances, trigger backups, modify retention settings, and delete backup items. This is the broadest backup role. It should be assigned only to backup administrators, not to application teams or general operations staff.

Backup Operator is the operational role: trigger backups, restore data, and monitor backup status. An operator cannot create or modify backup policies, cannot change retention settings, and cannot delete backup items. This is the right role for operations teams who need to respond to incidents without the ability to modify the backup configuration.

Backup Reader is read-only: view backup status, policies, and alerts. Audit teams, compliance officers, and senior management who need visibility without operational access use this role. No changes of any kind are possible.

Permission	Backup Contributor	Backup Operator	Backup Reader
Create/modify backup policy	Yes	No	No
Enable backup for a VM	Yes	No	No
Trigger on-demand backup	Yes	Yes	No
Restore data	Yes	Yes	No
Stop backup / delete data	Yes	No	No
View backup alerts	Yes	Yes	Yes
View backup jobs	Yes	Yes	Yes

Note: these roles apply to Azure Portal, REST API, PowerShell, and CLI operations. They do not govern the Azure Backup agent installed directly on Windows or Linux servers (the Mars agent), which uses its own authentication model.

Where to assign roles: scope matters

The scope of a role assignment determines which resources it covers. For backup operations:

Recovery Services vault level: The most precise scope. Assigning Backup Operator at the vault level limits the operator to backups within that specific vault. For environments with multiple vaults (per workload type, per environment, per team), vault-level assignments give granular control.

Resource group level: Assigns the role across all Recovery Services vaults in the resource group. Useful when vaults are organised by team or environment into resource groups and you want to grant team access to their own vaults without touching others.

Subscription level: Assigns across all vaults in the subscription. Appropriate for central backup administrators who manage all backup infrastructure. Do not use this scope for Backup Operator or Backup Contributor unless the person genuinely needs access to everything.

The principle of least privilege applies directly here. A developer who occasionally needs to restore a specific application's data does not need subscription-scope Backup Operator access. They need Backup Operator on the specific vault or resource group that contains their workload's backup.

Separating backup administration from production operations

The most important RBAC decision for Azure Backup security is ensuring that the accounts used to manage production workloads cannot also manage or delete backup infrastructure.

This means:

Separate the backup admin role from production admin roles. Subscription Owner and Contributor at subscription level include the ability to manage backup infrastructure. Application teams and DevOps engineers should not have these levels unless they genuinely need them. Scope their access to the resource groups they own, and assign backup roles only where needed.

Use dedicated accounts for backup administration. Backup Contributor should be assigned to accounts or groups dedicated to the backup function, separate from general IT or DevOps accounts. These accounts should be protected by PIM (requiring just-in-time activation with MFA and justification) rather than having standing active assignments.

Protect against delete with soft delete and multi-user authorisation. RBAC prevents unauthorised deletion of backup data, but it is not the only control. Enable soft delete on all Recovery Services vaults: deleted backup data is retained for 14 days in a soft-deleted state and can be restored. This protects against both accidental and malicious deletion. Multi-user authorisation (Resource Guard) adds an additional approval layer for sensitive operations: even a Backup Contributor cannot delete backup data without an approval from a Resource Guard owner, who is typically in a separate Azure subscription or under a different management hierarchy.

Use Microsoft Entra ID groups, not individual assignments

Assigning backup roles to individual user accounts creates two problems: a sprawl of individual assignments that are hard to audit, and a process gap when people join or leave the team. Use Entra ID groups instead.

Create a group for each backup role (e.g., Azure-Backup-Operators-Production, Azure-Backup-Readers-Audit). Assign the role to the group. Manage group membership through your standard joiner-mover-leaver process. When someone joins the backup operations team, add them to the group. When they leave, remove them. The role assignment does not change; the membership does.

This also simplifies audit: a single role assignment list shows "Azure-Backup-Operators-Production has Backup Operator on this vault" rather than dozens of individual user assignments.

Monitoring and alerting on backup permission changes

Changes to backup RBAC assignments should be logged and alerted. An unexpected grant of Backup Contributor or Backup Operator, particularly to an account that is not in the expected group, is a potential indicator of a compromised account attempting to establish persistence before an attack.

Azure Activity Log captures all role assignment changes. Route Activity Log to Log Analytics and create an alert rule:

AzureActivity
| where OperationNameValue == "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| where ActivityStatusValue == "Success"
| where ResourceGroup has "backup" or ResourceId has "recoveryservices"
| project TimeGenerated, Caller, ResourceId, Properties

Set this as a scheduled query alert running every 30 minutes. Route to your security operations channel rather than general email, so unexpected permission changes receive immediate attention.

Backup RBAC for regulated businesses

For FCA, PCI DSS, and DORA compliance, backup access controls need to be evidenced. Regulators and auditors ask: who can access your backup data? Who can delete it? How do you know your backups have not been tampered with?

RBAC assignments provide the access control evidence. Activity Log exports provide the audit trail. Soft delete provides tamper protection. Regular access reviews (via PIM or Entra ID Access Reviews) demonstrate that permissions are maintained deliberately and reviewed on a schedule.

The combination of these controls, documented in a backup security policy and evidenced with export data, satisfies the access control requirements of most frameworks.

Where Critical Cloud comes in

Getting backup RBAC right is part of a coherent backup security posture that also includes encryption, soft delete, multi-user authorisation, and tested recovery. We design and operate Azure Backup for regulated businesses where backup integrity is a compliance requirement, not just a best practice. As the world's first Powered by Datadog accredited partner, we monitor backup job success rates, soft delete events, and permission changes as live operational signals. See how Critical Support works.