First separate control-plane and data-plane access
Key Vault uses Microsoft Entra ID to authenticate callers, but authorization depends on the requested plane. The control plane manages the vault resource through Azure Resource Manager. The data plane works with secrets, keys and certificates through the vault endpoint.
| Plane | Examples | Authorization |
|---|---|---|
| Control plane | Create or delete a vault, read properties, configure networking and tags | Azure RBAC management actions |
| Data plane | Get or set a secret, encrypt with a key, create or retrieve a certificate | Azure RBAC data actions or legacy access policy |
Critical AZ-104 distinction
Key Vault Contributor can manage the vault’s control plane but cannot read secret values. Data access requires a suitable Key Vault data-plane role or, on a legacy-model vault, an access policy.
Azure RBAC vs legacy Key Vault access policies
| Decision | Azure RBAC model | Access policy model |
|---|---|---|
| Current direction | Recommended and centrally managed | Legacy model |
| Assignment | Azure role assignment to a user, group, service principal or managed identity | Vault access policy lists object permissions for a principal |
| Scope | Management group, subscription, resource group, vault and selected object scopes | Specific vault |
| Governance | Works with Azure RBAC tooling, privileged access and centralized auditing | Vault owners with sufficient control-plane rights can modify policies |
| Permission-model change | Invalidates legacy policy permissions | Invalidates data-plane RBAC permissions if changed back |
Starting with Key Vault API version 2026-02-01, Azure RBAC is the default model for newly created vaults. Existing vaults must still be inspected; do not infer their model from the age of the application or from a role assignment alone.
Choose the narrowest suitable Key Vault data role
Built-in roles differ by object type and action. Assign them at the vault scope in most application designs and avoid broad subscription-level data access unless the operating model requires it.
- Key Vault Secrets User: read secret contents for an application that consumes secrets.
- Key Vault Secrets Officer: manage secrets but not permissions, keys or certificates.
- Key Vault Crypto User: perform specified cryptographic operations using keys.
- Key Vault Certificates Officer: manage certificates except permissions.
- Key Vault Reader: read metadata but not secret values or key material.
- Key Vault Administrator: all data-plane operations; reserve for justified administration.
- Key Vault Data Access Administrator: assign or remove constrained Key Vault data roles; it does not equal unrestricted data access.
Role names and capabilities should be confirmed in current Microsoft documentation before automation. For stable infrastructure code, Microsoft recommends using unique role definition IDs rather than display names.
Managed identity removes credentials, not authorization
A system-assigned or user-assigned managed identity can request a Microsoft Entra token without storing an application secret. You must still grant that identity the correct Key Vault data permission at the correct scope.
- Enable or attach the intended managed identity to the Azure workload.
- Capture the identity’s principal object ID; do not confuse it with a client ID or resource ID.
- Confirm the vault permission model.
- Assign the minimum data role for RBAC, or the minimum object permissions for a legacy access policy.
- Permit the workload’s network path to the vault endpoint.
- Use the Key Vault SDK with a supported token credential and retry transient propagation failures.
A role assignment to the wrong managed identity is a common cause of 403 errors, especially when an application has both system-assigned and user-assigned identities.
Migrate from access policies without causing an outage
Changing a vault to the Azure RBAC permission model invalidates all access-policy permissions. Treat the change as an authorization migration, not a portal toggle.
Use a maintenance window and rollback plan for critical workloads. After switching, confirm applications, backup, rotation, deployment pipelines and operational access. Microsoft notes that recovered soft-deleted vaults do not preserve role assignments, so recovery procedures must recreate them.
Worked scenario: App Service receives 403 reading a secret
Situation: An App Service uses a user-assigned managed identity. The operator assigned Key Vault Contributor at the vault, but the application receives HTTP 403 when calling GetSecret.
The role controls the vault, not its secret values
Key Vault Contributor provides management-plane actions. It does not include the data action to read secret content.
Grant the actual identity a data-plane role
Confirm the app selects the intended user-assigned identity, assign Key Vault Secrets User at the vault scope, wait for propagation, and verify the network path and private DNS if public access is restricted.
Authentication, authorization and networking are independent gates. A valid managed-identity token and a control-plane role do not prove that secret access or vault connectivity is allowed.
HTTP 403 troubleshooting: do not broaden permissions first
- Capture the caller: identify the tenant, principal object ID and selected managed identity from logs or token claims.
- Confirm the operation: distinguish management operations from
get,list,set, unwrap, sign or certificate operations. - Confirm the model: inspect whether the vault uses Azure RBAC or legacy access policies.
- Evaluate assignment: verify the right role or policy, principal and scope; remember inherited assignments.
- Allow propagation: recent role changes can take several minutes; use bounded retry rather than permanent over-privilege.
- Check networking: inspect firewall rules, trusted-service assumptions, private endpoints, virtual network links and DNS resolution.
- Check resource state: verify vault name, tenant, subscription, secret version, enabled dates and deletion state.
- Use diagnostics: enable Key Vault logging and correlate the 403 reason, caller and network evidence.
A 403 may mean the request authenticated but lacks permission, or that the network source is not approved. A private-endpoint 403 can be a DNS-path problem disguised as authorization failure.
AZ-104 practice checks with explanations
An administrator can configure a vault but cannot read a secret value. They have Key Vault Contributor. Is this expected?
Yes. The role grants control-plane management, not secret data-plane access.
A VM must read secrets without storing a client secret. What two separate steps are required?
Enable a managed identity and grant the identity the minimum Key Vault data permission. Identity solves authentication; the role or access policy solves authorization.
What must happen before switching a legacy vault to Azure RBAC?
Map and assign equivalent data-plane roles and validate workloads. Existing access-policy permissions are invalidated when the model changes.
Common AZ-104 mistakes
- Assuming Reader or Key Vault Contributor can read secret values.
- Assigning a role to a client ID instead of the intended principal object.
- Ignoring whether the vault uses RBAC or access policies.
- Switching authorization models before creating replacement access.
- Granting Key Vault Administrator when Secrets User is sufficient.
- Troubleshooting only permissions while firewall or private DNS blocks the path.
- Assuming a managed identity receives automatic target access.
- Forgetting role-assignment propagation and recovery procedures.
Frequently asked questions
What is the recommended Azure Key Vault authorization model?
Microsoft recommends Azure role-based access control for Key Vault. It centralizes role assignments and supports scopes from management group or subscription down to a vault and, for exceptional cases, individual objects.
Does Key Vault Contributor let a user read secret values?
No. Key Vault Contributor manages the vault resource on the control plane but does not grant access to secret values, keys or certificates on the data plane.
What happens when a vault changes from access policies to Azure RBAC?
Existing access-policy permissions become invalid. Assign equivalent Key Vault data-plane roles before changing the permission model and validate critical workloads to avoid an outage.
Why does a managed identity receive 403 from Key Vault?
The identity may lack the correct data-plane role or access policy, use a different principal than expected, be outside the assignment scope, encounter propagation delay, or be blocked by Key Vault firewall, private endpoint or DNS configuration.
Should every application share one Key Vault?
Microsoft recommends a vault per application per environment with role assignments at the vault scope in most cases. Individual-object role assignments are exceptions rather than the default design.
Official Microsoft references
Review Microsoft Learn for the Key Vault RBAC guide, access-policy migration, access troubleshooting, Key Vault authentication, and the current AZ-104 study guide.