Azure Key Vault RBAC should replace your old access policies

Anyone who has looked after Azure Key Vault for a while knows how annoying classic access policies can be. They're easy to set up, but in larger or more mature environments they get unwieldy fast. I still come across lots of vaults that run on all-or-nothing access policies, even though the same organizations are asking for tighter security and governance. Azure Key Vault RBAC tends to get pushed down the list because the migration looks like extra work, yet the difference in risk and manageability is too big to ignore.

Access policies cause real problems in practice

Access policies are a blunt tool. Permissions are set per vault, not per secret or certificate, and you can't scope them to individual objects. Anyone with Contributor on the vault can grant themselves access, so proper governance and least privilege simply aren't possible. You can't use Privileged Identity Management (PIM) for time-bound access, and there's no clean audit trail for role assignments or access requests. In many of my projects these limits cause friction between operations and security, particularly once an audit or an incident investigation comes along.

Azure Key Vault RBAC brings the granularity we know from the rest of Azure

With the Azure Key Vault RBAC model you get the same granularity and consistency you already have elsewhere in Azure. You assign roles such as Key Vault Secrets User, Key Vault Crypto User, Key Vault Administrator and Key Vault Reader at the vault level or even on an individual secret or key. Assignments can go to users, groups or the managed identities of your apps. Combined with PIM, admin access becomes eligible only, with approval and a time limit. Entra and Azure audit logs record both changes and access, which gives you the visibility compliance requires (security features).

The migration to RBAC works best in stages

The switch doesn't need to disrupt anything. Microsoft's migration guide describes a sensible approach. I normally begin by mapping the existing access policies to the closest RBAC roles, and I handle the managed identities of production apps first, since most business processes depend on them. Assign the RBAC roles alongside the existing policies and test properly before you change the vault permission model to Azure RBAC. I only disable the old access policies once I'm sure no app has broken. Working in stages like this avoids outages and makes sure nothing business-critical loses access.

The diagram below shows the usual sequence:

graph TD
    A["Read access policies"] --> B["Assign RBAC roles"]
    B --> C["Test app/identity access"]
    C --> D["Switch Vault to RBAC model"]
    D --> E["Finalize and remove legacy policies"]

Figure: Typical migration workflow to Azure Key Vault RBAC

Practical tip: Before I switch the model, I always write down the old access policies in detail. If something goes wrong, the mapping and troubleshooting are much simpler.

I assign roles with PowerShell. When there are several vaults or a lot of identities, it's quicker than clicking through the Azure Portal:

New-AzRoleAssignment -ObjectId <ManagedIdentity-ObjectId> -RoleDefinitionName "Key Vault Secrets User" -Scope "/subscriptions/<SubId>/resourceGroups/<RG>/providers/Microsoft.KeyVault/vaults/<VaultName>"

A secure vault needs more than RBAC

Moving to RBAC is only one part of securing Key Vault. I insist on soft-delete and purge protection for every vault, because without them secrets can be wiped by accident or on purpose. I still find vaults without this basic protection far too often. Limiting vault access with private endpoints and firewalls should also be standard practice. Azure Policy lets you audit every vault that still uses the legacy access policy model (RBAC guide).

I no longer consider RBAC optional

Azure Key Vault RBAC has stopped being a "nice to have". The old access policies are outdated, and in a modern Azure environment they're a genuine risk. Once you switch, Key Vault permissions follow the same model as the rest of your Azure security, and you get better auditability, consistency and control. Add PIM, Azure Policy, soft-delete and network controls on top, and your platform will be in much better shape for whatever comes next.

If you want more practical governance and security advice, have a look at my posts on Conditional Access baseline policies and Azure cost management.