Transition Azure Key Vault access policies to Azure RBAC

Question

|Please share the step-by-step guidelines to complete this transition| | -------- | Transition to Azure RBAC

You’re receiving this email because you’re using Azure Key Vault. On 27 February 2027, all Azure Key Vault API versions prior to 2026-02-01 will be retired. Azure Key Vault API version 2026-02-01—releasing in February 2026—introduces an important security update: Azure role-based access control (RBAC) will be the default access control model for all newly created vaults. Existing key vaults will continue using their current access control model. Azure portal behavior will remain unchanged. If you’re using legacy access policies for new and existing vaults, we recommend migrating to Azure RBAC before transitioning to API version 2026-02-01. To learn why Azure RBAC is critical to security, read our blog. If you want to continue using legacy access policies for new key vault creation after transitioning to API version 2026-02-01, you'll need to explicitly configure access policies as the access control model in your CLI, PowerShell, Rest API, ARM, Bicep, and Terraform templates. If you don’t take this action, all newly created vaults will be created with Azure RBAC as the default access control model, which can result in HTTP 403 errors and failures in your code and operations due to missing roles.

Required action

Migrate new and existing vaults to Azure RBAC before transitioning to API version 2026-02-01 or explicitly configure new vaults to use legacy access policies. You’ll need to transition to API version 2026-02-01 before 27 February 2027, when all prior APIs will be retired. For additional guidance on securing your Azure Key Vault deployments, refer to our documentation.

Help and support

If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and you need technical help, create a support request.

Transition to Azure RBAC

You’re receiving this email because you’re using Azure Key Vault. On 27 February 2027, all Azure Key Vault API versions prior to 2026-02-01 will be retired. Azure Key Vault API version 2026-02-01—releasing in February 2026—introduces an important security update: Azure role-based access control (RBAC) will be the default access control model for all newly created vaults. Existing key vaults will continue using their current access control model. Azure portal behavior will remain unchanged. If you’re using legacy access policies for new and existing vaults, we recommend migrating to Azure RBAC before transitioning to API version 2026-02-01. To learn why Azure RBAC is critical to security, read our blog. If you want to continue using legacy access policies for new key vault creation after transitioning to API version 2026-02-01, you'll need to explicitly configure access policies as the access control model in your CLI, PowerShell, Rest API, ARM, Bicep, and Terraform templates. If you don’t take this action, all newly created vaults will be created with Azure RBAC as the default access control model, which can result in HTTP 403 errors and failures in your code and operations due to missing roles.

Required action

Migrate new and existing vaults to Azure RBAC before transitioning to API version 2026-02-01 or explicitly configure new vaults to use legacy access policies. You’ll need to transition to API version 2026-02-01 before 27 February 2027, when all prior APIs will be retired. For additional guidance on securing your Azure Key Vault deployments, refer to our documentation.

Help and support

If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and you need technical help, create a support request.

Answer 1

Hello Shivaji Kaleru

Please refer this Microsoft Document for migrating Azure Key Vault access policies to Azure RBAC https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-migration?tabs=cliBefore starting the migration, ensure you have:

Required permissions: You must have the following permissions on the key vault:

• Microsoft.Authorization/roleAssignments/write permission, included in Owner and User Access Administrator roles
  • Microsoft.KeyVault/vaults/write permission, included in the Key Vault Contributor role
  Inventory of applications and identities: List all applications, services, and users that access the key vault, and document all current access policies and the permissions they grant.

Inventory current access policies

Document all existing access policies, noting the security principals (users, groups, service principals) and their permissions.

In the Azure portal:

1. Navigate to your key vault
2. Select Access policies under Settings
3. Document all existing access policies, noting:
   • Identity (user, group, or service principal)
     • Key, Secret, and Certificate permissions granted

Create equivalent Azure RBAC role assignments

For each security principal with an access policy, create one or more Azure RBAC role assignments based on the mapping table above.

In the Azure portal:

1. Navigate to your key vault
2. Select Access control (IAM)
3. Click Add > Add role assignment
4. Select the appropriate role based on the access policy mapping
5. Search for and select the user, group, or service principal
6. Click Review + assign to create the role assignment
7. Repeat for each identity that needs access

Enable Azure RBAC

After creating all necessary role assignments, switch the vault to use the Azure RBAC permission model.

In the Azure portal:

1. Navigate to your key vault
2. Select Properties under Settings
3. Change Permission model to Azure role-based access control
4. Click Save

Validate access

Test access to the vault to ensure all applications and users can still perform required operations.

In the Azure portal:

1. Try to access secrets, keys, or certificates based on your assigned roles
2. Verify that applications using the vault still function correctly

After migration, set up proper monitoring to detect any access issues.Before starting the migration, ensure you have:

Required permissions: You must have the following permissions on the key vault:

• Microsoft.Authorization/roleAssignments/write permission, included in Owner and User Access Administrator roles
  • Microsoft.KeyVault/vaults/write permission, included in the Key Vault Contributor role
  Inventory of applications and identities: List all applications, services, and users that access the key vault, and document all current access policies and the permissions they grant.

Inventory current access policies

Document all existing access policies, noting the security principals (users, groups, service principals) and their permissions.

In the Azure portal:

1. Navigate to your key vault
2. Select Access policies under Settings
3. Document all existing access policies, noting:
   • Identity (user, group, or service principal)
     • Key, Secret, and Certificate permissions granted

Create equivalent Azure RBAC role assignments

For each security principal with an access policy, create one or more Azure RBAC role assignments based on the mapping table above.

In the Azure portal:

1. Navigate to your key vault
2. Select Access control (IAM)
3. Click Add > Add role assignment
4. Select the appropriate role based on the access policy mapping
5. Search for and select the user, group, or service principal
6. Click Review + assign to create the role assignment
7. Repeat for each identity that needs access

Enable Azure RBAC

After creating all necessary role assignments, switch the vault to use the Azure RBAC permission model.

In the Azure portal:

1. Navigate to your key vault
2. Select Properties under Settings
3. Change Permission model to Azure role-based access control
4. Click Save

Validate access

Test access to the vault to ensure all applications and users can still perform required operations.

In the Azure portal:

1. Try to access secrets, keys, or certificates based on your assigned roles
2. Verify that applications using the vault still function correctly

After migration, set up proper monitoring to detect any access issues.