Role-Based Access Control should be used on Keyvault Services

What does the recommendation "Role-Based Access Control should be used on Keyvault Services" check?

Flags any standard Key Vault whose data-plane authorisation still uses the legacy vault access policy model rather than Azure RBAC, that is, where 'enableRbacAuthorization' is false or unset on the vault. It looks only at which authorisation system is selected for granting access to keys, secrets and certificates; it does not check who currently holds those grants, whether any individual role assignment is over-privileged, whether secrets are rotated, or how tightly the control plane and firewall are locked down. Managed HSM is a separate resource type with its own local RBAC, so it is out of scope for this recommendation, as are vaults already set to the RBAC model regardless of how broad their assignments are.

Why does "Role-Based Access Control should be used on Keyvault Services" matter?

Under the access policy model, anyone holding 'Microsoft.KeyVault/vaults/write', such as a broad Contributor or Key Vault Contributor, can quietly add themselves to a vault's access policy and read every secret in it, with no separation between managing the vault and reading its data. That is exactly how a routine resource-management role becomes a path to your database passwords and signing keys. Azure RBAC closes the gap: granting data access requires the Owner or User Access Administrator role, permissions can be scoped to a single secret instead of the whole vault, assignments integrate with Privileged Identity Management for time-limited, just-enough access, and every grant shows up in one central view across Azure rather than in a per-vault policy nobody audits. The result is genuine least privilege rather than the all-or-nothing, vault-wide reads the access policy model encourages.

How do I fix "Role-Based Access Control should be used on Keyvault Services"?

1. Confirm your role assignments are in place before flipping the switch: grant 'Key Vault Secrets User' (or the matching keys/certificates role) to each application identity at the vault or individual-secret scope, because enabling RBAC immediately stops access policies being honoured and an unprepared cutover locks workloads out.
2. Set the permission model to RBAC on the vault: 'az keyvault update --name <vault> --enable-rbac-authorization true', which sets the 'enableRbacAuthorization' property on the vault.
3. Enforce it going forward by assigning the built-in policy. Look the definition up by display name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Azure Key Vault should use RBAC permission model'].name" -o tsv); az policy assignment create --name kv-rbac --policy "$pid" --scope <subscription-or-mg-scope>. Set 'enableRbacAuthorization: true' in your Bicep or Terraform vault modules so new vaults ship RBAC-first.

# Find the highest-risk privileged assignments first: external accounts and blocked leavers holding Owner.
SUB="00000000-0000-0000-0000-000000000000"

# List Owners, with type and object id, so external and group principals are obvious.
az role assignment list \
  --scope "/subscriptions/$SUB" \
  --role Owner \
  --query "[].{who:principalName, type:principalType, id:principalId}" -o table

# Remove an external partner's Owner assignment (work finished). Keep at least one Owner you control.
az role assignment delete \
  --assignee "[email protected]" \
  --role Owner \
  --scope "/subscriptions/$SUB"

# Remove a deprecated (blocked) account's role assignment by object id.
# Blocking the Entra sign-in does NOT remove the assignment; delete it explicitly.
az role assignment delete \
  --assignee-object-id "<blocked-user-object-id>" \
  --scope "/subscriptions/$SUB"

# Consolidate the remaining legitimate Owners behind one Entra group, then make it eligible
# (just-in-time) via Privileged Identity Management so nobody holds standing Owner.