Validity period of certificates stored in Azure Key Vault should not exceed 12 months

What does the recommendation "Validity period of certificates stored in Azure Key Vault should not exceed 12 months" check?

Flags any certificate object in a standard Azure Key Vault whose issuance policy sets a validity period longer than 12 months, evaluated through the built-in policy 'Certificates should have the specified maximum validity period' with its 'validityInMonths' parameter. It reads the 'validity_months' value in each certificate's x509 properties, so it judges the lifetime the vault will issue or renew to, not the time left until the current certificate expires. It does not inspect TLS certificates held outside Key Vault, does not cover keys or secrets (those have their own validity policies), and does not apply to certificates in a Managed HSM, which uses a separate control surface.

Why does "Validity period of certificates stored in Azure Key Vault should not exceed 12 months" matter?

A certificate's private key is a long-lived credential, and the longer it is valid the longer a quietly stolen copy keeps working. Multi-year certificates also mean revocation and rotation muscles atrophy: teams forget how to reissue, so when a compromise or a forced public-CA revocation lands they scramble and risk a customer-facing outage. Capping validity at 12 months forces regular automated rotation, shrinks the window any single leaked key is useful, and keeps the renewal path exercised so an emergency swap is routine rather than an incident. It also keeps you aligned with public CA and browser rules that already refuse to issue longer-lived publicly trusted certificates.

How do I fix "Validity period of certificates stored in Azure Key Vault should not exceed 12 months"?

1. Recreate or update the certificate with a compliant issuance policy: in az CLI, build a policy where x509_props.validity_months is 12 or less and apply it with 'az keyvault certificate create --vault-name <vault> --name <cert> --policy @policy.json', or in the portal open the certificate, edit its Issuance Policy and set Validity Period (in months) to 12.
2. Enable certificate auto-rotation so the shorter lifetime is sustainable: set the certificate's lifetime action to AutoRenew (for example 'az keyvault certificate set-attributes' with a policy whose lifetime_actions trigger renewal at a percentage of the validity), which makes a 12-month cap operationally invisible.
3. Assign the built-in policy to stop new long-lived certificates being created, looking the definition up by display name rather than hardcoding a GUID: pid=$(az policy definition list --query "[?displayName=='Certificates should have the specified maximum validity period'].name" -o tsv); az policy assignment create --name cert-max-validity --policy "$pid" --scope <scope> --params '{"maximumValidityInMonths":{"value":12},"effect":{"value":"Deny"}}'. Run it as Audit first, confirm the impact, then move to Deny.

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