Key Vault RBAC vs Access Policies: migrate now, your future self will thank you
Azure Key Vault has two permission models. One is the future, one is the past, and most of us are still using the past. Here's how to switch.
If you opened an Azure Key Vault five years ago, you used Access Policies. If you open one today, you'll see Microsoft now strongly recommends the RBAC permission model. They both work — but you should be moving everything to RBAC.
Here's why, and how.
What's actually different
Access Policies:
- Stored on the vault itself.
- Up to 1024 entries per vault.
- Different permission types for keys, secrets, and certificates managed independently.
- Not visible in Azure RBAC tooling — you have to look at the vault to see who has access.
Azure RBAC:
- Stored in Entra ID, alongside every other Azure permission.
- Unlimited assignments, supports groups natively.
- Built-in roles (Key Vault Administrator, Key Vault Secrets User, etc.).
- Visible in
az role assignment list, in Privileged Identity Management, in Defender, in Conditional Access — everywhere RBAC is.
The second category is why I've stopped using Access Policies entirely.
Why this matters operationally
When a security incident happens and someone asks "who has access to our production secrets?" — with RBAC you can answer in 30 seconds with az role assignment list --scope $VAULT_ID. With Access Policies, you're clicking through every vault one by one.
When a person leaves the company and you off-board them — with RBAC, removing them from the right Entra ID group revokes Key Vault access along with everything else. With Access Policies, you have to remember to clean up each vault.
When you implement Privileged Identity Management to make access just-in-time — RBAC roles plug straight into PIM. Access Policies don't.
The migration recipe
Step 1: Switch the vault's permission model.
az keyvault update \
--name my-vault \
--resource-group my-rg \
--enable-rbac-authorization true
⚠️ The moment you do this, existing access policies stop being honored. So you do step 2 first.
Step 2: Create equivalent role assignments first.
For every existing Access Policy, identify the equivalent built-in role:
| Access Policy permissions | Closest RBAC role |
|---|---|
| Get/List secrets | Key Vault Secrets User |
| Get/List/Set/Delete secrets | Key Vault Secrets Officer |
| Get/List/Set certificates | Key Vault Certificates Officer |
| Get/List/Sign/Wrap keys | Key Vault Crypto User |
| Full admin (everything) | Key Vault Administrator |
# Example: grant an app the Secrets User role
az role assignment create \
--role "Key Vault Secrets User" \
--assignee $APP_OBJECT_ID \
--scope $(az keyvault show -n my-vault --query id -o tsv)
Do this for every principal that currently has an Access Policy. Test the new role assignments with the --query "permissions" and az role assignment list --scope commands before flipping the switch.
Step 3: Flip the vault to RBAC mode (the command in step 1).
Step 4: Remove the legacy Access Policies.
az keyvault delete-policy --name my-vault --object-id $OBJ_ID
Or just leave them — they're inert in RBAC mode. I prefer to delete them for cleanliness.
The minor gotchas
Network policies still apply. The migration is just about the authorization layer. If you have firewall rules or Private Endpoint, those still need to be respected.
Apps using Managed Identity can need a small wait. Sometimes a freshly granted role takes 5–10 minutes to propagate. If your app immediately tests a secret read after the role grant, give it a buffer.
Built-in roles are sometimes too broad. If you need to grant only Get on secrets but not List, RBAC's built-in roles don't have that exact match — you'd need a custom role. For most teams this isn't worth it.
The bigger picture
Key Vault is the canary for "are you using Azure's identity model end-to-end?". If your secrets store has its own bespoke permission system that no other tool can see, your security posture has a blind spot.
Migrate. It takes a couple of hours per vault, and it pays back the next time you do an access review.