Key rotation
Replacing credentials in a controlled overlap, moving traffic to the new key, then revoking the old one before a leak can stay useful.
See it
What it is
Key rotation replaces a credential or cryptographic key with a new one, moves new work to it, then retires the old one. The overlap matters: JWT verifiers may need both public keys while old tokens expire, and an API client may need both credentials during a rolling deploy. A key ID such as JWT's `kid` tells readers which key produced a value.
Rotate immediately after suspected exposure, employee or vendor access changes, and algorithm or policy changes. Scheduled rotation limits how long an unnoticed leak remains useful, but only if the process is automated and rehearsed. The safe sequence is create, distribute, make active, observe, disable, then delete after the recovery window.
Replacement is not revocation. Creating a new key does nothing while the old one still works everywhere. Cutting the old one off too early causes an outage; leaving it enabled forever preserves the breach. Encryption keys add another wrinkle: old data still needs its old key unless it is re-encrypted or protected with envelope encryption, where a smaller wrapping key can be rotated.
Ask AI for it
Implement zero-downtime key rotation for this service with AWS Secrets Manager. Give each version an identifier, read `AWSCURRENT` for new operations, accept `AWSPREVIOUS` only during a bounded grace period, and cache neither version longer than five minutes. For JWT signing, publish both public keys in JWKS with distinct `kid` values, sign only with the new key, and remove the old key after the longest token lifetime. Automate create, distribute, activate, verify, disable, and delete steps; add a rollback before deletion; alert on any use of the old key after cutover; and write a test that rotates during live requests without failed authentication or duplicate work.