Compliance

Harden Key Vault data protection

One capability across every Key Vault: make sure a deleted or compromised vault can be recovered rather than lost for good, and that no key lives forever, so the secrets, keys and certificates the estate depends on cannot be wiped, lost or quietly left valid indefinitely.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-keyvault-certificate-validity-period azure-keyvault-key-expiration azure-keyvault-purge-protection azure-keyvault-secret-expiration azure-keyvault-soft-delete

Hardening Key Vault data protection: the basics

What does an under-protected Key Vault actually look like?

A Key Vault is the most leverage-dense object in an Azure subscription: it holds the secrets, keys and certificates that everything else trusts. Under-protection shows up in a handful of distinct shapes rather than one setting. Purge protection can be off, so a soft-deleted vault, or anyone with rights, can permanently erase its contents inside the recovery window. Soft delete governs whether a deleted vault is recoverable at all for a 7 to 90 day window. And keys can have no expiration date, so a cryptographic key created years ago is still valid today with no enforced point at which it must be rotated. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: a store of cryptographic material that is easier to destroy, or that stays valid longer, than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one vault-heavy subscription can fail several Key Vault checks at once. 'Key vaults should have purge protection enabled' and 'Key vaults should have soft delete enabled' both sit under the Microsoft Cloud Security Benchmark control DP-8 (back up and recover data), while 'Key Vault keys should have an expiration date' sits under DP-6 (use a secure key management process). They read as separate problems on the report, but they are one job: make sure the vaults you depend on can survive an accident or an insider, and that no key is allowed to live forever.

Most of this exposure is drift, not intent. A vault created before purge protection was considered, a key minted once and never given an expiry, a rotation policy that was never set. Since February 2025 Microsoft has made soft delete mandatory on every vault and it can no longer be disabled, so that recommendation is now satisfied by the platform. The remaining work is real: turn on purge protection so a recovery window cannot be cut short, and set an expiration date on every key so rotation is enforced rather than hoped for.

In this lesson you will learn how Azure Key Vault expresses recoverability and key lifetime, how to find every under-protected vault and every never-expiring key in a subscription, and how to harden them without breaking the workloads that depend on them. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The key that outlived the breach

Purge protection exists because of a specific failure mode: a soft-deleted vault can still be permanently purged inside its recovery window, by a disgruntled insider, a compromised account or an automation script that cleans up too aggressively, and once purged the keys are gone for good. If those keys encrypted a database, the data they protected becomes permanently unreadable. Microsoft made soft delete mandatory on all vaults in February 2025 precisely because accidental deletion was common, but purge protection, the setting that stops anyone cutting the recovery window short, is still opt-in. It is the one Key Vault setting that, once enabled, cannot be turned off again, by anyone, including Microsoft.

Finding Key Vault gaps across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows Key Vault findings spread across a dozen vaults in two subscriptions that pre-date the team's current guardrails.

Rather than work the findings one by one, Sam starts by listing which vaults still lack purge protection and which keys still have no expiration date, so the production vaults that protect real data can be separated from empty test vaults before anything changes.

Start by listing the vaults that still lack purge protection. These are the ones whose recovery window can be cut short.

$ az keyvault list --query "[].{name:name, softDelete:properties.enableSoftDelete, purge:properties.enablePurgeProtection}" -o table

Name SoftDelete Purge

---------------- ------------ -------

kv-payments-prod True

kv-test-sandbox True

# kv-payments-prod has soft delete on but purge protection unset. A purge inside the window wipes it. Fix first.

A production vault with soft delete on but purge protection unset is the highest-value target in this group: its keys can still be permanently destroyed inside the recovery window. Fix these first.

How Defender for Cloud decides a Key Vault is under-protecteddeep dive

Most Key Vault recommendations resolve to one of three properties. The first is 'enablePurgeProtection' on the vault: when it is unset, a soft-deleted vault can be permanently purged inside its recovery window, so the keys it holds can be destroyed for good before the window expires. The second is 'enableSoftDelete': it governs whether a deleted vault is recoverable at all for a configurable 7 to 90 day window, and since February 2025 Microsoft has made it mandatory on every vault and it can no longer be disabled, so that recommendation is now satisfied by the platform itself. The third is the 'expires' attribute on each key: when a key has no expiration date it is valid indefinitely, so there is no enforced point at which it must be rotated and a compromised key stays usable forever.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change itself is immediate, but the posture catches up on the next assessment. This matters when you are gathering audit evidence against a deadline. Note also that purge protection is the one Key Vault setting that, once enabled, cannot be reversed: enable it deliberately, because you cannot turn it off again afterwards.

The strongest position combines the vault and key settings with an Azure Policy backstop: a deny or audit policy on purge protection ('Key vaults should have deletion protection enabled') means no new vault can be created without it, and a policy on key expiration ('Key Vault keys should have an expiration date') flags any key that lacks one. Pair the expiry date on each key with a rotation policy ('az keyvault key rotation-policy update'), where the expiry time has a minimum of 28 days, so rotated keys are reissued with a fresh expiry automatically. Turning those on is the difference between checking that nothing is under-protected today and guaranteeing that nothing can be created under-protected tomorrow.

What is the impact of leaving Key Vault under-protected?

The direct impact is irreversible loss. A vault without purge protection can be permanently purged inside its recovery window, by a compromised account, a departing insider or an automation script that cleans up too aggressively, and once the keys are gone the data they encrypted is permanently unreadable. A key with no expiration date stays valid indefinitely, so a key that is quietly compromised can be used for as long as the attacker holds it, with no enforced rotation to cut the exposure short. The overwhelming majority of these incidents were not attacks but accidents: a vault deleted by a wrong-scoped cleanup, a key that nobody ever set to expire.

The second-order impact is blast radius. A Key Vault is a single point of failure for everything that trusts it: databases encrypted with its keys, services that authenticate with its secrets, sites that serve its certificates. Losing one vault can take down a whole dependency tree at once. Hardening the vault, making it unpurgeable and forcing keys to rotate, shrinks that risk to a recoverable, time-boxed event rather than a permanent loss.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that cryptographic material is recoverable and that keys are rotated on a defined lifetime. A passing set of Key Vault recommendations across every subscription, with purge protection on and every key carrying an expiration date, is among the cheapest and most defensible artefacts you can hand an auditor.

How do you harden Key Vault safely?

Work the capability as one loop rather than chasing individual findings. The order matters: enable purge protection deliberately, because it cannot be reversed, and pair every key expiry with a rotation policy so you do not break a live workload when a key lapses.

1. Inventory every vault and key by protection

List the vaults that lack purge protection and the keys that have no expiration date. Treat this inventory as the source of truth, not the Defender finding count, because one vault and its keys can trigger several recommendations at once. Soft delete is now mandatory and on everywhere, so that part is already satisfied.

2. Separate production vaults from test drift

Decide what each vault actually protects. A vault holding the encryption keys for a regulated database is a catastrophic-loss item; an empty test vault is drift. Prioritise the vaults whose keys protect real data, because losing those is the outcome you are insuring against.

3. Enable purge protection and set key expiry, highest impact first

Enable purge protection on the production vaults (remember it cannot be turned off again), then set an expiration date on every key that lacks one and attach a rotation policy so rotated keys are reissued with a fresh expiry. Sequence expiry carefully: a key must be rotated before it expires, or the workload that depends on it fails.

4. Ratchet it shut with Azure Policy

Assign deny or audit policies so no new vault can be created without purge protection ('Key vaults should have deletion protection enabled') and so any key without an expiration date is flagged ('Key Vault keys should have an expiration date'). This makes the safe configuration enforced rather than merely encouraged, so the next vault is born hardened.

# 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"

Quick quiz

Question 1 of 5

Defender for Cloud shows Key Vault findings across purge protection and key expiration on several vaults. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure Key Vault expresses recoverability and key lifetime across the settings in this capability.

You can now treat Key Vault data protection as one capability rather than a scatter of findings: inventory the vaults without purge protection and the keys without an expiration date, separate the production vaults from test drift, enable purge protection and set key expiry highest-impact first, and ratchet the estate shut with Azure Policy. Soft delete is already on everywhere by default. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Hardening Key Vault data protection: the cost and risk view

A near-zero-cost capability that removes a catastrophic single-point-of-failure class of loss

Key Vault protection is one of the cheapest controls to fix and one of the most expensive to get wrong. Enabling purge protection and setting expiration dates on keys costs nothing in Azure spend. The cost sits entirely in operational care: a key that expires must be rotated before it does, or the workload that depends on it fails, so the real expense is the engineering discipline to attach a rotation process to every expiry rather than any line on the bill.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A production vault holding the encryption keys for a regulated database, with purge protection off, carries a far higher expected loss than an empty test vault, yet both surface as a single red finding. Map the failures to what each vault actually protects and prioritise by blast radius, not by recommendation count.

The arithmetic is one-sided. The remediation is engineering time plus the standing discipline of key rotation. The downside of leaving it is the documented cost of a vault wiped by accident or by a departing insider: encrypted data that can no longer be decrypted, services that cannot authenticate, and a recovery effort measured in days of outage rather than minutes of configuration.

This lesson is for the finance partner who sees a cluster of Key Vault findings on the security report and wants to know what the right response is and what it costs. It covers why these controls are free to fix in Azure spend, why the real cost is the rotation discipline that expiry dates demand, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The key that outlived the breach

How a finance partner frames the Key Vault decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with nine Key Vault findings spread across a dozen vaults in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Enabling purge protection or setting an expiration date on a key changes nothing on the Azure bill, so the spend question is narrow: there is no incremental cost at all, only the standing operational discipline that every key with an expiry date must be rotated before it lapses or the workload that depends on it breaks.

Sam asks the team to map each failing vault to what it actually protects. Two vaults hold the encryption keys for regulated production databases and lack purge protection, one holds the TLS certificate for the public site, and the rest are empty or test vaults. The list is reframed on the risk register: the two production vaults are catastrophic-loss items to harden today at zero Azure cost, the certificate vault needs purge protection plus a rotation policy so the cert never silently lapses, and the test vaults are low-value drift to sweep up. The finance pack reads: 'Nine findings close at no incremental spend; the only standing cost is the rotation discipline that expiry dates demand; the thing standing between us and a clean posture is engineering process, not budget.'

Why Key Vault protection belongs on the risk register

The cost model here is asymmetric in a way that is rare for security work. Hardening Key Vault costs nothing in Azure spend, and leaving it under-protected creates a catastrophic tail risk. Each vault without purge protection is one where a future accident or insider could permanently destroy the keys, and while the probability per event is low, the probability across all vaults over years is not. The data those keys protect is only as recoverable as the vault itself.

The documented cost of losing a production vault includes days of outage while keys are reissued and data is re-encrypted, mandatory breach notification if a compromised key exposed data, and the possibility that some encrypted data is simply unrecoverable. Against that, the remediation is engineering time plus the standing discipline of key rotation, which costs nothing on the bill but demands that every expiry date is paired with a rotation process. The finance role is to attach expected loss to each failing vault so the work is prioritised by blast radius, not by the order the report lists it.

What finance can do about the Key Vault gap

Finance cannot enable a vault setting, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with no incremental Azure spend and one clear standing cost: the discipline of key rotation. Three levers.

1. Make explicit that the Azure-spend cost is zero

Be clear that enabling purge protection and setting expiration dates on keys does not move the Azure bill at all. There is no per-finding charge to forecast. The only standing cost is operational: every key given an expiry date needs a rotation process attached so it is renewed before it lapses. Budget that as engineering time and process, not as cloud spend, so nobody can claim the capability is a spending decision.

2. Order the work by blast radius, not by finding count

A vault holding the encryption keys for a regulated production database and an empty test vault both show up as a single red finding, but their expected loss differs by orders of magnitude: losing the first can mean permanently unreadable data, losing the second means nothing. Ask the team to map each failing vault to what it protects and harden the production vaults first. The metric that belongs on the cost-and-security review is the count of findings weighted by the criticality of what each vault protects, not the raw total.

3. Insist that every expiry date has a rotation process behind it

An expiration date with no rotation behind it is a future outage, not a control: the key will lapse and the workload will fail. Require that every key given an expiry is paired with a rotation policy and an owner, so the control reduces risk rather than scheduling an incident. The distinction between 'we set expiry dates and wired up rotation' and 'we set expiry dates and forgot to rotate' is exactly what separates a hardened estate from a self-inflicted outage.

Quick quiz

Question 1 of 5

A security report shows nine Key Vault findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure Key Vault expresses recoverability and key lifetime across the settings in this capability.

You have finished the finance view of hardening Key Vault. You know the cost model is one-sided: closing every finding is free in Azure spend, the only standing cost is the rotation discipline that expiry dates demand, and the downside of leaving a vault under-protected is the documented and largely irreversible cost of a purged vault: days of outage and data that may never be recovered. Next time a cluster of Key Vault findings lands, you will order them by blast radius, insist every expiry has a rotation process behind it, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Hardening Key Vault data protection: the headline

Whether the keys the whole estate trusts can be destroyed by accident, or left valid forever

Key Vault is the category of risk where one deletion or one stale key turns a small mistake into a wide outage. A vault without purge protection can be permanently wiped inside its recovery window, and a key with no expiration can stay valid for years with no enforced rotation. The report shows this as a scatter of separate findings across the estate.

The leadership question is not 'are we compliant today?' It is 'if someone deletes the wrong vault tomorrow, or a key is quietly compromised, can we recover and can we limit the damage?' The defensible end state is that purge protection is enforced by policy, soft delete is on everywhere (which it now is by default), and every key carries an expiration date so rotation is mandatory rather than optional.

None of this is a cost decision. Protecting Key Vault is essentially free in Azure terms. It is a governance decision about whether the estate's most critical secrets are protected by design or only by everyone remembering not to make a mistake.

A short read for the leader who needs to know what an under-protected Key Vault risks, why hardening it is a governance decision rather than a budget one, and what a defensible end state looks like across the estate.

Fun fact

The key that outlived the breach

What it looks like when Key Vault loss is prevented by design, not luck

After a peer company suffered days of outage when a departing engineer purged a production vault and the encryption keys it held were gone for good, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to enable purge protection, because recoverability across the estate was governed by habit rather than policy.

The team's response was to stop treating Key Vault as a per-vault cleanup and start treating it as a guardrail. They listed every vault without purge protection and every key without an expiration date, enabled purge protection on the production vaults, set expiry dates and rotation policies on the keys that lacked them, and then assigned an Azure Policy that denies the creation of any new vault without purge protection. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the platform prevents it by design: a vault cannot be purged inside its recovery window, and no key is allowed to live forever.' That shift, from relying on everyone remembering to harden a vault to making the loss structurally hard, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level risk

Nearly every catastrophic cloud key-loss event came back to the same root cause: a vault that could be permanently destroyed was, because of an accident or an insider, and the keys it held could not be recovered. Enabling purge protection is the capability that makes that root cause structurally impossible, and an Azure Policy backstop makes it impossible to create a new vault without it.

The cost of getting this wrong is large and well documented, an outage measured in days and data that may never be recovered, while the cost of fixing it is essentially engineering time and a rotation routine. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on Key Vault

The executive handle is not to approve each vault fix individually; it is to require that vault loss is prevented by policy, that purge protection is enforced and that every key has an enforced lifetime, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, the production vaults have purge protection on, every key carries an expiration date with a rotation policy behind it, and Azure Policy denies the creation of any new vault without deletion protection. A backstop that no new vault can be created without is the difference between checking nothing is under-protected today and guaranteeing nothing can be created under-protected tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of Key Vault recommendations across every subscription plus evidence that the deny policies are assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat purge protection as a deliberate, irreversible commitment

Purge protection is the one Key Vault setting that cannot be turned off once enabled, which is exactly why it is the right control to mandate: it removes the option to permanently destroy a vault inside its recovery window. The leadership requirement is simply that it is on for every vault that protects real data, accepted as a permanent commitment rather than a reversible toggle.

Quick quiz

Question 1 of 5

At a board review you ask whether a purged-vault incident like a competitor's could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure Key Vault expresses recoverability and key lifetime across the settings in this capability.

Two takeaways. Key Vault protection is the rare control where the risk of inaction is severe, an outage measured in days and possibly unrecoverable data, and the cost of action is essentially engineering time and a rotation routine, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and every vault was protected today'; it is Azure Policy that denies any vault without deletion protection and flags any key without an expiry, making accidental loss structurally hard, with purge protection accepted as a deliberate, permanent commitment.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Key Vault

Part of the learning path Encrypt across Azure

Harden Key Vault data protection

Hardening Key Vault data protection: the basics

The key that outlived the breach

Finding Key Vault gaps across a subscription

How Defender for Cloud decides a Key Vault is under-protecteddeep dive

What is the impact of leaving Key Vault under-protected?

How do you harden Key Vault safely?

1. Inventory every vault and key by protection

2. Separate production vaults from test drift

3. Enable purge protection and set key expiry, highest impact first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Hardening Key Vault data protection: the cost and risk view

The key that outlived the breach

How a finance partner frames the Key Vault decision

Why Key Vault protection belongs on the risk register

What finance can do about the Key Vault gap

1. Make explicit that the Azure-spend cost is zero

2. Order the work by blast radius, not by finding count

3. Insist that every expiry date has a rotation process behind it

Quick quiz

Keep learning

Hardening Key Vault data protection: the headline

The key that outlived the breach

What it looks like when Key Vault loss is prevented by design, not luck

Why this is a board-level risk

The leadership move on Key Vault

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat purge protection as a deliberate, irreversible commitment

Quick quiz

Keep learning

Controls this lesson covers

Key Vault

Related compliance lessons