azureblog.co.uk
← cd ~/posts

Key Vault: move from access policies to Azure RBAC

Key Vault has two permission models. Azure RBAC is the recommended one, and switching is simpler than it looks if you plan the role mapping first.

2 min read✓ checked 12 Aug 2026Azure · Security
Part 5 of 6 in Locking down admin access
On this page
  1. Why RBAC is better
  2. Common role mappings
  3. Switching over
  4. Finding vaults still on access policies

can control data access with vault access policies (the original model) or Azure RBAC. Microsoft recommends , and there are good reasons.

Vault access policies

Legacy model

  • Set on the vault itself
  • Whole-vault scope only
  • Vault managers can grant themselves data access
  • No PIM

Azure RBAC

Recommended

  • Same model as all Azure resources
  • Scope to vault or a single secret
  • Separates management from data access
  • Works with PIM and access reviews
The two permission models for Key Vault data.

Why RBAC is better

  • One model everywhere. Permissions are managed the same way as every other Azure resource, and they appear in the same reviews and reports.
  • PIM support. Data-plane roles can be made eligible and time-boxed.
  • Finer scope. Roles can be assigned on a single secret, key or certificate, not just the whole vault.
  • Separation of duties. With access policies, anyone who can manage the vault can grant themselves access to its secrets. With RBAC, data access needs a role assignment permission they may not have.

Common role mappings

RoleUse for
Key Vault Secrets UserApps that read secrets
Key Vault Crypto UserApps that use keys to encrypt, decrypt, sign or verify
Key Vault Certificate UserApps that read certificates
Key Vault Secrets OfficerPeople who manage secrets
Key Vault AdministratorFull data-plane management. Use sparingly, ideally through .
What does it do with the vault?
App reads secretsKey Vault Secrets User
App encrypts or signs with keysKey Vault Crypto User
Person rotates secretsKey Vault Secrets Officer, ideally eligible through PIM
Manages vault settings onlyKey Vault Contributor (no data access under RBAC)
Which role does this identity need?

Switching over

  1. List the existing access policies and map each to an RBAC role.
  2. Create the role assignments before switching. Role assignments can take a few minutes to take effect.
  3. Switch the permission model:
shell
az keyvault update --name kv-app-prod --resource-group rg-app --enable-rbac-authorization true
  1. Test every app that uses the vault. If something breaks, switching back restores the old access policies.
Note: changing the permission model is itself a sensitive operation. Restrict who can do it, and treat it as a change, not a tweak.

Finding vaults still on access policies

kql
// Azure Resource Graph
resources
| where type == "microsoft.keyvault/vaults"
| extend rbac = tobool(properties.enableRbacAuthorization)
| where rbac != true
| project name, resourceGroup, subscriptionId

Pair this with the built-in that audits Key Vaults not using RBAC, so new vaults don't add to the list.

  • Map every access policy to a role
  • Create role assignments and wait for them to apply
  • Switch the permission model
  • Test each app and pipeline
  • Remove leftover Contributor rights that were only there for access policies
Does switching delete the access policies?

They're kept but ignored while RBAC is on. Switching back makes them active again, which is your rollback.

Who can make the switch?

Changing the permission model needs permission to create role assignments, such as Owner or User Access Administrator, because it changes who can reach the data.

Next in Locking down admin access · part 6 of 6Entra Backup and Recovery is here: an undo button for your tenant →

Related posts