Secret expiry dates are a feature, not a chore

While building secret rotation tooling for a client’s Azure environment, I ran into a platform policy that denies creating any Key Vault secret with an expiry more than 180 days out. My first reaction was mild annoyance: the rotation script now had to cap every expiry it set. My second reaction, after living with it for a while, was that every organisation should do this.

The problem with secrets that never expire

A secret without an expiry date is a secret with an unknown blast radius. It might be five years old, shared across three services, copied into someone’s local env file, and known to people who left the team long ago. Nothing in the vault tells you any of that. Expiry dates turn “we should rotate these someday” into a deadline the platform actually tracks.

Order matters: alerting before enforcement

The tempting first step is to slap expiry dates on everything. Do not start there. If secrets can expire before anyone notices, you have converted a security risk into an availability risk. So the sequence I landed on:

1. Alerting first. Wire up notifications well before expiry (Key Vault emits near-expiry events; a scheduled job querying secret attributes works too). Rotation should never be a surprise.
2. Real expiry dates next. Set honest dates on existing secrets and rotate before they hit. My rotation script defaults every new version to the maximum the policy allows, so nothing is created exempt.
3. Enforcement last. Once the muscle memory exists, add a policy at the org or management-group level: expiry is mandatory, and it cannot exceed a maximum validity. In Azure this is a built-in policy definition with a deny effect. Now nobody can opt out, including future you.

The unexpected win: finding dead secrets

The part I did not anticipate is that mandatory rotation doubles as a usage audit. When a secret comes up for rotation and you ask “what consumes this?”, sometimes the answer is nothing. The service was decommissioned, the integration was replaced, and the secret just sat there as attack surface.

Without expiry dates those secrets live forever. With enforcement, every secret gets looked at on a fixed cadence, and the ones nobody claims get deleted instead of rotated. Less attack surface, a cleaner vault, and in a few cases it flagged whole resources that were still running for no reason, which is money back.

Takeaway

Expiry enforcement feels like bureaucracy until you realise what it buys: a hard upper bound on how long a leaked credential works, a forced periodic review of every secret you own, and a built-in detector for the ones you no longer need. Set up the alerts first, then the dates, then the policy. In that order it is nearly painless.