Missing Purge Protection Lets Azure Key Vault Soft-Delete Give False Recovery Confidence

Symptom

A Key Vault security review confirms soft-delete is active on every production vault, yet during an incident a service principal purges a batch of secrets outright and none of them come back during what everyone assumed was a protected retention window. The audit log shows a normal-looking delete followed almost immediately by a purge, and recovery tooling that relied on soft-delete simply has nothing left to restore.

False Assumption

Teams treat "soft-delete is enabled" as proof that Key Vault contents are protected against accidental or malicious deletion. Soft-delete is enabled by default on current Key Vault resources and cannot be turned off, so it feels like a permanent guarantee. That guarantee only covers the retention window itself; it says nothing about whether a purge during that window is blocked.

Root Cause

Purge protection is the control that actually blocks permanent deletion during the soft-delete retention window, and it is a separate, independently configured property from soft-delete itself. A vault can have soft-delete on and purge protection off at the same time, and nothing in the standard portal soft-delete indicator distinguishes that state from a fully protected vault. Any principal with delete-then-purge rights on such a vault can remove an object and immediately purge it, collapsing the retention window to zero.

Impact

Any principal holding purge rights on an affected vault can permanently destroy secrets, keys and certificates in seconds, with no recovery path once the purge completes. Where the vault holds customer-managed encryption keys, the consequence extends beyond the vault itself: data encrypted with a purged key can become permanently inaccessible, turning a configuration gap into an availability and data-protection incident rather than a simple access-control finding.

Diagnosis

Confirm the current state before assuming either way. This is read-only and safe to run against production.

az keyvault show --name <vault-name> --query "properties.enablePurgeProtection" -o tsv

Then check the wider estate for the same gap, since one hardened vault does not imply the rest of the subscription is consistent:

az keyvault list --query "[?properties.enablePurgeProtection==null || properties.enablePurgeProtection==false].name" -o tsv

Cross-check which permission model each affected vault uses (access policies or Azure RBAC), because who actually holds purge rights differs between the two models and the portal's access policy list will not tell the whole story under RBAC.

Correction

Enable purge protection explicitly on every vault that must not lose data to a rushed or malicious delete-then-purge sequence. Test the change in an isolated non-production vault first.

az keyvault update --name <vault-name> --resource-group <resource-group> --enable-purge-protection true

Treat this as a deliberate, change-managed action rather than a routine toggle, because the setting cannot later be reversed on that vault.

Validation

Confirm the change by independently re-querying vault properties rather than trusting the command's own success message. Re-run the discovery query and confirm the target vault no longer appears in the non-compliant list, then in the non-production vault, delete a disposable test secret and attempt to purge it during the retention window; the purge attempt should be rejected while the secret remains recoverable. Only treat the control as proven once both checks pass independently.

Rollback

There is no technical way to disable purge protection once it is enabled on a given vault, so the only rollback available is procedural, not technical. If the change turns out to have been applied in error, or if it blocks a legitimate process that intentionally purges disposable secrets, the recovery path is to create a new vault without purge protection, migrate the required secrets, keys and certificates into it, update dependent application references, and decommission the original vault once migration is verified. This is why validation in a non-production vault before touching production is not optional.

Prevention

Bake purge protection into the vault provisioning template or pipeline so new vaults are created with it enabled from the start, rather than relying on a later manual step that can be skipped. Add the discovery query to a recurring configuration check so drift is caught before an incident, not after one, and review which principals hold purge rights separately from which principals hold delete rights, since the two are often granted together without anyone examining the combination.