Azure Key Vault supports two authorization models for data-plane access: Azure role-based access control and the older Key Vault access policy model. Both can still work, but they create very different governance boundaries. Microsoft now recommends Azure RBAC because permission management is integrated with Azure Resource Manager, role assignments are auditable at familiar scopes, and the model separates ordinary resource contribution from the authority to grant access to keys, secrets, and certificates.
The security difference is important. Under the legacy access policy model, a principal with sufficient write permissions on the vault resource can potentially modify access policies and grant itself data-plane permissions. Microsoft specifically warns about this risk and recommends restricting Contributor-style access when access policies are used. With Azure RBAC, permission administration is controlled through role assignments and the roles that are allowed to create them.
This topic sits directly inside the current Microsoft SC-500 objective for securing secrets and keys with Azure Key Vault. The useful skill is not memorizing which checkbox selects RBAC. It is understanding how the two models affect privilege boundaries, migration, scope, operations, and incident analysis.
Azure RBAC moves authorization into the Azure control model
With Azure RBAC, access is granted through role assignments made to users, groups, service principals, or managed identities. A role assignment combines a principal, a role definition, and a scope. That scope can be the vault and, for supported scenarios, can be narrowed further to individual objects. The model is consistent with the rest of Azure and works naturally with centralized identity and access reviews.
This is why the mental model from Azure RBAC scope and inheritance applies so well to Key Vault. The authorization decision is not merely “does this identity have secret access?” It is where the assignment came from, how broad its scope is, whether it is inherited, and who had the authority to create it.
Access policies are a vault-native legacy authorization system
Access policies define permissions directly on the vault for keys, secrets, and certificates. They are straightforward to understand in small environments and remain supported, which means existing deployments do not need to be broken simply because a newer model exists. The concern is governance: the ability to edit the vault can overlap too closely with the ability to grant data access.
That overlap can weaken separation of duties. A deployment operator who only needs to manage tags, diagnostics, or networking may receive a broad resource-management role and then gain the ability to alter access policies. In a high-value vault, that is a larger privilege than many organizations intend. The authorization model should therefore be chosen as part of the vault’s trust boundary, not as a compatibility preference.
Microsoft now makes RBAC the stronger default for new designs
Microsoft’s current Key Vault guidance recommends Azure RBAC for data-plane authorization. A significant recent change reinforces that direction: Key Vault API version 2026-02-01 and later defaults newly created vaults to RBAC authorization unless the deployment explicitly selects the legacy access policy model. Existing vaults that already use access policies continue to work unless the setting is changed.
That means infrastructure-as-code templates and automation deserve review. An older template that relied on the historical default can create a different authorization model after an API-version update if it does not set the property deliberately. Security-sensitive configuration should always be explicit. The same principle is discussed in the distinction between governance policy and RBAC: defaults are convenient, but durable security comes from intentional configuration.
Role selection matters as much as model selection
Choosing RBAC does not automatically produce least privilege. Azure provides built-in Key Vault data roles with different capabilities for secrets, keys, certificates, and broader administration. Assigning an overly powerful role at subscription or resource-group scope can recreate the same privilege problem in a different form.
Use managed identities for workloads where possible and give each identity only the data operations it needs. A deployment pipeline that writes a secret may not need to read every existing secret. An application that retrieves one secret should not automatically receive key-management permissions. The practical guidance in Azure Key Vault secret design is relevant because the vault should reduce credential sprawl, not become a place where broad identities can access everything.
Migration requires an authorization inventory before the switch
Moving a production vault from access policies to RBAC is not a cosmetic change. Existing access policies stop being the authorization source once RBAC is enabled, so every application, operator, automation account, and managed identity that depends on the vault needs an equivalent role assignment before the cutover. Missing one identity can create an immediate production outage.
Start by inventorying current access policies and observed callers. Classify each permission set into a target RBAC role and scope. Create and validate the assignments, test representative operations, and then switch the vault model during a controlled change window. Monitoring should be ready to distinguish authorization failures from network or application errors. A rollback plan is still useful even when the long-term direction is clear.
Separate control-plane administration from data-plane access
One of the best reasons to use RBAC is that it encourages a cleaner separation between people who administer Azure resources and people or workloads that consume secret material. A platform engineer may need to create vaults, configure private endpoints, and enable diagnostics without needing to read secrets. A security administrator may need authority to manage role assignments without being a routine consumer of the stored material.
This separation fits the broader identity architecture described in Microsoft Entra identity and access management. Privilege should be granted to roles and managed identities that match operational responsibilities, with high-impact permission changes visible in audit logs and, where appropriate, subject to privileged-access workflows.
Network controls and authorization solve different Key Vault risks
A Key Vault can use firewalls, private endpoints, and public-network restrictions in addition to data-plane authorization. Those controls should be layered, not confused. Private connectivity can reduce who can reach the vault endpoint, while RBAC or access policies determine what an authenticated caller is allowed to do after reaching it.
An overly broad role is still overly broad on a private network, and a perfectly scoped role does not by itself prevent unnecessary public exposure. High-value vaults usually need both network restriction and strong identity authorization. Architecture reviews should ask separately: who can route to the vault, who can authenticate, who can read or change each object type, and who can grant those permissions.
Audit the people who can grant access, not only the people who have access
Access reviews often focus on secret readers and miss the principals that can assign Key Vault roles. Those grant authorities are more powerful because they can change who has data access later. Review Owner, User Access Administrator, custom roles with role-assignment permissions, and any privileged automation that can modify authorization.
The same review should look for assignments at unexpectedly broad scopes. A Key Vault role inherited from a resource group may have been convenient when the environment was small but can become excessive as more vaults are added. The point is to evaluate effective access, not only assignments visible on one resource page.
Choose a model for the operating future, not the migration past
Access policies can remain appropriate for legacy systems that cannot be migrated immediately, but new designs should have a strong reason to choose them over RBAC. “That is how the old vault was configured” is not a security requirement. Microsoft’s direction, current API behavior, and the separation-of-duties advantages all favor RBAC for most new Key Vault deployments.
Across Microsoft cloud environments, the durable design is to make access explicit, least-privileged, and reviewable. RBAC provides a stronger foundation for that model, but only when role scopes and grant authority are disciplined. The authorization system is a tool; the security outcome still depends on whether the organization can explain who can access the vault, why that access exists, and who can change it.
Break-glass access should be explicit as well. A production vault may need an emergency path for a small number of privileged operators, but that does not justify permanent broad read access. Use tightly controlled identities, strong authentication, alerting on activation or role assignment, and documented post-incident review. The emergency mechanism should be tested so the team knows it works without making it part of normal administration.
Automation can also create accidental privilege expansion. Infrastructure pipelines that assign Key Vault roles often run with broad subscription permissions, so a template error can grant access at a wider scope than intended. Validate the target scope before deployment and treat role-assignment changes as security-sensitive outputs in code review. The authorization model may be RBAC, but the most important question remains whether the principal receives exactly the permissions required for exactly the resources intended.
For shared platform vaults, consider whether one vault is creating unnecessary authorization coupling. Azure RBAC can scope access cleanly, but dozens of unrelated applications in one vault still increase the impact of an administrative mistake. Separate vaults by environment, application boundary, or sensitivity when that separation reduces shared privilege and simplifies ownership. Authorization design is easier to review when the resource boundary already reflects the trust boundary.
