Does migrating an Azure Key Vault from access policies to RBAC, require changes in the client app?

Migrating the vault to Azure RBAC normally requires no C# client changes, provided the application continues authenticating with the same Microsoft Entra identity and that identity receives an equivalent RBAC role before the permission model is switched.

What changes—and what does not

Your Minimal API can continue using the same vault URI, SecretClient, and credential mechanism. The .NET Key Vault client supports authorization through either RBAC or legacy access policies; authentication remains based on the application’s identity.^1^

For example, this code does not need to change:

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var vaultUri = new Uri(builder.Configuration["KeyVaultUri"]!);
var client = new SecretClient(vaultUri, new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("DatabaseConnection");
string value = secret.Value;

What changes is the authorization configuration in Azure:

• Before: the application identity has a Key Vault access policy.
• After: that same identity has an Azure role assignment at the vault or secret scope.
• Switching permission models does not automatically translate existing access policies into role assignments; create the assignments before cutover.^2^

Recommended read-only role

If the stored values are secrets, assign the application identity Key Vault Secrets User. This role permits reading secret values and metadata but provides no secret set or delete data actions.^3^

Do not assign:

• Key Vault Secrets Officer, which is intended for secret management.
• Key Vault Administrator, which grants broad data-plane access.
• Key Vault Reader by itself, because reading metadata is different from reading secret values.

If by “key” you mean an actual Key Vault cryptographic key rather than a secret, select the applicable key role instead. Key Vault treats permissions for keys and secrets separately.^4^

Safe migration sequence

1. Identify the application’s current identity.
   Use the same service principal or managed identity named in the existing access policy. For an App Service making SDK calls, assign the role to that Web App’s managed identity rather than to the general Microsoft Azure App Service platform identity.^5^
2. Create the RBAC assignment before switching models.
   In Azure portal:
   • Open Key Vault → Access control (IAM).
   • Select Add → Add role assignment.
   • Choose Key Vault Secrets User.
   • Select the application’s managed identity or service principal.
   • Scope it to the vault, or to an individual secret if that narrower scope fits the application.
3. Inventory and translate every other access policy.
   Include users, deployment pipelines, automation, and operational services—not only the Minimal API. The migration documentation requires equivalent assignments for every principal that must retain access.^2^
4. Switch the permission model.
   In Azure portal:
   • Open Key Vault → Settings → Properties.
   • Change Permission model to Azure role-based access control.
   • Select Save.
   Alternatively:

      az keyvault update \
        --name <vault-name> \
        --resource-group <resource-group> \
        --enable-rbac-authorization true
   

5. Validate the application.
   Read a noncritical secret and verify that write and delete operations remain unavailable to the application identity. RBAC assignments can take several minutes to propagate, so allow for propagation before treating an immediate authorization failure as a configuration error.^2^

The account performing the migration needs both role-assignment write permission—available through Owner or User Access Administrator—and vault write permission, included in Key Vault Contributor.^2^

RBAC is the recommended model because permission management is separated from ordinary vault contribution: under legacy access policies, principals with certain vault write permissions can potentially grant themselves data-plane access.^6^

References

1. Azure Key Vault secret client library for .NET - version 4.11.2
2. Migrate to Azure RBAC from access policies
3. Azure built-in roles for Security
4. About Azure Key Vault secrets
5. Transition Azure Key Vaults to Azure RBAC - Microsoft Q&A
6. Azure role-based access control (Azure RBAC) vs. access policies (legacy)