Configuring soft delete and purge protection for Azure Ke...

A single accidental az keyvault delete command, a misfiring Terraform destroy, or an attacker with elevated permissions can wipe out every secret, key, and certificate your production systems depend on. Without Key Vault soft delete purge protection enabled, that deletion can become permanent within minutes — no recovery window, no safety net. Soft delete gives you a retention period to recover deleted secrets Azure workloads rely on, while purge protection stops anyone, including a compromised admin account, from force-purging that retained data before the retention window expires.

In this guide, you'll learn how to check your current configuration, enable both protections on new and existing vaults, tune retention settings, recover accidentally deleted objects, and adopt backup practices that complement — rather than replace — these built-in safeguards. By the end, your vaults will be resilient against both accidental deletion and deliberate tampering.

Step 1: Understand What Soft Delete and Purge Protection Actually Do

Before changing any settings, it's worth being precise about what each control does, because they solve different problems.

• Soft delete retains a deleted vault (or a deleted secret, key, or certificate within a vault) for a configurable retention period — 7 to 90 days, default 90 — instead of removing it immediately. During that window, the object is recoverable but not usable.
• Purge protection prevents anyone from permanently purging a soft-deleted vault or object before the retention period expires, even a user with Purge permissions or the Owner role on the subscription.

Soft delete alone protects against accidental deletion. It does not protect against a malicious actor who deletes and then immediately purges the vault to destroy evidence or sabotage recovery. That's why Microsoft requires soft delete as a prerequisite for purge protection, and why any vault holding production credentials should run with both enabled. As of recent Azure policy updates, soft delete is enabled by default on new vaults and can no longer be disabled — but purge protection is still opt-in and is the setting most teams forget.

Step 2: Enable Key Vault Soft Delete Purge Protection on a New Vault

When creating a new vault, enable both properties in the same command:

az keyvault create \
  --name "kv-prod-app01" \
  --resource-group "rg-security-prod" \
  --location "eastus" \
  --enable-soft-delete true \
  --retention-days 90 \
  --enable-purge-protection true

Equivalent Bicep/ARM snippet:

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-prod-app01'
  location: location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    accessPolicies: []
  }
}

Terraform users should set the matching arguments on azurerm_key_vault:

resource "azurerm_key_vault" "prod" {
  name                       = "kv-prod-app01"
  location                   = var.location
  resource_group_name        = var.rg_name
  tenant_id                  = var.tenant_id
  sku_name                   = "standard"
  soft_delete_retention_days = 90
  purge_protection_enabled   = true
}

Step 3: Enable Purge Protection on an Existing Vault

If you inherited vaults created before purge protection was standard practice, you can enable it in place — but be aware this is a one-way operation. Once purge protection is on, it cannot be turned off for the life of the vault.

az keyvault update \
  --name "kv-legacy-app02" \
  --resource-group "rg-security-prod" \
  --enable-purge-protection true

Soft delete cannot be disabled on modern vaults, so most legacy-vault remediation work is simply this one purge protection flag. Run this against every vault in your subscriptions, not just the ones you remember creating — orphaned vaults from old pipelines are a common gap.

Step 4: Audit Every Vault in Your Tenant for Compliance

A single command tells you which vaults are unprotected:

az keyvault list --query "[].{name:name, resourceGroup:resourceGroup}" -o table

for vault in $(az keyvault list --query "[].name" -o tsv); do
  az keyvault show --name "$vault" \
    --query "{name:name, softDelete:properties.enableSoftDelete, purgeProtection:properties.enablePurgeProtection}" \
    -o tsv
done

For larger estates, use Azure Policy to enforce and continuously report on this instead of scripting it ad hoc:

az policy assignment create \
  --name "enforce-kv-purge-protection" \
  --policy "0b60c0b2-2dc2-4e1c-b5c9-abbed971de53" \
  --scope "/subscriptions/<subscription-id>"

(Use az policy definition list --query "[?contains(displayName, 'purge protection')]" to confirm the built-in definition ID in your environment, as Microsoft occasionally revises these.)

Step 5: Recover Deleted Secrets, Keys, and Certificates

Soft delete is only useful if your team actually knows how to recover deleted secrets Azure vaults are holding when someone deletes them by mistake. List what's recoverable, then restore it:

# List soft-deleted secrets in a vault
az keyvault secret list-deleted --vault-name "kv-prod-app01" -o table

# Recover a specific secret
az keyvault secret recover --vault-name "kv-prod-app01" --name "db-connection-string"

# The same pattern applies to keys and certificates
az keyvault key recover --vault-name "kv-prod-app01" --name "app-signing-key"
az keyvault certificate recover --vault-name "kv-prod-app01" --name "tls-cert-2026"

If the whole vault itself was deleted (not just an object inside it), recover the vault first, then reapply access policies and RBAC assignments, since those don't always follow the vault back automatically:

az keyvault list-deleted -o table
az keyvault recover --name "kv-prod-app01" --location "eastus"

Document this recovery procedure somewhere your on-call engineers will actually find it during an incident — the middle of an outage is the wrong time to be reading Azure CLI docs for the first time.

Step 6: Apply Key Vault Backup Best Practices Alongside Soft Delete

Soft delete and purge protection cover deletion scenarios, but they don't protect against region-wide outages, cross-tenant migrations, or the need to restore a vault's contents into a different subscription. That's where a real backup strategy comes in. Key Vault backup best practices worth adopting:

1. Export individual objects regularly for vaults holding high-value secrets:

   az keyvault secret backup --vault-name "kv-prod-app01" --name "db-connection-string" --file "db-secret.blob"
   

2. Store backup blobs encrypted and access-controlled, ideally in a separate subscription or tenant than the source vault, so a single compromised identity can't destroy both the live vault and its backups.
3. Test restores on a schedule, not just when you need one:

   az keyvault secret restore --vault-name "kv-dr-app01" --file "db-secret.blob"
   

4. Pair backups with infrastructure-as-code for the vault itself (access policies, network rules, diagnostic settings) so a full rebuild doesn't rely on institutional memory.
5. Rotate and re-back-up after every credential rotation — a stale backup that restores an already-revoked secret provides false confidence.

Backups are a complement to soft delete and purge protection, not a substitute. Soft delete handles the "oops" scenario within days; backups handle the "our region is gone" or "we need this in a different tenant" scenario.

Verification and Troubleshooting

Confirm settings took effect. Both enableSoftDelete and enablePurgeProtection should read true:

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

"Purge protection cannot be disabled" error. This is expected behavior, not a bug. Once enabled, the setting is permanent for the vault's lifetime by design — plan retention days accordingly before enabling it in production.

"A vault with the same name already exists in deleted state." This happens when you try to recreate a vault with a name that's still in its soft-delete retention window. Either recover the existing deleted vault or purge it explicitly (only possible if purge protection was never enabled on it) with az keyvault purge --name <name> --location <region>.

Recovered secret has an old version. Recovery restores the secret object and its version history as of deletion time; if you need the very latest value and it was rotated after deletion, you'll need your external backup or the rotating system's own record, which is another reason Step 6 matters.

Policy assignment shows non-compliant but vaults look correct. Azure Policy compliance scans run on a schedule (typically up to 24 hours) rather than instantly — trigger an on-demand scan with az policy state trigger-scan if you need immediate confirmation after remediation.

How Safeguard Helps

Manually auditing every Key Vault across every subscription in a growing Azure estate doesn't scale, and it's exactly the kind of configuration drift that slips through during a busy sprint. Safeguard continuously inventories your cloud resources, including Key Vaults, and flags any vault where soft delete or purge protection is missing, misconfigured, or was silently reverted by an automation script or a well-meaning but under-informed teammate.

Beyond point-in-time checks, Safeguard maps Key Vault configuration into your broader software supply chain risk picture — correlating which pipelines, service principals, and workloads depend on which secrets, so a misconfigured vault is prioritized by actual blast radius rather than treated as an isolated finding. That means your security team spends less time chasing spreadsheets of vault settings and more time on the handful of vaults that genuinely matter, with evidence-ready reporting for audits that ask you to prove these controls are in place, not just configured once and forgotten.

If you're responsible for securing secrets across a multi-team Azure environment, Safeguard gives you the continuous visibility to know that Key Vault soft delete purge protection is enforced everywhere it should be, before an incident forces you to find out the hard way.