Key Rotation Planner
Pick the credential types in your stack and get a per-type rotation runbook that enforces the one safe order — generate, verify, deploy, monitor, then revoke — plus a recommended cadence and zero-downtime overlap notes. Output is a tracked checklist and a copyable runbook. Everything runs in your browser; nothing is uploaded.
- 1. GenerateCreate the new credential alongside the old one — never replace it in place.
- 2. VerifyMake a real authenticated call with the new credential and confirm it works.
- 3. DeployUpdate every consumer to the new credential, then restart / redeploy.
- 4. MonitorWatch for errors and confirm the old credential is no longer in use.
- 5. RevokeOnly now, disable (reversibly) and then delete the old credential.
Never generate-and-revoke in one step. A rotation you cannot verify before the old credential dies is a lockout.
What this tool is
- A free, in-browser planner: select the credential types in your stack and get a per-type rotation runbook that enforces one safe order and a recommended cadence.
- The safe order is always the same five steps: (1) generate the new credential, (2) verify it with a real authenticated call, (3) deploy it to every consumer, (4) monitor for errors, (5) only then revoke the old one.
- Never generate-and-revoke in one step. A rotation you cannot verify before the old credential dies is a lockout — recovering from one can cost a full day.
- Covers AWS access keys, database passwords, third-party API keys, TLS/SSL certificates, SSH keys, OAuth client secrets, JWT/token signing keys, and cloud service-account keys, with zero-downtime overlap notes where the platform supports two active credentials.
- Output is a tracked checklist you can tick off plus a plain-text runbook you can copy or download. Everything runs client-side — nothing is sent anywhere.
Why rotation order is the whole game
Rotating a secret sounds like a single action, but it is a sequence — and doing the steps out of order is how a routine maintenance task turns into an outage. The failure mode that bites teams again and again is generate-and-revoke in one step: you mint a new key, immediately kill the old one, and only then discover the replacement was never verified. A typo in a secret store, a consumer you forgot, a cached copy, or a new key with the wrong scopes is now unrecoverable, because the credential you would need to fix it is already dead.
The fix is to keep the old credential alive as a safety net until the new one is proven. That is the entire reason the five-step order exists.
The safe order, every time
- 1. Generate the new credential — alongside the old one, never replacing it in place.
- 2. Verify it with a real authenticated call. Prove the new credential actually works and has the scopes it needs before you rely on it.
- 3. Deploy the new credential to every consumer — apps, CI, secret stores, config — and restart or redeploy so running processes pick it up.
- 4. Monitor for errors and confirm the old credential has stopped being used — auth-failure spikes and usage logs tell you whether anything was missed.
- 5. Revoke the old credential — and only now. Where you can, disable it first (reversible) before deleting, so a surprise is still recoverable.
Overlap beats a hard cutover
Most platforms let two credentials be valid at once, and that overlap is what makes a zero-downtime rotation possible. AWS IAM allows two active access keys per user. SSH authorized_keys holds many keys. A JWKS can publish both the old and new public keys so already-issued tokens keep validating until they expire. Many identity providers allow two OAuth client secrets, and cloud service accounts usually allow multiple keys. The planner calls out where overlap is available per type — use it instead of flipping a single value in place.
The one rule to keep: never do step 1 and step 5 together. Generate the new credential and verify it before the old one dies. A rotation you cannot verify before the old credential is revoked is a lockout with extra steps — and the recovery, when SSH and a web console are both unreachable, can cost a full day. This planner gives general guidance, not professional advice; always follow your provider's current rotation documentation for exact commands.
Frequently asked questions
What is the safe order for rotating a credential?
Always: (1) generate the new credential, (2) verify it works by making a real authenticated call with it, (3) deploy or update every consumer to use the new credential, (4) monitor for errors to confirm nothing is still using the old one, and (5) only then revoke or delete the old credential. The critical rule is that you never generate the new credential and revoke the old one in the same step. If you revoke before you have proven the replacement works and is in use everywhere, a single mistake — a typo in a secret, a service you forgot, a cached copy — becomes a lockout with no way back in. A rotation you cannot verify before the old credential dies is just an outage with extra steps.
How often should I rotate keys and secrets?
Cadence depends on the credential and your risk, and you should follow your provider’s current guidance, but common starting points are: long-lived cloud access keys and service-account keys roughly every 90 days; database passwords every 90 days or immediately on staff departure or suspected exposure; third-party API keys every 90 days or per the provider’s policy; OAuth client secrets every 6 to 12 months; JWT signing keys around every 90 days with overlapping key IDs; SSH keys at least annually and immediately when an operator leaves; and TLS certificates well before expiry (ACME-issued certificates renew automatically, often on a 60 to 90 day cycle). The most important rotations are not scheduled at all — rotate immediately on any suspected compromise.
How do I rotate credentials with zero downtime?
Use the platform’s support for more than one active credential so the old and new overlap. AWS IAM allows two active access keys per user, so you create the second, cut everything over, then delete the first. SSH authorized_keys holds many keys at once, so you add the new public key everywhere and prove login before removing the old. A JWKS can publish both the old and new public keys, so tokens already signed under the old key still validate until they expire. Many identity providers allow two client secrets, and most cloud service accounts allow multiple keys. For TLS, the new certificate and its full chain must be trusted and serving before you retire the old one — never let the old certificate expire before the new one is live.
Why not just generate a new key and delete the old one at the same time?
Because you lose your only safety net. Between generating and deleting there are several ways to get locked out: the new credential might have the wrong scopes or permissions, a consumer might not have picked it up yet, a secret store or CI variable might still hold the old value, or the new value might have been copied with a transcription error. If the old credential is already gone when any of those surfaces, you have no working credential and often no way to authenticate the very action you would need to fix it. Keeping the old credential alive until the new one is verified and fully deployed means every failure mode is recoverable by simply continuing to use the old credential while you investigate.
Is anything I enter sent to a server?
No. The Key Rotation Planner runs entirely in your browser. It only reads which credential types you select and assembles a runbook from built-in templates — it makes no network calls, so nothing you choose or type leaves your machine. The generated runbook is general guidance to help you plan a safe rotation; it is not professional advice, and you should always follow your provider’s current, authoritative rotation documentation for the exact commands and options.