Enable Key Vault purge protection only after choosing a recoverability window

Bottom line: Azure Key Vault soft delete retains deleted vaults and objects for a configured period so they can be recovered. Purge protection prevents permanent deletion during that retention period. Microsoft states that purge protection cannot be disabled or overridden once enabled. Choose the retention and recovery operating model before production enforcement.

Source fact: what Microsoft documents

Microsoft’s Key Vault recovery overview distinguishes soft delete from purge protection. Soft delete places a deleted vault, key, secret, or certificate into a recoverable state for a configurable retention period. Names remain reserved while the corresponding object is soft-deleted, subject to the documented naming scope.

Purge protection prevents permanent purge until the retention period has elapsed. Microsoft states that no administrator and not even Microsoft can override or disable purge protection once it is enabled. After retention ends, deletion completes according to the service behavior. Recovery and purge require appropriate permissions, and linked Azure services can have additional recovery steps because role assignments, Event Grid subscriptions, or other integrations might not be restored automatically.

What the source does not establish

Soft delete does not protect a secret from authorized reading, stop use of a compromised key, maintain application availability after deletion, or replace backup and configuration evidence. Recovery of a vault object does not necessarily restore dependent application configuration or permissions. Purge protection can also delay legitimate name reuse or decommissioning; the retention window is an operational constraint, not only a security benefit.

Applicability questions

• Which keys, secrets, certificates, applications, managed identities, and services depend on each vault?
• What deletion-detection and recovery time is required, and what retention period supports it?
• Who can delete, recover, purge, change retention-related settings, and modify access?
• Which role assignments, network rules, private endpoints, Event Grid subscriptions, or integrations must be recreated after recovery?
• Is the vault production, test, ephemeral, or subject to a legal deletion requirement?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Inventory vault dependencies and select retention from incident detection, recovery, and legitimate decommissioning needs.
2. Enable purge protection for production through infrastructure as code or a governed change, recognizing that it cannot later be disabled.
3. Separate routine object administration from deletion, purge, and recovery authority and alert on those operations.
4. Exercise key, secret, certificate, and vault recovery in a safe scope, including recreation of dependent permissions and integrations.
5. Preserve independent configuration and application-recovery procedures; do not rely on the recycle state as the complete recovery plan.

Verification and evidence

• Preserve vault retention, soft-delete and purge-protection state, role assignments, dependencies, and approval.
• Record deletion and recovery tests with timestamps and object identifiers but never secret values or private keys.
• Verify applications can use the recovered object and that network and permission dependencies are restored.
• Monitor delete, recover, purge, and access-policy or RBAC changes through protected logging.

Official references

• Azure Key Vault recovery overview — Microsoft