Key Vault access & recovery

RBAC data plane, purge protection, private vaults.

Azure Key Vault is the governed home for the three credential types — secrets, keys, and certificates — and how you use it (the access model, the recovery settings, the network exposure) decides whether it is a strong control or a single point of failure.

RBAC data-plane access over legacy policies

A vault has two access models. The legacy vault access policies grant coarse permission sets and are all-or-nothing per operation type; the newer Azure RBAC data-plane model gives granular, consistent, auditable roles like Key Vault Secrets User (read secrets) and Key Vault Administrator (manage). Prefer RBAC — it aligns vault access with the rest of your Azure authorization, supports PIM for just-in-time admin, and lets you grant a workload read on exactly the secrets it needs rather than the whole vault.

# Enable the RBAC data-plane model on the vault, then grant least privilege.
az keyvault update -g rg -n app-kv --enable-rbac-authorization true
 
# The app's managed identity may READ secrets — nothing more.
az role assignment create --assignee-object-id $APP_MI \
  --role "Key Vault Secrets User" \
  --scope $(az keyvault show -g rg -n app-kv --query id -o tsv)
# Admins get "Key Vault Administrator" as a PIM-eligible, just-in-time role.

Recovery and network exposure

Turn on soft-delete and purge protection so keys and secrets cannot be permanently destroyed — by accident or by an attacker — during the retention window; without purge protection, a compromised admin can wipe your keys irrecoverably. Restrict the vault to a Private Endpoint (or selected networks) with public access disabled, so a leaked token cannot reach it from the internet, and enable diagnostic logging so every secret and key access is auditable and anomalous bulk reads are visible.