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 recommends RBAC, and starting with Key Vault API version 2026-02-01 RBAC is the default access model for newly created vaults. Scripts and templates that create vaults and then add access policies will need updating. This post covers when each model makes sense and how to move an existing vault across.

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 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.
  • Contributors can grant themselves access. Anyone with Contributor, Key Vault Contributor or any role that can write to the vault can add an access policy for themselves and read every secret. Microsoft’s own guidance calls this out as the main risk of the model.
  • All or nothing per vault. A policy grants access to every secret in the vault. You can’t limit it to a single secret.
  • 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 Certificate User Read full certificate contents, including the private key
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.
  • Only Owner or User Access Administrator can grant data access. Contributors on the vault can’t give themselves secrets, which closes the gap described above.
  • Finer scope. You can assign a role on a single secret when one application needs to share one value with another. Key Vault also supports ABAC conditions in preview, for example limiting a principal to secrets whose names match a pattern.
  • One place to review access. az role assignment list shows access across all vaults in a scope.

The pain points:

  • Propagation delay. Microsoft says role assignments “can take several 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 to RBAC stops all existing access policies from being evaluated. 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 organisations 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

Once you enable RBAC on a vault, its access policies stop being evaluated, so every role assignment has to exist before you switch.

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"

Give the assignments a few minutes to propagate, then test access before you switch.

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. Its compliance dashboard shows which vaults still use access policies, which are missing soft-delete, purge protection or network restrictions, and what is expiring. Discovery works the same whichever access model a vault uses.

Further Reading