If you manage Azure infrastructure long enough, you eventually hit the same fork in the road: a new Key Vault needs an access model, and Azure gives you two incompatible ways to grant it — access policies or role-based access control (RBAC). The Key Vault access policy vs RBAC decision looks cosmetic at first glance, but it determines whether your permission grants show up in Azure AD audit logs, whether you can scope access to a single secret, and whether a departing contractor's vault access actually gets revoked when their account is disabled. Microsoft has been steering customers toward RBAC since it reached general availability in 2020, but access policies are still the default on vaults created years ago, and mixing the two models on the same vault is not supported. Below, we break down how each model actually works, when to keep access policies, and how to migrate without locking yourself out of production secrets.
Key Vault Access Policy vs RBAC: What's Actually Different?
The core difference is where the permission lives and how granular it can get. Access policies are a Key Vault-native feature: each vault carries its own list of up to 1,024 access policy entries, and every entry grants an identity a set of permissions across four object types — keys, secrets, certificates, and (for legacy vaults) storage accounts. There's no concept of "read this one secret but not that one" — an access policy that grants Get on secrets grants it for every secret in the vault. RBAC, by contrast, uses Azure's standard Microsoft.Authorization role assignment system, the same one that governs storage accounts, VMs, and resource groups. Roles like Key Vault Secrets User or Key Vault Crypto Officer can be assigned at the management group, subscription, resource group, vault, or — critically — individual object level, so you can grant a CI/CD identity access to exactly one secret instead of the whole vault. RBAC assignments also flow through Azure AD's audit trail (Azure Activity Log and Azure AD sign-in logs), while access policy changes are logged only as vault configuration events, which makes incident reconstruction meaningfully harder.
When Should You Actually Use Access Policies Instead of RBAC?
You should still reach for access policies in a shrinking set of cases: vaults in regions or Azure Stack environments where RBAC for Key Vault data actions isn't yet supported, legacy automation that authenticates with certificate-based service principals hardcoded to the access policy model, or short-lived test vaults where the operational overhead of role assignment propagation isn't worth it. Access policy changes apply immediately, while RBAC role assignments can take up to 10 minutes to propagate globally — a real problem if a deployment pipeline provisions a vault and immediately tries to write a secret to it. Outside of these edge cases, Microsoft's own guidance is unambiguous: RBAC is the recommended Azure Key Vault permission model for any new vault, and has been since it moved to general availability. If you're standing up a vault today with no legacy constraint, there's no good reason to choose access policies.
What Does the Azure Key Vault Permission Model Look Like Under RBAC?
Under RBAC, permissions are split cleanly between control plane and data plane, which is the single biggest mental shift for teams coming from access policies. Control plane actions — creating the vault, setting network rules, configuring diagnostic logging — are governed by standard Azure roles like Contributor. Data plane actions — reading a secret value, signing with a key, listing certificates — require one of roughly a dozen Key Vault-specific built-in roles: Key Vault Administrator (full data plane access), Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Certificates Officer, Key Vault Crypto Officer, Key Vault Crypto User, and Key Vault Reader among them. This split matters operationally: under the old access policy model, anyone with Contributor rights on the vault resource could also grant themselves data access, because access policies were themselves a control-plane property of the vault. Under RBAC, an Azure subscription owner does not automatically get to read secrets — they'd need an explicit Key Vault Secrets User (or higher) role assignment, which closes a privilege-escalation path that shows up repeatedly in cloud security assessments.
How Do You Plan a Key Vault RBAC Migration Without Breaking Production?
Plan a Key Vault RBAC migration by inventorying every identity in the vault's current access policy list before you flip the switch, because the two models cannot coexist — enabling RBAC on a vault disables its access policies entirely, effective immediately. Start by pulling the existing policy list (az keyvault show --query properties.accessPolicies), mapping each object-type/permission combination to the closest built-in RBAC role, and pre-creating those role assignments while the vault is still in access policy mode — role assignments can be created regardless of the vault's current authorization model, so there's no reason to do this live. Set the vault's enableRbacAuthorization property to true only after every existing identity has a corresponding role assignment in place, and budget for that 10-minute propagation window before cutting over dependent pipelines. Teams that skip the inventory step are the ones who discover, mid-incident, that a forgotten Logic App connector lost secret access the moment RBAC was enabled. A staged rollout — enabling RBAC on a non-production vault clone first, validating every consumer, then repeating on production during a maintenance window — is the difference between a clean migration and a Sev1.
What Goes Wrong When Key Vault Access Control Is Misconfigured?
The most common failure is over-broad grants: an access policy or RBAC role assigned at too high a scope, most often Key Vault Administrator or Contributor handed to an entire engineering team instead of the two or three identities that actually need write access. In access policy vaults, this is compounded by the all-or-nothing object-type model — a support engineer who needs to read one certificate for a renewal ends up with Get, List, and often Delete across every key, secret, and certificate in the vault, because access policies don't support object-level scoping. Poor Key Vault access control also shows up as stale grants: service principals from decommissioned applications still holding Get/Set on secrets months after the app was retired, because access policy cleanup isn't tied to any lifecycle event the way Azure AD group membership changes are. In our own assessments across customer Azure tenants, the two findings we flag most often are vaults where more than half the access policy entries belong to identities with no corresponding active resource, and vaults where a broad role like Owner or Contributor was used as a substitute for a properly scoped Key Vault Secrets User assignment — a shortcut that works until it doesn't.
How Safeguard Helps
Safeguard treats Key Vault permissions as part of your software supply chain attack surface, not a one-time IAM checkbox. Our platform continuously inventories every access policy entry and RBAC role assignment across every vault in your Azure tenants, flags identities whose Key Vault access control grants exceed what their actual usage pattern justifies, and surfaces stale service principals still holding secret or key permissions long after the workload that needed them was decommissioned. During a Key Vault RBAC migration, Safeguard maps your existing access policy entries to their nearest built-in RBAC roles automatically, so security and platform teams can validate the mapping before cutover instead of reverse-engineering it from CLI output under time pressure. And because Safeguard correlates Key Vault grants with the CI/CD identities, build agents, and third-party integrations that actually consume your secrets, it catches the specific pattern that access-policy sprawl produces: a pipeline identity with broad vault-wide access when a single-secret RBAC role assignment would do. If you're weighing Key Vault access policy vs RBAC for an upcoming migration, Safeguard gives you the visibility to make that call with evidence instead of guesswork — and to prove to auditors that the access model you chose is the one actually enforced in production.