Edit

Plan for Azure RBAC as the default access control model in Key Vault

Azure Key Vault API version 2026-02-01 and later changes the default access control model for new vaults to Azure RBAC, consistent with the Azure portal experience. Both Azure RBAC and access policies remain fully supported. API version 2026-02-01 is available in public Azure regions, Azure operated by 21Vianet, and Azure Government.

This article focuses on access-control behavior for new and existing key vaults. For guidance on the control plane API retirement and how to update applications, scripts, templates, SDKs, Azure CLI, and Azure PowerShell, see Update the Azure Key Vault API version you use.

  • New key vault creation behavior: When you create a new vault with API version 2026-02-01 or later, the default access control model is Azure RBAC (enableRbacAuthorization = true). This default applies only to create operations. To use access policies for new vaults, set enableRbacAuthorization to false at creation time.
  • Existing key vault behavior: Existing vaults keep their current access control model unless you explicitly change enableRbacAuthorization. Using API version 2026-02-01 or later to update a vault doesn't automatically change access control. Vaults where enableRbacAuthorization is null (from older API versions) continue using access policies.

Important

All Key Vault control plane API versions before 2026-02-01 retire on February 27, 2027. This retirement is separate from access-control migration. For the API-version update checklist, see Update the Azure Key Vault API version you use.

Important

Upgrade to Azure CLI 2.90.0 or later or Azure PowerShell 16.3.0 or later, which support API version 2026-02-01 and later. Use of API versions earlier than 2026-02-01 will be suspended after February 27, 2027.

We encourage you to migrate key vaults that currently use access policies to Azure RBAC for improved security. For more information on why Azure RBAC is recommended, see Azure role-based access control (Azure RBAC) vs. access policies. For step-by-step migration guidance, see Migrate to Azure RBAC from access policies.

What you need to do

If you already know your vault's access control model, skip to Determine your next steps. Otherwise, check your current configuration first.

Use this article to decide how access control should be configured:

  • If you create new vaults with API version 2026-02-01 or later, decide whether to accept the Azure RBAC default or explicitly set access policies.
  • If you update existing vaults with API version 2026-02-01 or later, understand that the API version update doesn't automatically change access control.
  • If you want to migrate existing vaults from access policies to Azure RBAC, use the dedicated migration guide.

Important

To change the enableRbacAuthorization property for a key vault, you must have the Microsoft.KeyVault/vaults/write permission (included in roles such as Contributor and Owner). The Azure portal additionally requires Microsoft.Authorization/roleAssignments/write (included in roles such as Owner and User Access Administrator) to ensure you can assign Key Vault RBAC roles after the change and avoid lockout. For more information, see Enable Azure RBAC permissions on Key Vault.

Check your current configuration

Check if your vault's access configuration is set to Azure RBAC or access policies. Check this configuration through the Azure CLI or PowerShell commands.

After checking your configuration:

Check a single vault

  1. Use the az keyvault show command to retrieve vault details:

    az keyvault show --name <vault-name> --resource-group <resource-group>
    
  2. Check the Enabled for RBAC Authorization property (enableRbacAuthorization) for the key vault.

Check multiple vaults by resource group

Use the az keyvault list command to list all vaults in a resource group and check their RBAC authorization status:

# List all key vaults in the resource group and check Azure RBAC status
az keyvault list --resource-group <resource-group> --query "[].{name:name, rbacEnabled:properties.enableRbacAuthorization}" --output table

Check multiple vaults across your subscription

Use the az keyvault list command to list all vaults in your subscription and check their RBAC authorization status:

# List all key vaults in the subscription and check Azure RBAC status
az keyvault list --query "[].{name:name, rbacEnabled:properties.enableRbacAuthorization}" --output table

Determine your next steps

Based on your current access control model, follow the appropriate guidance below.

Keep API-version updates separate from access-control migration

If your applications, scripts, templates, or SDKs use a control plane API version before 2026-02-01, update them regardless of whether your key vaults use Azure RBAC or access policies. This API-version update is separate from migrating from access policies to Azure RBAC. For guidance on identifying and updating the API versions used by your applications, scripts, templates, and SDKs, see Update the Azure Key Vault API version you use.

Vaults that use Azure RBAC

If your key vaults already use Azure RBAC, you don't need to change access control. New key vaults created with API version 2026-02-01 or later also use Azure RBAC by default unless you explicitly set enableRbacAuthorization to false.

Vaults that use access policies

If your key vaults use access policies (legacy) (enableRbacAuthorization = false or null), decide if you want to migrate to role-based access (recommended) or continue using access policies. For more information on access control models, see Use Azure RBAC for managing access to Key Vault and Azure Key Vault best practices.

Choose your path:

Use this opportunity to increase your security posture by migrating from vault access policies to Azure RBAC. For the migration procedure, see Migrate to Azure RBAC from access policies.

Continue using access policies

Access policies remain a fully supported access control model.

  • Existing vaults: Vaults already using access policies continue to use access policies unless you explicitly change enableRbacAuthorization.
  • New vaults: When you create new vaults with API version 2026-02-01 or later, you must explicitly set enableRbacAuthorization to false to use access policies, as described in the following sections.

Choose one of the following methods based on your scenario:

Using ARM, Bicep, Terraform templates

When creating new key vaults by using API version 2026-02-01 or later, set enableRbacAuthorization to false in all Key Vault ARM, Bicep, Terraform templates, and REST API calls to use access policies (legacy).

Using Create Key Vault commands

When creating new key vaults by using API version 2026-02-01 or later, you must specify access policies configuration to avoid defaulting to Azure RBAC.

Update the Azure CLI or PowerShell modules to the latest version.

Update Azure CLI to the latest version. For more information, see How to update the Azure CLI.

Use the appropriate command to create a key vault with access policies:

Use the az keyvault create command and set --enable-rbac-authorization false:

az keyvault create --name "testCreateTutorial" --resource-group "testResourceGroup" --enable-rbac-authorization false
Using Create Resource commands

When you create new key vaults by using API version 2026-02-01 or later, set enableRbacAuthorization to false to use access policies (legacy). If you don't specify this property, it defaults to true (Azure RBAC).

Use the az resource create command and set "enableRbacAuthorization": false and --api-version "2026-02-01":

az resource create --resource-group $resourceGroup --name $vaultName --resource-type "Microsoft.KeyVault/vaults" --location $location --api-version "2026-02-01" --properties "{\"sku\": { \"family\": \"A\", \"name\": \"standard\" }, \"tenantId\": \"$tenantID\",\"enableRbacAuthorization\": false, \"accessPolicies\": []}"

Next steps