Key rotation: what it is and how often to rotate keys
What goes wrong without key rotation, how often NIST suggests rotating, why rotation isn't re-encryption, the special case of video keys, and what to ask.
On this page 8 sections
Key rotation means replacing a cryptographic key with a new one, on a schedule or after an event such as a staff exit or a suspected leak, so that any one key protects a limited amount of data for a limited time. How often depends on the key: NIST suggests most symmetric keys be used for under two years, public TLS certificates are moving to 47-day lifetimes by 2029, and any key you believe is exposed should be replaced at once. In practice, the bigger danger is rarely the interval on paper; it's keys that never change, sit in code or leave with former staff.
What goes wrong without key rotation
- Leaked keys stay useful forever. A key copied from a laptop, a log file or an old backup works for as long as it's in use. Without rotation, that can mean years.
- Former staff and vendors keep access. An administrator or agency that once handled a key still knows it after they leave, unless it changes.
- Keys end up in the wrong places. Keys hard-coded in apps, committed to code repositories or pasted into chat are common, and every place a key has been is a place it can leak from.
- Some keys wear out. When AES-GCM is used with random nonces, NIST's SP 800-38D caps one key at 2^32 encryptions, so busy systems can hit a limit long before any calendar deadline.
- Rotation that's never practised breaks things. A team forced to rotate for the first time during an incident discovers every place the old key was hard-coded, often by taking something down.
- One key covering everything. The more a single key protects, the more one leak exposes.
How often to rotate keys
NIST's key management guidance, SP 800-57 Part 1, calls the period a key may be used its cryptoperiod. A well-chosen one limits how much data an attacker can study, how much damage a single compromise does, and how long anyone has to steal the key. NIST also lists staff turnover among the reasons to keep cryptoperiods short. Its suggested outer limits, alongside the events that should trigger rotation sooner:
| Key | Suggested outer limit | Rotate immediately when |
|---|---|---|
| Keys that encrypt data | NIST: under two years of use; as short as a day or a week when large volumes are encrypted quickly | The key is exposed, or a usage limit approaches |
| Master keys that protect other keys | NIST: under two years of use | Anyone with access leaves, or misuse is suspected |
| Secret keys that sign or authenticate, such as URL-signing secrets | NIST: under two years | The secret appears in code, logs or a former vendor's systems |
| Private signing keys, such as those behind login tokens | NIST: one to three years | Any suspicion of exposure |
| Public TLS certificates | CA/Browser Forum rules: falling to 47 days by 2029 | The private key is exposed |
Treat these as ceilings, not targets. Under CA/Browser Forum ballot SC-081, the maximum lifetime of public TLS certificates falls in steps from 398 days to 47 days between March 2026 and March 2029, which makes manual renewal impractical; see our guide to public key infrastructure.
Rotation isn't re-encryption
Rotating a key usually means new data gets the new key while old data stays as it was. AWS says so plainly in its key management documentation: rotation doesn't re-encrypt data the key protects, and it won't mitigate a compromised data key. NIST makes the same point from the other side: data encrypted under a key needs that key until the data is re-encrypted or destroyed.
So scheduled rotation limits the future, while a leak needs a different response: stop using the exposed key, re-encrypt what it protected and find out how it leaked. Many systems keep this manageable with envelope encryption, a common design in which data keys are themselves encrypted under a master key, so rotating the master key doesn't mean touching every file; our guide to envelope encryption and KMS explains the idea.
The special case of video keys
Video keys expose the gap between rotation and re-encryption more sharply than most. A key that decrypts recorded lectures is shared by every student who watches them, and if it's captured once, every lecture it covers can be decrypted, for good. Rotating afterwards protects future uploads only; the lectures already protected by that key stay exposed until they're encrypted again, which for a large library is slow and costly. That's why how much each key covers matters as much as how often keys change. Live classes are different, because a stream can switch keys while it's running. Our guide to HLS encryption explains why video keys are so exposed in the first place.
Signing keys and tokens
Keys that sign things, such as expiring video links or login tokens, have a rotation problem of their own: everything signed with the old key stays valid until it expires. Rotating abruptly logs students out or breaks playback mid-lecture; not rotating at all leaves a leaked signing key able to create valid links or logins indefinitely. Standards help here. RFC 7517 describes using key IDs to choose among keys in a published key set during key rollover, so old and new keys can overlap. Our guides to signed URLs and JWTs and sessions cover how those credentials get abused.
What to ask your tech team or vendor
- Do we have a list of every key and secret we rely on, where each is stored and who can reach it?
- Are any keys hard-coded in apps, code repositories or configuration files?
- When did each key last change, and what triggers a change: a schedule, a staff exit, a suspected leak?
- Can keys be rotated without logging students out or interrupting live classes?
- If a key leaked tomorrow, what data would need re-encrypting, and how long would that take?
- How much does each video key protect: one lecture, one course or the whole library?
- Are certificate renewals automated, given shrinking lifetimes?
Rotation is one part of the wider key life cycle, from generation to destruction, covered in our guide to encryption key management.
Key takeaways
- Rotation limits how much data one key protects and for how long.
- NIST's cryptoperiods are ceilings; staff exits and suspected leaks should trigger rotation at once.
- Rotation doesn't re-encrypt old data, so a leaked key needs re-encryption as well.
- A captured video key exposes everything it covers, which makes key scope as important as timing.
- Signing keys need overlap during rotation, or students get logged out and links break.
Frequently asked questions
What is key rotation?
Key rotation is the practice of retiring a cryptographic key and replacing it with a new one, either on a schedule or after an event such as a suspected leak or a staff departure. New data or signatures use the new key, while the old key is kept only as long as needed to decrypt or verify what it already protected, then destroyed.
What is key rotation in encryption?
In encryption, key rotation means new data is encrypted under a new key while older data stays readable with the old one. Key management services keep previous key versions for that reason. Rotation doesn't re-encrypt existing data, so if a key is actually compromised, the data it protected must also be re-encrypted under a new key to be safe again.
What is key rotation in JWT?
It's replacing the key used to sign JSON Web Tokens without breaking logins. Issuers publish their public keys in a key set, each with a key ID, and every token names the key that signed it. A new key is published before it's used, and the old one stays available until every token it signed has expired.