Cybersecurity glossary
What is Key Rotation?
Learn what key rotation is, how scheduled and emergency rotations differ, why dual-key decrypt windows matter, and how to rotate TLS certificates and JWT signing keys safely.
Definition
Key rotation is the controlled process of replacing cryptographic keys, certificates, or signing credentials with new ones while preserving availability, auditability, and the ability to decrypt or verify data created with older keys for as long as policy requires.
Why key rotation matters
Cryptographic keys age in two ways: time passes, and exposure risk accumulates. A key may be copied from a backup, overused by a busy service, handled by too many operators, embedded in an old image, or weakened by changing cryptographic guidance. Key rotation limits how much data, trust, and future access depends on one secret staying secret forever.
Good rotation is not just generating a replacement key. It is a lifecycle workflow that coordinates producers, consumers, audit logs, rollback plans, revocation, and old ciphertext that may still need to be read.
Common rotation triggers
Most organizations need both planned rotation and emergency rotation. Scheduled rotation keeps cryptoperiods bounded. Emergency rotation is the incident response path when a key may already be unsafe.
Scheduled rotation
Routine replacement based on cryptoperiods, compliance policy, usage volume, or planned algorithm upgrades.
Emergency rotation
Rapid replacement after suspected key exposure, unauthorized signing, leaked backups, vendor compromise, or operator mistakes.
Certificate rotation
TLS, mTLS, code-signing, and device certificates must be renewed, re-keyed, or revoked before expiry or after compromise.
Signing key rotation
JWT, webhook, package, and SSO signing keys require overlap so verifiers can trust old signatures until their validity window closes.
How a safe key rotation rollout works
A rotation succeeds when old and new trust states overlap deliberately instead of accidentally. Systems should know which key version produced each ciphertext, token, or signature so they can select the correct verification or decryption path.
Inventory key usage
Identify where the key is stored, who can use it, which services depend on it, what data or signatures reference it, and how clients discover trust changes.
Create the replacement
Generate or import the new key in a KMS, HSM, CA, or secrets platform with policy, ownership, tags, and audit logging already attached.
Publish trust metadata
Distribute the new certificate chain, JWKS entry, key version identifier, or configuration before switching writers and signers.
Switch new operations
Start encrypting, wrapping, signing, or serving TLS with the new key while retaining controlled read or verify access to the previous key.
Drain old dependencies
Let old JWTs expire, re-encrypt stored records, replace deployed certificates, clear caches, and confirm clients have accepted the new trust material.
Retire and record
Disable, revoke, archive, or destroy the old key according to policy, then preserve evidence of who approved and executed the rotation.
Dual-key decrypt windows
Encryption systems often need a transition period where the application writes with the new key but can still decrypt old data. That dual-key decrypt window should be explicit: old keys remain enabled only for reads, only for named workloads, and only until data is re-encrypted or reaches its retention limit.
Envelope encryption makes this easier. Data can be encrypted with data encryption keys, while a KMS or HSM rotates higher-level wrapping keys and tracks key versions. For high-risk events, teams may still need a full re-encryption campaign so old key material can no longer unlock sensitive records.
| Rotation case | Overlap needed | Safe retirement signal |
|---|---|---|
| Database or object encryption | New writes use the new key; old ciphertext remains readable by key version. | Records are re-encrypted, deleted, or beyond retention requirements. |
| TLS certificate and private key | New certificate is deployed while clients still trust the issuing chain. | Traffic confirms the new certificate is served everywhere and the old certificate is expired or revoked when needed. |
| JWT signing key | JWKS publishes old and new public keys while old tokens remain valid. | The maximum token lifetime plus cache TTL has elapsed. |
| CA or root trust material | Cross-signing, staged trust-store updates, or new intermediate rollout may be required. | Relying parties trust the new path and old issuance has stopped. |
Certificate and JWT key rotation
TLS certificate rotation is time-sensitive because certificates expire and clients validate names, chains, revocation state, and trusted issuers. Automation through ACME or private CA enrollment reduces outages, but operators still need inventory, renewal monitoring, private-key custody, and alerts for certificates served from forgotten load balancers or appliances.
JWT signing key rotation has a different failure mode: verifiers may cache public keys. A safe rollout publishes the new kid in JWKS first, signs new tokens with the replacement key second, and removes the old key only after every token it signed has expired plus cache skew. Emergency JWT rotation may also require revoking sessions or reducing token lifetime because old tokens can remain valid until verifiers stop trusting the old key.
Key rotation checklist
- Assign every key an owner, purpose, cryptoperiod, version identifier, and retirement rule.
- Automate scheduled rotation through KMS, HSM, CA, or deployment pipelines wherever possible.
- Keep old keys read-only or verify-only during overlap; do not allow them to produce new ciphertext or signatures.
- Design emergency rotation runbooks before compromise, including approvals, blast-radius analysis, revocation, and customer-facing impact.
- Log key creation, activation, use, policy changes, revocation, and destruction to tamper-resistant audit storage.
- Monitor certificate expiry, JWKS cache behavior, KMS errors, failed decrypts, and unexpected use of retired key versions.
- Test rotations in staging with realistic caches, token lifetimes, replicas, backups, and rollback procedures.
- After rotation, verify that old key material is disabled, revoked, archived, or destroyed according to data retention and compliance policy.
The practical takeaway
Key rotation is a reliability exercise as much as a cryptographic one. The safest programs rotate keys before they become emergencies, keep old keys available only for deliberate decrypt or verify windows, automate certificate and JWT rollovers, and leave enough evidence to prove what changed when the next audit or incident review asks.
Related security terms
Key Management Service (KMS)
A managed system for generating, storing, rotating, and auditing cryptographic keys.
Hardware Security Module (HSM)
Tamper-resistant key custody used for high-value root, wrapping, CA, and signing keys.
Encryption at Rest
Stored-data protection that often depends on careful key wrapping and rotation policy.
Certificate Authority (CA)
The issuer and trust framework behind TLS certificate lifecycle and replacement.
TLS 1.3
A modern TLS protocol version where certificate and private-key rotation protect endpoint identity.
Frequently asked questions
What is key rotation in simple terms?
Key rotation means replacing an old cryptographic key with a new one, updating systems to use the new key, and keeping old keys available only as long as needed for decryption, verification, rollback, or audit.
How often should encryption keys be rotated?
Rotation frequency depends on data sensitivity, cryptoperiod policy, compliance requirements, key usage volume, and operational risk. Many systems use scheduled rotation for routine hygiene and immediate rotation after suspected exposure.
What is emergency key rotation?
Emergency rotation is an accelerated replacement after a suspected compromise, employee offboarding incident, vendor breach, algorithm weakness, accidental exposure, or unauthorized use. It prioritizes containment, revocation, and evidence preservation.
Why do systems need a dual-key decrypt window?
During rotation, new writes should use the new key while reads may still need the previous key. A dual-key decrypt window prevents outages while data is gradually re-encrypted or expires naturally.
How is certificate rotation different from encryption key rotation?
Certificate rotation replaces an identity credential and often its private key before expiry or compromise. It must coordinate issuance, deployment, chain changes, revocation, monitoring, and client trust behavior.
How do you rotate JWT signing keys?
Publish the new public key in JWKS, start signing new tokens with the new private key, keep the old public key until issued tokens expire, then remove or disable the old key after the verification window closes.
Does rotating a KMS master key re-encrypt all data automatically?
Usually not. Many KMS designs rotate the wrapping key for future operations while existing data keys or ciphertext remain decryptable through key versions. Full data re-encryption is a separate migration.
References
Explore authoritative guidance and frameworks related to key rotation.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.