Azure Key Vault Access Policies vs RBAC: Which Should You Use?

Two Models, One Key Vault

Azure Key Vault supports two authorization models: the original access policies and the newer Azure role-based access control (RBAC). Both control who can read, write, and manage secrets, keys, and certificates. But they work differently, and picking the wrong one creates headaches that show up months later.

Microsoft now recommends RBAC as the default for new Key Vaults. But “recommended” doesn’t mean “always correct.” Here’s when each model actually makes sense.

Access Policies: The Original Model

Access policies are defined directly on the Key Vault. Each policy grants a specific security principal (user, group, service principal, or managed identity) a set of permissions for secrets, keys, and/or certificates.

# Grant an app read access to secrets
az keyvault set-policy \
  --name my-vault \
  --spn "00000000-0000-0000-0000-000000000000" \
  --secret-permissions get list

How it works: The Key Vault maintains its own list of who can do what. Azure Resource Manager isn’t involved in the authorization decision once the policy is set.

The good parts:

Simple mental model. You look at the Key Vault, you see who has access.
No dependency on Azure AD role assignments propagating. Policy changes take effect immediately.
Works well for small teams with a handful of vaults.

The pain points:

1024 policy limit per vault. Each unique principal counts as one policy. In large environments with many service principals, you hit this ceiling.
No inheritance. Every vault needs its own policies configured individually. Move a secret to a new vault and you need to recreate all the access policies.
No conditional access. You can’t add conditions like “only from this subnet” or “only during business hours” to access policies.
Audit is per-vault. To see who has access to what across your entire estate, you need to query every vault individually.

Azure RBAC: The Modern Model

Azure RBAC for Key Vault uses the same role assignment system as every other Azure resource. You assign built-in roles (or custom roles) at the vault, resource group, or subscription scope.

# Grant an app the Key Vault Secrets User role
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee "00000000-0000-0000-0000-000000000000" \
  --scope "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/my-vault"

Key Vault RBAC built-in roles:

Role	What it can do
Key Vault Administrator	Full management of all vault content
Key Vault Secrets Officer	Full CRUD on secrets (not keys or certs)
Key Vault Secrets User	Read secrets only
Key Vault Certificates Officer	Full CRUD on certificates
Key Vault Crypto Officer	Full CRUD on keys
Key Vault Crypto User	Sign, verify, wrap, unwrap with keys
Key Vault Reader	Read vault metadata (not secret values)

The good parts:

Inheritance. Assign a role at the resource group level and it applies to every vault in that group. Assign at subscription level and it applies everywhere.
Consistent tooling. Same az role assignment commands, same Azure Policy support, same Privileged Identity Management (PIM) integration as every other Azure resource.
No 1024 limit. Role assignments don’t have the same ceiling as access policies.
Conditional access. You can combine RBAC with Conditional Access policies for additional controls.
Single pane of glass. az role assignment list shows you access across all vaults in a scope.

The pain points:

Propagation delay. Role assignments can take up to 10 minutes to propagate. If your deployment pipeline creates a vault and immediately tries to write a secret, it may fail.
More complex for simple scenarios. If you just need one app to read one vault, RBAC adds conceptual overhead compared to a single access policy.
Breaking change during migration. Switching a vault from access policies to RBAC invalidates all existing access policies. If you miss a principal during migration, something breaks.

When to Use Which

Use RBAC when:

You manage more than 5-10 vaults
You need PIM (just-in-time access) for Key Vault access
You want consistent access management across all Azure resources
You’re hitting the 1024 access policy limit
You need subscription-wide or resource-group-wide access grants
You’re setting up a new environment from scratch

Use access policies when:

You have a small, stable environment with few vaults
Your deployment scripts depend on immediate access (no propagation delay tolerance)
You’re running legacy infrastructure that was built around access policies and migration risk outweighs the benefits

Realistically: For most organizations in 2026, RBAC is the right choice. The propagation delay is the only significant downside, and you can work around it with retry logic in deployment pipelines.

Migrating from Access Policies to RBAC

This is a one-way switch per vault. Once you enable RBAC, access policies stop being evaluated.

Step 1: Audit existing access policies

# Export all access policies for a vault
az keyvault show --name my-vault --query "properties.accessPolicies" -o json

For each policy entry, note the objectId and which permissions they have for secrets, keys, and certificates.

Step 2: Map policies to RBAC roles

Access Policy Permission	RBAC Role
secrets: get, list	Key Vault Secrets User
secrets: get, list, set, delete	Key Vault Secrets Officer
keys: all operations	Key Vault Crypto Officer
certificates: all operations	Key Vault Certificates Officer
Everything	Key Vault Administrator

Step 3: Create role assignments BEFORE switching

# Create the RBAC assignments while still in access policy mode
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee "OBJECT_ID_HERE" \
  --scope "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/my-vault"

Wait at least 15 minutes for propagation.

Step 4: Switch the authorization model

az keyvault update \
  --name my-vault \
  --enable-rbac-authorization true

Step 5: Verify

Test every application and pipeline that accesses the vault. Check that no 403 Forbidden errors appear in Key Vault diagnostic logs.

Important: Do this vault-by-vault, starting with a dev vault. Don’t batch-migrate production vaults on a Friday.

Monitoring Access Across Both Models

Regardless of which model you use, you need visibility into who accesses what. Key Vault diagnostic logs capture all data plane operations, but correlating access patterns across 50+ vaults and multiple subscriptions is where manual approaches break down.

CertifyClouds scans all your Key Vaults across every connected subscription and gives you a single compliance dashboard showing secret access patterns, expiry status, and rotation compliance. Whether you use access policies, RBAC, or a mix of both, the discovery and monitoring layer works the same way.