Key Rotation Policy

What is a key rotation policy?

A key rotation policy is a defined schedule and process for regularly replacing cryptographic keys, secrets, and credentials with new ones. Rather than creating an encryption key, API key, or password once and using it indefinitely, a rotation policy mandates that keys be retired and replaced on a set cadence (and immediately upon suspected compromise). The security principle behind it is limiting the exposure window: if a key is ever compromised — leaked, stolen, or cracked — the damage is bounded to the period before the next rotation, rather than continuing indefinitely. A key that never changes is a key an attacker can use forever once they obtain it; a rotated key becomes useless to them after the next cycle.

Why rotate — the risk it manages

The value of rotation follows from how credentials get compromised in the real world: leaks are often silent and discovered late (a key exposed in a git commit, a log file, a breached third party, or an insider’s copy may be exploited for months before anyone notices), and cryptographic keys used heavily over long periods accumulate exposure. Regular rotation directly shrinks the attacker’s useful window and forces periodic re-establishment of trust. It’s also frequently a compliance requirement — standards like PCI-DSS, and many security frameworks, mandate documented key/credential rotation, so a rotation policy is often not optional. Rotation applies across many credential types, each with its own considerations: encryption keys (rotating the key used to encrypt data — often handled so new data uses the new key while old data is re-encrypted or remains decryptable via retained old key versions), API keys and secrets (like API keys, OAuth client secrets, database passwords), TLS certificates (which rotate via expiry/renewal), and signing keys (like the ones behind JWKS, where publishing multiple valid keys enables seamless rotation). Managed services make this far easier: AWS KMS, for instance, supports automatic annual rotation of encryption keys, and secrets managers (AWS Secrets Manager, HashiCorp Vault) can rotate database credentials and API keys automatically on a schedule.

The hard part: rotating without breaking things

The reason key rotation is a policy and not just “change the key sometimes” is that rotation is operationally tricky and, done naively, causes outages — which is exactly why so many organizations don’t rotate, leaving keys in place for years (the very problem rotation exists to solve). The core challenge is doing it without downtime: if you simply delete the old key and create a new one, everything still using the old key breaks the instant you switch. The correct approach uses overlapping validity — introduce the new key while the old one is still accepted, migrate all consumers to the new key, verify nothing is still using the old one, and only then retire it. This is why systems like JWKS publish multiple valid keys simultaneously (tokens signed by either verify during the transition), and why database-credential rotation stages the new credential before revoking the old. The other essential lesson: rotation must be automated to actually happen. Manual rotation is toilsome, error-prone, and reliably neglected — teams intend to rotate quarterly and then don’t, so the policy exists on paper while keys quietly age for years. Automating rotation (via KMS, Secrets Manager, cert-manager, ACME for certificates) is what turns a rotation policy from aspiration into reality, and it also handles the overlap/transition mechanics that make manual rotation risky. The recurring mistakes: not rotating at all (the most common failure — keys living indefinitely because rotation seems hard), rotating naively without overlap (causing outages, which then discourages future rotation), keeping the old key valid too long after transition (undermining the point), and relying on manual processes that inevitably lapse.

What people get wrong

• Not rotating at all — because rotation seems operationally risky, many keys live for years, which is precisely the indefinite-exposure problem rotation exists to prevent.
• Naive rotation without overlap: deleting the old key before consumers migrate causes outages — use overlapping validity (accept both keys during transition), as JWKS and secrets managers do.
• Manual processes — hand-rotation is toilsome and reliably neglected; automate rotation (KMS, Secrets Manager, ACME) so the policy actually executes and handles the transition safely.

Primary source: AWS KMS: Rotating keys