Azure Key Vault: Purge Rights on Service Principals
Azure Key Vault: Purge Rights on Service Principals sits in the Azure Key Vault Security risk register because a small configuration shortcut can widen access, weaken control boundaries, or hide failure conditions. The risk usually starts with terraform and ARM quickstart snippets for azurerm_key_vault frequently list secret_permissions = ["get","list","set","delete","purge"] because the example was lifted from an "administrator" policy block rather than In production, the concern is a compromised or over-scoped pipeline identity can issue az keyvault
The Trap
An access policy on an Azure Key Vault grants the Purge permission (secrets, keys, or certificates) to an application service principal, most commonly a CI/CD identity such as a GitHub Actions OIDC principal or a Terraform apply account.
The Default State
Terraform and ARM quickstart snippets for azurerm_key_vault frequently list secret_permissions = ["get","list","set","delete","purge"] because the example was lifted from an “administrator” policy block rather than a scoped one. Soft-delete is enabled by default in current API versions, but purge protection (enablePurgeProtection) is not enforced unless explicitly set, so the Purge permission is live and unguarded from the moment the vault is created.
The Blast Radius
A compromised or over-scoped pipeline identity can issue az keyvault secret purge or the equivalent key/certificate call and permanently remove an object during what should be its 7-to-90-day soft-delete retention window. There is no recovery, no approval gate, and no MFA check, because service principals cannot be interactively challenged. If the purged object is an HSM-backed key used for encryption at rest, the data it protected becomes unrecoverable the instant the key is gone, functionally a self-inflicted crypto-shred. Because purge protection cannot be retrofitted onto already-purged objects, this failure is discovered only after the secret, certificate, or key is unrecoverable, typically during an incident response window when the team is trying to rotate or restore exactly the material that no longer exists.
The Lead Mechanic Fix
Enable purge protection immediately: az keyvault update --name <vault> --enable-purge-protection true. Strip Purge from every service principal’s access policy: az keyvault set-policy --name <vault> --spn <appId> --secret-permissions get list set delete --key-permissions get list create delete --certificate-permissions get list create delete. Migrate the vault to RBAC authorization with --enable-rbac-authorization true and assign scoped roles like Key Vault Secrets Officer, never Key Vault Administrator, to pipeline identities. Reserve the purge action for a PIM-eligible human role requiring MFA and approval, and alert on PurgeSecret, PurgeKey, and PurgeCertificate entries in the AuditEvent diagnostic category.