Microsoft AzureOverview
The recommended way to access Key Vaults is to use the Azure Role-Based Access Control (RBAC) permissions model.
Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources. It allows users to manage Key, Secret, and Certificate permissions. It provides one place to manage all permissions across all key vaults.
Rationale
The new RBAC permissions model for Key Vaults enables a much finer-grained access control for key vault secrets, keys, certificates, etc., than the vault access policy. This, in turn, will permit the use of privileged identity management over these roles, thus securing the key vaults with JIT Access management.
Important note
For new Key Vaults created with API version 2026-02-01 or later, Azure RBAC is now the default access model. Existing vaults keep their current model until you explicitly switch them.
Impact
Implementation needs to be properly designed from the ground up, as this is a fundamental change to how key vaults are accessed/managed. Changing permissions to key vaults will result in a loss of service as permissions are re-applied. For the least downtime, map your current groups and users to their corresponding permission needs.
Remediation guidance
Azure Remediation
Service-wide fix (recommended): standardize Azure RBAC for vault data-plane access and treat legacy access policies as technical debt that should be migrated deliberately.
Azure portal
- Open the Key Vault.
- Go to
PropertiesorAccess configurationdepending on the portal view. - Change the permission model to
Azure role-based access control. - Save the change.
- Go to
Access control (IAM)and assign the required built-in Key Vault data-plane roles before cutting applications over.
Azure CLI
Enable RBAC authorization on the vault:
az keyvault update --resource-group <resource-group> --name <vault-name> --enable-rbac-authorization true
Validate the setting:
az keyvault show --resource-group <resource-group> --name <vault-name> --query properties.enableRbacAuthorization
Operational notes
- Do not switch the permission model before you recreate the required access as Azure RBAC role assignments. The access policy model is ignored once RBAC authorization is enabled.
- The safest migration pattern is: map current permissions, create equivalent RBAC assignments, test access, then switch the vault.
- Microsoft now defaults new vaults to RBAC in current API versions, so platform standards should assume RBAC-first going forward.
References
- https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-migration
- https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide
- https://learn.microsoft.com/en-us/cli/azure/keyvault
Query logic
These are the stored checks tied to this control.
Azure key vaults not using RBAC
Connectors
Covered asset types
Expected check: eq []
{
kmsVaults(where: { enableRbacAuthorization: false }) {
...AssetFragment
}
}
