Azure Key Vault Architecture Note: Soft-Delete and Purge Protection Baseline

A deleted Azure Key Vault object is not immediately unrecoverable—unless someone purges it. The smallest recoverable control-plane design treats soft-delete and purge protection as mandatory properties of every vault that holds production keys, secrets, or certificates. This note covers the requirements, the minimal vault configuration, trust boundaries, operational checks, and the failure modes that still break the design.

Requirements

Protect keys, secrets, and certificates from accidental or malicious permanent deletion while preserving least-privilege access through managed identities and Azure RBAC. Soft-delete retains deleted vaults and vault objects for a retention window; purge protection blocks immediate permanent purge. The design must separate who can delete from who can recover, and must expose deletion and recovery events to operations teams.

The smallest suitable design

One Standard or Premium key vault in the workload region with soft-delete and purge protection enabled, a private endpoint plus deny-by-default firewall, Azure RBAC data-plane assignments only, and workload access via managed identity. No connection strings or certificates in application code or configuration files.

Before changing a production vault, inspect the current properties. Run the following in Azure Cloud Shell (Bash) or a local Azure CLI session; you need at least Reader on the vault, or Contributor/Owner on the resource group to modify it. These commands assume a current Azure CLI version—verify exact syntax and property names against the CLI reference for your installed version.

az keyvault show \
  --name <vault-name> \
  --resource-group <resource-group> \
  --query "{softDelete:properties.enableSoftDelete, purgeProtection:properties.enablePurgeProtection, retentionDays:properties.softDeleteRetentionInDays}"

Expected check: softDelete and purgeProtection both return true, and retentionDays matches your policy. If purge protection is false, a deleted vault or object can be purged immediately by a principal with purge permissions.

To enable purge protection on an existing vault—an irreversible change:

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

Re-run the show command to confirm the property flipped to true. Risk: purge protection cannot be disabled after it is enabled, so confirm retention length and recovery ownership before running this command.

Trust and data boundaries

Key Vault has two distinct planes. The management plane controls vault lifecycle—create, delete, network rules, and RBAC or legacy access-policy assignments—and is governed by Azure roles such as Contributor or Owner. The data plane controls key, secret, and certificate operations—get, set, sign, encrypt, recover—and is governed by Key Vault RBAC roles (for example, Key Vault Administrator or Key Vault Secrets User) or legacy access policies. Do not mix legacy access policies and Azure RBAC without validating effective permissions; conflicting grants can widen the data-plane boundary.

The network boundary is enforced with a private endpoint and a firewall set to deny public traffic by default. Workloads authenticate with a system-assigned or user-assigned managed identity, so no client secret is stored in the application. Key Vault audit events—delete, recover, purge, and access-policy or RBAC changes—should stream to a Log Analytics workspace so that control-plane changes are visible to operations.

Operational checks

Recovery is only real if it has been rehearsed. In a non-production subscription, create a test vault with purge protection enabled, delete a test secret, and recover it within the retention window:

az keyvault secret list-deleted --vault-name <test-vault-name>
az keyvault secret recover --vault-name <test-vault-name> --name <test-secret-name>

Expected check: az keyvault secret show returns the secret metadata again. Repeat for keys and certificates. Then attempt to purge the same object with purge protection enabled; the operation should fail. Turn purge protection off on a separate test vault and confirm that purge succeeds immediately, so the team understands the difference.

Alert on vault deletion, secret or key purge, and access-policy or RBAC assignment changes. Verify certificate expiry and exportability before relying on Key Vault as the only copy; a non-exportable key cannot be recovered by exporting it.

Failure modes that break the design

• No purge protection: a deleted vault or object can be purged immediately and become unrecoverable.
• Retention expiry: soft-deleted objects are permanently purged when the retention window ends; soft-delete is not a backup.
• Irreversible purge protection: once enabled, purge protection generally cannot be disabled on that vault.
• Non-exportable keys: soft-delete does not override key export restrictions; if the key material is not exportable, recovery restores the key reference, not a portable copy.
• Subscription or resource-group deletion: vault soft-delete behavior can change under subscription lifecycle and locking policy; validate this before relying on recovery.
• Mixed permission models: combining legacy access policies with Azure RBAC can produce effective permissions wider than intended.

Conditions that change the design

Regulatory or operational requirements for immediate, irrevocable destruction argue against purge protection; in that case, document the destruction procedure and compensating controls instead. FIPS or HSM-boundary requirements may require the Premium SKU for HSM-protected keys, or Azure Managed HSM if the boundary must be fully customer-controlled. Multi-region resilience requires vault replication or a regional failover design; soft-delete alone is not geo-redundancy and does not protect against regional loss.

Because SKU defaults, regional availability, and Managed HSM differences can vary by release and region, confirm current behavior against live Azure documentation before finalizing production vaults.