Key vaults should have soft delete enabled

What does the recommendation "Key vaults should have soft delete enabled" check?

Flags any Key Vault where the 'enableSoftDelete' property is not set to true, meaning a deleted vault, key, secret or certificate is purged immediately with no recovery window. The check looks at the vault's configuration property only. It does not check whether purge protection ('enablePurgeProtection') is also enabled, it does not verify the length of the retention period, and it does not confirm whether your access policies or RBAC role assignments actually grant the recover and list-deleted permissions an operator would need to use soft delete in practice. A vault can pass this control yet still leave you unable to recover an object if nobody holds those permissions.

Why does "Key vaults should have soft delete enabled" matter?

Without soft delete, an accidental or malicious delete of a vault or a signing key is permanent and instant. Any application, database connection string, TLS certificate or disk-encryption key that depended on that object stops working, and there is no Azure-side path to bring it back. The business consequence is an outage with no rollback: services that cannot decrypt their data, expired certificates that cannot be reissued from the same key, and in the worst case data encrypted with a customer-managed key that is now unrecoverable. Soft delete keeps deleted objects in a recoverable state for the retention period so an operator mistake or a compromised credential cannot cause irreversible loss.

How do I fix "Key vaults should have soft delete enabled"?

1. Enable soft delete on the vault by setting 'enableSoftDelete' to true (Bicep) or running 'az keyvault update --name <vault> --enable-soft-delete true'. New vaults created through the portal already have it on by default and it cannot be turned off once enabled.
2. Decide whether you also need purge protection: set 'enablePurgeProtection' to true to block even a privileged user or attacker from force-purging objects before the retention window expires. This is required for some scenarios such as customer-managed key encryption, but note it is irreversible once set, so confirm your retention period first.
3. Set 'softDeleteRetentionInDays' to a value that fits your recovery process (7 to 90 days, default 90), grant the list, recover and purge permissions to the right operators or RBAC roles, and standardise all of this in your Bicep or Terraform vault module so every new vault inherits the safe configuration.

# Enable purge protection on every vault that lacks it. Note: this CANNOT be undone.
for kv in $(az keyvault list \
    --query "[?properties.enablePurgeProtection==null].name" -o tsv); do
  az keyvault update --name "$kv" --enable-purge-protection true
  echo "$kv: purge protection enabled (irreversible)"
done

# Give a key an expiration date and a rotation policy so it rotates before it lapses.
az keyvault key set-attributes --vault-name kv-payments-prod \
  --name db-encryption-key --expires "$(date -u -d '+1 year' +%Y-%m-%dT%H:%M:%SZ)"
az keyvault key rotation-policy update --vault-name kv-payments-prod \
  --name db-encryption-key --value @rotation-policy.json

# Ratchet it shut: deny any future vault created without deletion protection.
az policy assignment create \
  --name deny-kv-no-purge \
  --policy 0b60c0b2-2dc2-4e1c-b5c9-abbed971de53 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"