How to review who has access to Azure Key Vault

Reviewing access is read-only. Changing the permission model or role assignments is not, so plan those separately.

• To review: Reader on the subscriptions that hold the vaults, plus permission to read role assignments (Reader is enough on the vault scope).
• To change role assignments: Owner or User Access Administrator. Switching a vault to Azure RBAC also needs Microsoft.KeyVault/vaults/write, which is part of Key Vault Contributor. Microsoft states that the restricted Key Vault Data Access Administrator role cannot change the permission model.
• Tools: the Azure portal and Azure CLI (az login first).
• Know the two planes: the control plane manages the vault itself, the data plane reads and writes secrets, keys and certificates. They are authorised separately, so you must review both.

1. List your vaults. In the Azure portal open Key vaults, or run az keyvault list --query "[].{name:name, rg:resourceGroup}" -o table for the current subscription. Repeat per subscription.
2. Check the permission model of each vault. Open the vault, then Settings > Access configuration. The model is either Azure role-based access control or Vault access policy (legacy). Note which vaults still use access policies.
3. Review control-plane access. Open the vault, then Access control (IAM) > Role assignments. Pay attention to Owner, Contributor and User Access Administrator, including those inherited from the resource group or subscription. Microsoft warns that anyone with Contributor on a vault control plane can grant themselves data access by setting an access policy, so keep that role tightly controlled.
4. Review data-plane access. On an RBAC vault, look at the same IAM blade for roles such as Key Vault Administrator, Secrets Officer, Secrets User, Crypto Officer and Certificates Officer. On an access-policy vault, open Access policies and read each entry. Microsoft recommends assigning roles at the vault scope, one vault per application per environment, rather than on individual secrets, keys or certificates.
5. Check network reach. Open Networking and note whether public access is enabled and whether private endpoints are used.
6. Check logging. Open Monitoring > Diagnostic settings and confirm a setting sends the AuditEvent category to a Log Analytics workspace or storage account.
7. Write down the gaps (access-policy vaults, broad Contributor or Owner holders, vaults with no diagnostic setting) and fix them one vault at a time using the change commands below.

These commands only read. Replace the placeholders with your own values.

az keyvault show --name <vault-name> --query "{rbac:properties.enableRbacAuthorization, publicAccess:properties.publicNetworkAccess, accessPolicies:length(properties.accessPolicies)}"

az role assignment list --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name> --include-inherited -o table

az monitor diagnostic-settings list --resource /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name> -o table

What good looks like: rbac is true, the role list shows only the people and identities you expect, and at least one diagnostic setting exists.

Changes (these modify your Azure environment)

Change 1: switch a vault to Azure RBAC. Microsoft warns that setting the Azure RBAC permission model invalidates all access policy permissions and can cause outages if equivalent roles are not assigned first. Assign the roles below before you switch, in the portal under Access configuration.

Change 2: give an identity least-privilege data access at the vault scope.

az role assignment create --role "Key Vault Secrets User" --assignee <user-or-app-id> --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>

Change 3: send audit events to Log Analytics.

az monitor diagnostic-settings create --name kv-audit --resource /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name> --workspace <workspace-id> --logs '[{"category":"AuditEvent","enabled":true}]'

Role changes can take several minutes to take effect. Microsoft notes that Key Vault logs appear within about 10 minutes of an operation at most.

• Switching to RBAC before assigning roles. Existing access policies stop working at once and applications lose access.
• Forgetting the control plane. A broad Contributor assignment can be turned into data access, so reviewing only data-plane roles is not enough.
• Assigning roles on single secrets. Microsoft advises this only for specific cases, such as an individual secret shared between applications. It is hard to audit at scale.
• Sharing one vault across many applications and environments. Vault-level permissions then expose everything to every operator.
• Ignoring inherited assignments. Use --include-inherited so subscription and resource group roles are not missed.
• Logging without a retention plan. You must manage and secure the log destination yourself.

ConfigCobra is read-only and never changes your Azure environment. It scans every subscription the app can read with Reader access, and its Azure inventory lists Key Vault resources with their security properties, such as secrets and keys without an expiry. Each finding points at the exact resource, and for a failing control the remediation impact analysis shows which resources and identities would be affected before you apply a fix. The Azure benchmarks cover the Key Vault checks linked below. Start with the 14-day free trial, which has full access.