Key Vault Soft-Delete and Purge Protection: Why Every Azure Vault Needs Them

Key Vault is where a lot of teams keep the keys to the kingdom: TLS certificates, database connection strings, storage account keys, and the encryption keys that protect everything else. Which makes it a strange place to leave recovery features switched off. Yet plenty of vaults, especially older ones created before 2021, still run without soft-delete or purge protection. This check catches them before a bad day turns into an outage you cannot undo.

---

What this check detects

The keyvault_softdelete check inspects every Azure Key Vault in your subscriptions and flags any vault where one or both of these protections are missing:

• Soft-delete retains deleted vaults, keys, secrets, and certificates for a configurable retention period (7 to 90 days) instead of removing them immediately. During that window you can recover them.
• Purge protection blocks permanent deletion (a "purge") during the soft-delete retention period. Even a Key Vault administrator cannot force the data out early.

The reason both matter is subtle. Soft-delete alone gives you a recovery window, but anyone with Microsoft.KeyVault/locations/deletedVaults/purge/action permission can still purge the data inside that window. Purge protection closes that gap.

---

Why it matters

The risk here is permanent, unrecoverable data loss of your most sensitive material. There are a few ways it plays out.

Accidental deletion

Someone runs a Terraform destroy against the wrong workspace, or a cleanup script targets the wrong resource group. Without soft-delete, the vault and every secret in it are gone instantly. Any application that was reading those secrets starts failing the moment its cached values expire. Certificate-based auth breaks, database connections drop, and you have no copy to restore from.

Malicious destruction

An attacker who compromises a privileged identity often wants to do damage that is hard to reverse. Purging a Key Vault is a tidy way to destroy encryption keys and lock you out of the data they protected. If you use Key Vault keys for storage account or disk encryption, purging the key can render that encrypted data permanently unreadable. This is the cloud equivalent of burning the only copy of the recovery code.

Compliance and audit exposure

Frameworks like CIS Azure Foundations, SOC 2, and ISO 27001 expect controls that prevent loss of cryptographic material. A vault without these protections will show up as a finding in most audits, and "we meant to enable it" is not a control.

---

How to fix it

You can enable both features without recreating the vault and without downtime. Soft-delete and purge protection are one-way switches: once on, they cannot be turned off. That is intentional.

Azure CLI

Check the current state of a vault first:

az keyvault show \
  --name myVault \
  --query "properties.{softDelete:enableSoftDelete, purgeProtection:enablePurgeProtection, retentionDays:softDeleteRetentionInDays}"

Enable soft-delete (if somehow disabled) and purge protection together:

az keyvault update \
  --name myVault \
  --resource-group myResourceGroup \
  --enable-soft-delete true \
  --enable-purge-protection true \
  --retention-days 90

Azure Portal

1. Open the Key Vault and go to Settings > Properties.
2. Under Soft-delete, confirm it is enabled and set the retention period.
3. Under Purge protection, select Enable purge protection.
4. Click Save.

Terraform

For new and existing vaults managed in Terraform, set these arguments on the azurerm_key_vault resource:

resource "azurerm_key_vault" "main" {
  name                = "my-vault"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  tenant_id           = data.azurerm_client_config.current.tenant_id
  sku_name            = "standard"

  soft_delete_retention_days = 90
  purge_protection_enabled   = true
}

Bicep

resource vault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'my-vault'
  location: location
  properties: {
    tenantId: tenant().tenantId
    sku: {
      family: 'A'
      name: 'standard'
    }
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
  }
}

---

How to prevent it from happening again

Fixing the vaults you have today is the easy part. The harder part is making sure the next vault someone spins up is born compliant. Use a layered approach.

1. Enforce with Azure Policy

Microsoft ships a built-in policy that denies creation of vaults without purge protection. Assign it at the management group or subscription level:

# Built-in policy: "Key vaults should have deletion protection enabled"
az policy assignment create \
  --name "require-kv-purge-protection" \
  --display-name "Require Key Vault purge protection" \
  --policy "0b60c0b2-2dc2-4e1c-b5c9-abbed971de53" \
  --scope "/subscriptions/" \
  --enforcement-mode Default

With enforcement mode set to Default, any attempt to create or update a vault without purge protection is denied at the control plane. That stops the problem at the source, no matter which tool the request came from.

2. Sweep existing vaults

Enable purge protection across every vault in a subscription in one pass:

az keyvault list --query "[].name" -o tsv | while read vault; do
  echo "Enabling purge protection on $vault"
  az keyvault update --name "$vault" --enable-purge-protection true
done

3. Gate it in CI/CD

If you provision infrastructure as code, catch missing purge protection before it merges. A quick check on Terraform plans, or a policy-as-code tool like Checkov or Conftest, keeps non-compliant config out of main:

# Checkov flags Key Vault without purge protection via CKV_AZURE_42
checkov -d . --check CKV_AZURE_42

Wire that into a pull request check so the gate runs automatically on every change.

---

Best practices

• Set retention to 90 days unless you have a reason not to. Storage of soft-deleted objects is free, and a longer window gives you more room to catch an accidental deletion before it is too late.
• Always pair purge protection with RBAC. Purge protection limits damage; tight access control prevents it. Grant the Key Vault Administrator role sparingly and prefer the RBAC permission model over legacy access policies.
• Add resource locks for an extra layer. A CanNotDelete lock on the vault stops accidental deletes before soft-delete even comes into play.
• Separate vaults by blast radius. Keep production secrets in dedicated vaults with their own access boundaries, so a mistake in a dev vault never touches production material.
• Monitor delete and purge events. Send Key Vault diagnostic logs to a Log Analytics workspace and alert on VaultDelete and VaultPurge operations. Recovery is much easier when you find out within minutes.
• Run continuous checks. A point-in-time fix drifts. Scanning your environment regularly with Lensix keeps soft-delete and purge protection findings visible the moment a non-compliant vault appears.

Soft-delete and purge protection are the kind of controls you set once and forget, right up until the day they save you from permanent data loss. Enable them everywhere, enforce them with policy, and move on to the next problem.