RBAC Migration Bundles Purge Into Key Vault Admin

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.