Azure Key Vault Access Policy to RBAC Migration: How to Safely Move from Legacy Vault Policies Without Breaking Applications
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The Azure Key Vault permission model switch is the most dangerous part of the migration. When you enable RBAC authorization on a vault, every existing access policy is immediately ignored. Any application that was reading secrets via an access policy will receive 403 Forbidden errors from that moment forward. The safe migration requires creating all RBAC role assignments before switching the permission model. This guide covers the exact sequence, the permission mapping from access policies to RBAC roles, and the three scenarios that cause outages.
Auditing Existing Access Policies Before Migration
Before creating RBAC role assignments, inventory every existing access policy on the vault:
# List all access policies on a Key Vault
az keyvault show --name your-vault-name --resource-group your-rg \
--query 'properties.accessPolicies[].{ObjectId:objectId, Permissions:permissions}' \
--output table
# Resolve object IDs to display names
az keyvault show --name your-vault-name --resource-group your-rg \
--query 'properties.accessPolicies[]' | \
python3 -c "import json,sys; policies=json.load(sys.stdin); \
[print(p['objectId'], p['permissions']) for p in policies]"
For each object ID, resolve the identity type and name:
# Resolve a specific object ID to its display name and type
az ad object show --id "object-id-here" --query '{displayName:displayName, type:objectType}'
Categories to identify:
- Managed identities (application workloads that read secrets at runtime)
- Service principals (CI/CD pipelines, automation accounts)
- User accounts (individuals who manage vault contents)
- Groups (teams with shared vault access)
For each identity, note exactly which permissions are granted: get, list, set, delete, backup, restore, recover, purge for secrets; same categories for keys and certificates. This is your permission inventory that drives the RBAC role assignment plan.
Mapping Access Policy Permissions to RBAC Roles
Access policy permissions map to RBAC roles as follows:
Key Vault Secrets User (get, list on secrets):
For applications that read secret values at runtime. Managed identities running application workloads should use this role. This is the minimum permission for reading a secret value.
Key Vault Secrets Officer (get, list, set, delete, backup, restore, recover, purge on secrets):
For identities that manage the contents of the vault (create/update/delete secrets). CI/CD pipelines that rotate secrets, or security team members who manage vault contents, use this role.
Key Vault Reader (lists vault properties, does NOT allow reading secret values): Misleading name. This role allows listing the vault's metadata but does NOT grant permission to read secret values. This is a common migration mistake: granting Reader thinking it allows secret access.
Key Vault Administrator: Full control of the vault including permission management. Equivalent to granting all access policy permissions. Scope this role tightly -- grant at the vault level, not at subscription or resource group scope.
Key Vault Crypto User (get, list, sign, verify, encrypt, decrypt, wrapKey, unwrapKey on keys):
For workloads that use Key Vault for cryptographic operations (data encryption, token signing).
Create a mapping table before migration:
| Identity | Current Permissions | Target RBAC Role | Scope |
|---------|---------------------|-----------------|-------|
| app-prod-mi | secrets: get,list | Key Vault Secrets User | vault |
| cicd-sp | secrets: get,list,set | Key Vault Secrets Officer | vault |
| infra-team-group | all permissions | Key Vault Administrator | vault |
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The Safe Migration Sequence
The critical rule: create RBAC role assignments BEFORE switching the permission model. The switch is effectively instantaneous on the Azure side.
Step 1: Create all RBAC role assignments while vault is still in access policy mode
# Get the vault's resource ID
VAULT_ID=$(az keyvault show --name your-vault-name --resource-group your-rg --query id -o tsv)
# Assign Key Vault Secrets User to a managed identity
az role assignment create \
--role "Key Vault Secrets User" \
--assignee-object-id "managed-identity-object-id" \
--assignee-principal-type ServicePrincipal \
--scope $VAULT_ID
# Assign Key Vault Secrets Officer to a service principal
az role assignment create \
--role "Key Vault Secrets Officer" \
--assignee-object-id "service-principal-object-id" \
--assignee-principal-type ServicePrincipal \
--scope $VAULT_ID
Step 2: Verify role assignments are in place
az role assignment list --scope $VAULT_ID --output table
Confirm every identity from your mapping table has the correct role assigned.
Step 3: Test access with RBAC assignments while still in access policy mode
For each workload identity, verify the role assignment allows the expected operations. Use az keyvault secret show with the identity's token to confirm access works under RBAC. At this point the vault is still in access policy mode, so both access policies and RBAC assignments may coexist -- test that RBAC access works independently.
Step 4: Switch the vault to RBAC authorization
az keyvault update --name your-vault-name --resource-group your-rg \
--enable-rbac-authorization true
This command switches the model. Existing access policies are now ignored. All access goes through RBAC.
Step 5: Verify workloads immediately after switch Monitor application logs and Key Vault diagnostic logs for 403 errors in the 15 minutes after the switch.
The Three Outage Scenarios and How to Avoid Them
Scenario 1: Managed identity RBAC assignment missing The application's managed identity has an access policy but no corresponding RBAC role assignment was created before the switch. After the switch, the app receives 403 Forbidden.
Fix: Add the role assignment post-migration. RBAC changes take effect within 5-10 minutes in Azure.
az role assignment create \
--role "Key Vault Secrets User" \
--assignee-object-id "missed-mi-object-id" \
--assignee-principal-type ServicePrincipal \
--scope $VAULT_ID
Scenario 2: Group-based access policy migrated to user direct assignment instead of group role assignment A group was in the access policy. During migration, individual users in the group got direct role assignments instead of the group itself. New team members added to the group in the future will not have access.
Fix: Assign the RBAC role to the Entra ID group, not to individuals. Remove individual role assignments that duplicate group-based assignments.
Scenario 3: Certificate and key permissions missed The migration focused on secrets and missed the key or certificate permission mappings. Applications using Key Vault for TLS certificate retrieval or data encryption may stop working if key/certificate access policies were not migrated.
Fix: During the audit phase, explicitly check secrets, keys, and certificates sections of each access policy separately. Create RBAC assignments for Key Vault Crypto User and Key Vault Certificate User in addition to Secrets User where needed.
Scoping RBAC Assignments for Multi-Vault Environments
RBAC role assignments can be scoped at four levels: management group, subscription, resource group, or individual resource (vault). Multi-vault environments benefit from resource-group-level scoping when all vaults in the group should have the same access pattern:
# Assign Secrets User at resource group level (applies to ALL vaults in the group)
RG_ID=$(az group show --name your-rg --query id -o tsv)
az role assignment create \
--role "Key Vault Secrets User" \
--assignee-object-id "shared-app-mi-object-id" \
--assignee-principal-type ServicePrincipal \
--scope $RG_ID
Use resource group scoping for:
- A single application stack that uses multiple vaults (dev secrets, prod secrets, TLS certs) with the same managed identity
- An infra team that manages all vaults in a subscription uniformly
Use vault-level scoping (most restrictive) for:
- Applications that should access exactly one vault and no others in the resource group
- Third-party service principals that need minimal blast radius
Never use subscription-level scoping for application workloads. Subscription-level grants access to every Key Vault created in that subscription in the future, violating least privilege.
After migration, enforce vault-level RBAC scope via Azure Policy:
# Deny vault access policy mode via Azure Policy (enforce RBAC-only going forward)
az policy assignment create \
--name "deny-keyvault-access-policy" \
--policy "/providers/Microsoft.Authorization/policyDefinitions/12d4fa5e-1f9f-4c21-97a9-b99b3c6098e3" \
--scope "/subscriptions/your-subscription-id"
The bottom line
The Key Vault permission model switch is instantaneous and breaks all access policy-based access the moment it is enabled. The safe migration pattern is always: audit all access policies, create all RBAC role assignments, verify them, then switch. Do not switch first and fix access breaks reactively. Use the smallest RBAC role (Secrets User, not Secrets Officer) for read-only application workloads, assign at vault scope rather than resource group unless multi-vault access is intentionally needed, and enforce RBAC-only mode via Azure Policy to prevent new vaults from defaulting to access policies.
Frequently asked questions
Can I keep both access policies and RBAC assignments active at the same time during migration?
No. When a Key Vault is in access policy mode (the default), only access policies are evaluated. RBAC role assignments exist but are ignored. When the vault is switched to RBAC mode, only RBAC assignments are evaluated. You cannot run both simultaneously. This is why you must create and verify RBAC assignments before switching, not after.
What is the difference between Key Vault Secrets User and Key Vault Reader?
Key Vault Secrets User grants `get` and `list` on secret values -- it allows reading the actual secret content. Key Vault Reader grants read access to the Key Vault resource metadata (name, properties, access control configuration) but does NOT allow reading secret values, keys, or certificates. Reader is used for visibility into the vault's configuration, not for application workloads that need secret values. This distinction confuses many Azure practitioners who assume Reader = read everything.
How do I find all Key Vaults in my subscription that are still using access policy mode?
Run: `az keyvault list --subscription your-subscription-id --query "[?properties.enableRbacAuthorization!=true].{Name:name, ResourceGroup:resourceGroup, RbacEnabled:properties.enableRbacAuthorization}" --output table`. Vaults showing `None` or `False` for RbacEnabled are still using access policy mode. Use Azure Policy with the audit effect to generate compliance findings for all vaults not using RBAC authorization.
What happens to existing access policies after I switch to RBAC mode?
The access policy entries remain in the vault's configuration but are completely ignored. They will not be evaluated for any access decisions. If you switch back to access policy mode, the policies become active again. This is why the switch is technically reversible -- the policy entries are not deleted automatically. However, best practice after a successful RBAC migration is to delete the access policy entries to reduce confusion and prevent accidental reversion to policy mode from inadvertently restoring unintended access.
How do I detect when a new access policy or RBAC role assignment is added to a Key Vault?
Enable Diagnostic Settings on each Key Vault to send audit logs to a Log Analytics workspace, Event Hub, or Storage Account. The relevant log category is AuditEvent. In Log Analytics, query: `AzureDiagnostics | where ResourceProvider == 'MICROSOFT.KEYVAULT' | where OperationName == 'VaultPatch' or OperationName == 'SetAccessPolicy'`. For RBAC assignment changes on the vault, monitor Azure Activity Logs for 'Write roleAssignments' operations scoped to the Key Vault resource ID. Create a Sentinel analytics rule or Azure Monitor alert on these operations to notify the security team of any access control changes within minutes.
What is the security difference between Key Vault access policies and RBAC?
Access policies are a legacy Key Vault authorization model where permissions are granted per-vault to specific security principals with fixed permission bundles (for example, granting all secret Get, List, Set, Delete permissions together). RBAC authorization uses Azure role assignments at the vault, secret, key, or certificate level, enabling much finer-grained control (for example, a role that can only Get a specific secret by name). With RBAC, access is audited and managed through the same Azure RBAC tooling and logs as all other Azure resources, making governance more consistent. Microsoft recommends migrating to RBAC for new Key Vaults. The primary RBAC roles are Key Vault Secrets Officer (full management), Key Vault Secrets User (read secret values only), and Key Vault Reader (view metadata without reading values).
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.