RBAC Migration Bundles Purge Into Key Vault Admin
Azure Key Vault's RBAC model has no built-in role for delete-without-purge, so migrating from access policies to Key Vault Administrator quietly grants permanent-erase rights to every principal in that assignment scope, with no separate toggle to strip it back out.
At a glance
- Unsafe setting
- Key Vault Administrator RBAC role assigned at subscription or resource-group scope to automation service principals.
- Failure trigger
- A pipeline credential compromise or misdirected cleanup script calls purge on secrets or keys with purge protection disabled.
- Blast radius
- Secrets, keys and certificates are permanently erased with no soft-delete recovery path, and the action often goes unlogged without AuditEvent diagnostics enabled.
- Recommended control
- Enable purge protection at vault creation and replace broad Administrator role assignments with a custom role excluding the purge data action, scoped per vault.
Fix commands and configuration
enablePurgeProtection: trueaz role definition create --role-definition '{"Name":"KV Data Manager No Purge","DataActions":["Microsoft.KeyVault/vaults/secrets/*","Microsoft.KeyVault/vaults/keys/*"],"NotDataActions":["Microsoft.KeyVault/vaults/secrets/purge/action","Microsoft.KeyVault/vaults/keys/purge/action"]}'The Trap
Assigning the built-in Key Vault Administrator RBAC role during a migration from vault access policies to Azure RBAC, believing it maps cleanly onto the old "manage keys and secrets but not purge" access-policy template.
The Default State
The Azure Portal’s Key Vault migration wizard sets enableRbacAuthorization: true and offers Key Vault Administrator (role definition ID 00482a5a-887f-4fb3-b363-3b7fe8e74483) as the direct replacement for full access-policy grants. That role’s data actions include Microsoft.KeyVault/vaults/purge/action alongside every secret, key and certificate operation. Under the old access-policy model, teams could grant Get/List/Delete without ticking the Purge permission checkbox. Under RBAC, no equivalent built-in role exists — it is Administrator (with purge) or Reader/Officer roles that cannot delete at all. Engineers assign Administrator at subscription or resource-group scope to CI/CD service principals or Terraform automation accounts purely to keep deployments working, assuming purge sits behind a separate gate. It does not.
The Blast Radius
Combine this with enablePurgeProtection: false, which is still the vault creation default in most ARM/Bicep templates outside regulated landing zones, and any principal holding Administrator at broad scope can call az keyvault secret purge or the equivalent Purge REST call and bypass the soft-delete retention window entirely — no 7 to 90 day recovery period, no restore path. A single bad terraform destroy, a compromised pipeline credential, or a scripted cleanup job run against the wrong resource group erases certificates and encryption keys permanently. Because Purge actions only surface under the AuditEvent diagnostic category, and that category is frequently left off vault diagnostic settings, the deletion often produces no alert until dependent services fail to fetch a secret that no longer exists anywhere, including in Recovery Services.
The Lead Mechanic Fix
Set enablePurgeProtection: true at vault creation — it is immutable once set and cannot be disabled later, which is the point. Then replace broad Administrator assignments with a custom role definition that excludes the purge data action: az role definition create --role-definition '{"Name":"KV Data Manager No Purge","DataActions":["Microsoft.KeyVault/vaults/secrets/*","Microsoft.KeyVault/vaults/keys/*"],"NotDataActions":["Microsoft.KeyVault/vaults/secrets/purge/action","Microsoft.KeyVault/vaults/keys/purge/action"]}', and scope that role to the individual vault, not the resource group or subscription. Reserve genuine Administrator assignments for break-glass accounts only.