Key Vault keys should have an expiration date

What does the recommendation "Key Vault keys should have an expiration date" check?

Flags any cryptographic key in a standard Key Vault that has no expiration date set, meaning its 'exp' attribute is empty and the key stays valid indefinitely. The recommendation and its backing policy ('Key Vault keys should have an expiration date', 152b15f7-8e1f-4c1f-ab71-8c010ba5dbc0) evaluate standard Key Vault keys (Microsoft.KeyVault/vaults/keys) only; Managed HSM keys are governed by a separate recommendation, '[Preview]: Azure Key Vault Managed HSM keys should have an expiration date' (1d478a74-21ba-4b9f-9d8f-8e6fced0eec5), which is currently in Preview. It covers the keys themselves but not secrets or certificates (those have their own controls), and it does not verify that you actually rotate a key before its expiry arrives. A key with a date far in the future still passes, so the control proves an expiry exists rather than that the lifetime is sensible.

Why does "Key Vault keys should have an expiration date" matter?

A key that never expires is one that never has to be rotated, so a single compromised or quietly leaked key can decrypt data and sign requests for years before anyone notices. The longer a key lives, the more ciphertext and signatures it accumulates, which widens the blast radius of any exposure and weakens your position against cryptanalysis. For regulated workloads an indefinite key lifetime is also an audit finding in its own right, since standards such as PCI DSS and the Azure Security Benchmark expect a defined cryptoperiod. The business consequence of skipping it is concrete: a stale key that should have been retired stays usable, and when it does leak you face a forced re-encryption of everything it protected, often under breach-notification deadlines. Setting an expiration date forces a deliberate rotation moment rather than leaving keys to drift unmanaged.

How do I fix "Key Vault keys should have an expiration date"?

1. Set an expiration date on each existing key: in the portal open the key version and fill in 'Set expiration date', or run 'az keyvault key set-attributes --vault-name <vault> --name <key> --expires <ISO 8601 datetime>'. Choose a cryptoperiod that matches the data's sensitivity rather than a default far-future date.
2. Turn on automated rotation so expiry never strands a workload: configure a rotation policy with 'az keyvault key rotation-policy update', which can rotate a key a set time before 'expiryTime' and emit a 'near expiry' Event Grid event you can alert on.
3. Make expiration the default for new keys in Bicep or Terraform by setting the key's 'attributes.exp' (Bicep) or 'expiration_date' (Terraform azurerm_key_vault_key), so freshly created keys arrive compliant instead of being fixed after the control fails.

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