Soft delete saved us once.

Purge protection blocked us twice.

Here is what we learned about Key Vault deletion safeguards.

Soft Delete Is Enabled by Default Now

Soft delete used to be optional.

Now it is mandatory for all new Key Vaults.

When you delete a vault, it is not really deleted. It is soft-deleted.

It stays in a deleted state for 90 days by default.

You can recover it during that time.

After 90 days, it purges automatically.

It Saved Us From a Mistake

A developer accidentally deleted a Key Vault in production.

Panic. Incident. All hands on deck.

Then we remembered soft delete.

We ran:

az keyvault recover --name prod-keyvault

The vault came back. Secrets intact. No data loss.

The incident closed in 15 minutes instead of hours.

Soft delete worked exactly as designed.

Then We Hit Purge Protection

Purge protection is an additional safeguard.

When enabled, you cannot purge a deleted vault until the retention period expires.

Even if you want to.

We had a dev vault we wanted to delete and recreate.

We deleted it. Then tried to create a new vault with the same name.

Error: “Vault name already in use.”

The vault was soft-deleted, not purged.

We tried to purge it manually:

az keyvault purge --name dev-keyvault

Error: “Purge protection is enabled.”

We had to wait 90 days or use a different name.

We used a different name.

The Namespace Collision Problem

Key Vault names are globally unique.

Once a name is used, it stays reserved during the soft-delete retention period.

We could not recreate a vault with the same name until the deleted one was purged.

This blocked:

  • infrastructure as code re-deployments
  • testing vault configurations
  • cleanup after failed deployments

We started using name suffixes with timestamps to avoid collisions.

Not elegant. But it worked.

Purge Protection Is Required for Compliance

For production vaults, purge protection is non-negotiable.

Compliance frameworks require it:

  • prevent accidental deletion
  • prevent insider threats
  • meet data retention requirements

We enable purge protection on all production vaults.

But we do not enable it on dev or test vaults.

That gives us flexibility without sacrificing production safety.

Recovery Is Not Instant

Recovering a soft-deleted vault takes time.

The vault must be reactivated. DNS must propagate. Access policies must sync.

We recovered a vault once and immediately tried to access secrets.

It failed. The vault was recovering but not ready yet.

We had to wait 10 minutes before apps could connect.

Now we build that wait time into our recovery runbooks.

Deleted Secrets Also Have Soft Delete

It is not just vaults.

Secrets, keys, and certificates inside a vault also have soft delete.

When you delete a secret, it is soft-deleted. You can recover it.

When you recreate a secret with the same name, it fails if the deleted version still exists.

You have to either:

  • recover the old secret
  • purge the old secret (if purge protection allows it)
  • wait for the retention period to expire

We learned this when rotating secrets.

We deleted the old secret. Created a new one with the same name. It failed.

We had to purge the deleted secret first, then create the new one.

How We Manage It Now

We have clear policies:

Production vaults:

  • soft delete enabled (mandatory)
  • purge protection enabled (required for compliance)
  • 90-day retention period
  • recovery tested quarterly

Non-production vaults:

  • soft delete enabled (mandatory)
  • purge protection disabled (for flexibility)
  • 7-day retention period (minimum allowed)
  • deleted vaults purged manually after validation

This balances safety and agility.

Our Deletion Checklist

Before deleting a vault:

  1. Verify it is not in use (check Managed Identity access, app configs, logs).
  2. Export secrets if needed for backup.
  3. Document why it is being deleted.
  4. Check if the name will be reused (if yes, plan for retention period).
  5. Delete the vault.
  6. If purge protection is disabled and name reuse is needed, purge immediately.
  7. Update infrastructure as code to reflect the deletion.

We do not delete vaults casually anymore.

The Lesson

Soft delete is a safety net. It works.

Purge protection is a compliance requirement. It is also a constraint.

You need both for production. You need flexibility for development.

Design your vault strategy with deletion in mind.

Because deletion is not instant. It is not reversible after purge. And it blocks namespace reuse.

We learned that the hard way.

Now we plan for deletion before we create the vault.

That is the right order.