As part of the Key Vault API change coming, MSFT are advising customers to migrate from Access Polices to RBAC to control data plane access to Key Vaults.

Assessment & Mapping (Preparation)

Before making any changes, assess the following conditions for your Key Vault:

1. Data Plane Access: Determine whether you have access to the Key Vault’s data plane so you can check if the vault contains any secrets, keys, or certificates (i.e., is it empty or in use).
2. Current Permission Model: Identify whether the Key Vault is currently using Access Policies or Azure RBAC.
3. Access Policy Inventory: If the vault uses Access Policies, document which identities (users, groups, Managed Identities, SPNs) have assignments and what permissions they hold.

Role Mapping

Once the inventory is complete, map each identity to the equivalent Azure RBAC role:

• Applications (Read-Only): Assign the Key Vault Secrets User role.
• Portal Users (Read-Only): Assign the Key Vault Certificates User for Certificates only, or add Key Vault Secrets User to include secrets.
• Portal Users (Read/Write): Assign the Key Vault Certificates Officer and Key Vault Secrets User roles.
• AppGw Integration Managed ID: Assign Key Vault Secrets User role.
• Administrators/CI/CD: Assign the Key Vault Administrator role.

Role Staging (Non-Disruptive)

Assign the required roles via the Access Control (IAM) tab of the Key Vault.

Note: Access Policies will remain active and continue to handle traffic during this period.

The Cutover (The Toggle)

Once roles are assigned, navigate to Access Configuration in the Key Vault menu and switch the permission model to “Azure role-based access control.” Azure will immediately begin enforcing the RBAC roles staged in the previous step.

Validation & Code Updates

• Verify your applications (e.g., Application Gateways) are successfully retrieving secrets.
• Update your Infrastructure-as-Code (IaC) templates to set enableRbacAuthorization: true and remove legacy accessPolicies blocks.