Key Rotation Planner

Plan and track key rotation schedules

About Key Rotation Planner

Regular key rotation is a security best practice that limits the impact of key compromise. This planner tracks when each key was created, monitors its age, and suggests a rotation date. It is a local browser tool — nothing is sent anywhere — and the priority bands are a simple convention this page applies (overdue past 90 days, due soon past 60) rather than a NIST mandate, so adjust them to match your own policy.

How to Use

1Enter the domain name and the date the current key was created.
2Select the key type (RSA, ECDSA, or Ed25519) and enter the key size.
3Review the rotation schedule and prioritize keys that are due or overdue.

Use Cases

•Schedule regular key rotation across all your TLS endpoints
•Comply with NIST SP 800-57 key management guidelines
•Track key age for internal PKI and code signing certificates
•Coordinate rotation windows with maintenance and deployment cycles

Frequently Asked Questions

NIST recommends rotating asymmetric keys every 1-2 years, but for TLS certificates, rotating every 90 days is common practice, especially with Let's Encrypt's 90-day certificate validity.

Stale keys increase the risk of compromise. If a key is leaked or cracked, all past and future communications protected by that key are exposed. Regular rotation limits the damage window.

Yes, RSA keys generally require longer rotation intervals due to key generation cost, while ECDSA and Ed25519 keys can be rotated more frequently with less overhead.

Less urgently than it was, and the reason is worth understanding. For a public-facing certificate the key is public and proofs of work make factoring infeasible at any realistic size, so there is nothing to gain by rotating early. Rotation earns its place when the key has been exposed, when a policy requires it, or when certificates are long-lived and must-staple caps lifetime at far shorter intervals.

This page's own convention, not an external standard. An earlier version attributed them to NIST SP 800-57, which does not mandate those figures for TLS key rotation. What SP 800-57 does say is that cryptoperiods are context-dependent and should be bounded by the algorithm and key strength. Treat the bands as a starting convention and change them to match your own policy.

They are separate clocks measuring separate things. A certificate's lifetime is set by the authority and is now typically 90 days or less. A key's age is how long you have used it, and rotation policy for long-lived internal certificates is usually measured in months or years. Because certificates turn over far more often than keys, one key can sit behind many successive certificates.

The new key signs a fresh certificate, the certificate is deployed, and the old key is revoked once nothing depends on it. In automation the last step is the one to watch: a deploy hook that renames files and exits before the reload leaves a valid new certificate nowhere in the serving path, which looks like success and behaves like an outage.

Deliberately. The information needed is a domain and a date you hold, and computing a difference between them needs no backend. Keeping it client-side also means nothing about your key inventory leaves the tab, which matters when the list covers internal hosts. The consequence is that plans are not persisted — copy out anything you want to keep.

How the Schedule Is Worked Out

This page is a local browser tool. You give it a domain and the date its key was created, and it computes the key's age and suggests when to rotate — entirely in your session, with nothing sent to any server.

1Measure age from the creation date you enter, counted in whole days to today. Age is the input that matters: a recently rotated key is strong regardless of how weak its predecessor was.
2Band the age into a priority: over 90 days is overdue, over 60 is due soon, otherwise scheduled. Those thresholds are this page's convention, editable by changing them in view source — they are not a NIST requirement, and the earlier wording on this page wrongly attributed them to SP 800-57.
3Suggest the next rotation date as 90 days after the original creation, and record the key type and size you supplied alongside the plan. Work through the list from the top: every overdue key first, then due soon.

Plans accumulate in this page only — closing the tab clears them, so copy anything worth keeping. Key age and certificate expiry are different clocks: certificate lifetimes now run to 90 days or less while rotation policy is usually measured in months or years.

Tips & Best Practices

•Plan certificate rotation to minimize service disruption
•Use certificate rotation to limit exposure from key compromise
•Automate rotation processes for consistent execution
•Test rotation procedures regularly to ensure they work correctly

Technical Details

Planning: Certificate rotation scheduling and coordination
Automation: Automated rotation workflow and validation
Zero-downtime: Rotation without service interruption
Output: Rotation schedule with step-by-step procedures