Should Azure Key Vault use Azure RBAC or access policies?

How Azure RBAC changes the authorisation boundary for Key Vault

Azure RBAC moves Key Vault access into Azure’s central role and scope model, which is usually the cleaner option when you want one authorisation pattern across subscriptions and resource groups. It is a better fit when access should be reviewed alongside the rest of Azure, because the decision point is no longer embedded only inside each vault.

That centralisation matters operationally: it is easier to reason about who can read, write, or administer vault resources when permissions follow the same governance path as other Azure assets. It also reduces the chance that separate teams create overlapping vault-specific rules that drift over time.

For teams building a broader Azure access model, the same role-design discipline that applies to subscriptions and application identities applies here too. The practical question is whether the vault should follow an enterprise authorisation standard or remain an exception with local rules. The Azure RBAC and Service Principals Guide is useful when you want to align Key Vault access with role assignments, scopes, and least-privilege administration.

When access policies are still the right choice

Access policies are vault-specific, so they can be useful when you need a narrow, explicit permission set tied to one vault and do not want to grant broader Azure role permissions. That can be sensible for a small boundary, a legacy implementation, or a team that wants the vault to remain independently administered.

The trade-off is governance consistency. A vault-by-vault policy model can be harder to standardise, especially where multiple teams manage different vaults or where permissions are handed out informally. The more vaults you have, the more likely policy sprawl, stale grants, and inconsistent review practices become.

If your organisation is still deciding how to model the surrounding identity lifecycle, use a common access-governance lens rather than treating the vault as a special case. A practical starting point is the IAM and IGA Basics guide, which helps frame the difference between local permissions and governed entitlement management. That same pattern also appears in the Role Mining and Role Design Guide, especially where role sprawl or unclear ownership makes vault permissions hard to sustain.

How to decide without creating inconsistent access models

The safest decision rule is to choose one primary control plane for governance and use the other only when there is a documented exception. Mixing Azure RBAC and access policies is where teams most often create ambiguity, because nobody is sure which model is authoritative for review, removal, or escalation.

If you are standardising across Azure, prefer RBAC for predictable administration, access review, and separation of duties. If you are preserving a vault-local model, make sure the policy owner, review cadence, and emergency override path are explicit, because the risk is not only overpermission, but also inconsistent recovery when access needs to be changed quickly.

That discipline becomes more important as the number of managed secrets grows. Even when the vault is correctly configured, the surrounding lifecycle matters: who can create secrets, who can read them, how long access lasts, and how quickly stale permissions are removed. The Lifecycle Processes for Managing NHIs section is relevant here because vault access is often part of a wider provisioning, rotation, and offboarding problem rather than a one-time setup choice.

Risk and Threat Considerations

Key Vault permission mistakes often become exposure events, not just administrative issues. Overbroad admin rights, mixed authorisation models, or forgotten vault-local policies can allow a user or workload to reach secrets, keys, or certificates that were never meant to be broadly available.

Failure mechanism: A broad role assignment, stale access policy, or delegated admin path can let an identity expand from managing a vault to reading protected material inside it, especially when review processes do not distinguish between control-plane access and data-plane access.

Impact: Once secrets or keys are exposed, the blast radius can extend beyond the vault itself into application compromise, lateral access, service impersonation, or downstream data exposure. The risk increases when permissions are difficult to audit or when teams assume the other model is still enforcing the restriction.

Practitioner Guidance

What to prioritise: Pick one governing model for each vault estate and make it visible in your standards. If Azure RBAC is the default, treat access policies as an exception that must be justified, reviewed, and documented, not as a parallel convenience layer.

What to verify: Confirm who can administer the vault, who can manage its contents, and who can review the effective permissions. In practice, the strongest control is the one your teams can actually recertify without interpreting two different permission systems at the same time.

Common mistake: Teams often optimise for immediate setup speed and then inherit long-term complexity. The most expensive outcome is usually not the initial choice of RBAC or access policy, but the inability to explain, review, and revoke access consistently six months later.

Practitioner takeaway: Choose the model that gives you the cleanest governance story, then enforce it consistently. For Key Vault, consistency is usually more important than theoretical flexibility.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• How should security teams govern Azure Key Vault access for applications?
• How should security teams configure Azure Key Vault to reduce exposure from public access settings?
• When does Azure Key Vault access become too broad for least privilege?