Secret Rotation Order Planner
A dozen secrets leaked at once. Which do you rotate first? List what was exposed and which secrets can reach which others, and get an ordered plan: most powerful and most reachable first, dependencies respected, with contain-or-rotate, what breaks, and a verify step after each — new credential verified before the old one is revoked.
For routine, scheduled rotation of a single credential type, use the Key Rotation Planner. For one leaked key with provider-specific steps, use Leaked Credential Response.
1 · What was exposed
2 · Rotation order
- 1Legacy AWS deploy user keyCloud root / admin access keyContain now, then rotate
- · Power 10/10: lets an attacker act as you or ship code to others.
- · It is public or already in the attacker's hands.
- · It can read or create Production database password — rotating those first would hand the attacker their new values.
- Contain: Disable the key now (for example set an access key Inactive — reversible) and, if abuse is active, attach an explicit deny-all policy to the principal.
- Create: Prefer replacing it with a role or workload identity that issues short-lived credentials. If a static key is unavoidable, create a second key with least privilege. A root account should have no access keys at all: delete, do not replace.
- Verify: Make a real authenticated call with the new credential from every consumer, then watch the cloud audit log for any further use of the old key ID.
- Revoke old: Delete the old key once every consumer is verified on the new one.
- Hunt: New users, access keys, roles, trust policies and resources created since exposure — in every region and account.
What breaks if rushed: Automation, scripts and CI jobs that use the key.
- 2CI bot personal access tokenCI/CD platform token or automation PATRotate — verify before revoke
- · Power 8/10: reaches production systems or data.
- · It is public or already in the attacker's hands.
- · It can read or create Payments webhook secret, Payments API key, Release signing key passphrase — rotating those first would hand the attacker their new values.
- Create: Create a new token with the minimum scopes and an expiry date, and update the pipelines or bots that use it. Prefer short-lived tokens issued per job.
- Verify: Run one pipeline end to end with the new token.
- Revoke old: Revoke the old token, then check the platform audit log for any use of it after revocation.
- Hunt: New runners, workflow changes, new secrets, webhooks, deploy keys or apps added since exposure.
What breaks if rushed: Pipelines, bots and integrations that authenticate with it.
- 3npm publish tokenPackage registry publish tokenContain now, then rotate
- · Power 9/10: lets an attacker act as you or ship code to others.
- · It is public or already in the attacker's hands.
- Contain: Revoke now. A publish token lets an attacker ship code to your users; a broken release pipeline is the lesser harm.
- Create: Move to trusted publishing (OIDC from CI) if the registry supports it; otherwise issue a new granular token scoped to the packages and the automation that need it.
- Verify: Run the publish step in dry-run mode or publish a pre-release from CI.
- Revoke old: Revoke the old token and confirm it no longer appears in the registry account.
- Hunt: Versions published since exposure, new maintainers or owners, changed package settings.
What breaks if rushed: The release pipeline, until the new token or trusted publishing is in place.
- 4Release signing key passphraseCode / artefact signing keyContain now, then rotate
- · Power 9/10: lets an attacker act as you or ship code to others.
- · It is public or already in the attacker's hands.
- · Comes after CI bot personal access token, which can read or create it.
- Contain: If anything malicious may have been signed, revoke the certificate (or publish a key revocation) now and tell consumers.
- Create: Generate a new key, ideally inside an HSM or managed signing service so it cannot be copied; re-sign current releases; publish the new public key or certificate through a channel the attacker does not control.
- Verify: Verify a newly signed artefact on a clean machine, and confirm the old certificate shows as revoked.
- Revoke old: Revoke the old certificate or key with the issuer, and remove the old key material everywhere it was stored.
- Hunt: Every artefact signed with the old key since exposure — list it and confirm it is yours.
What breaks if rushed: Verification on clients that pin the old key. Artefacts signed with a revoked certificate may stop installing on some platforms (timestamped signatures may keep working — check your platform).
- 5Production database passwordDatabase password / connection stringRotate — verify before revoke
- · Power 7/10: reaches production systems or data.
- · Comes after Legacy AWS deploy user key, which can read or create it.
- Create: Create a second database user with the same grants (or use dual-password support where the database has it), and switch applications to it one at a time.
- Verify: Application health checks pass and connection pools show only the new user.
- Revoke old: Drop or lock the old user, then check the database audit log for login attempts with it.
- Hunt: New database users, grants, triggers, scheduled jobs and functions; unusual bulk reads since exposure.
What breaks if rushed: Every application and job using the connection string. Changing the password in place drops all of them at once.
- 6Payments API keySaaS API key (payments, email, observability, AI)Rotate — verify before revoke
- · Power 5/10: reaches a supporting service.
- · Comes after CI bot personal access token, which can read or create it.
- Create: Use the provider's roll feature if it gives an overlap period; otherwise create a second key with the minimum permissions and switch to it.
- Verify: Make a real API call with the new key from production.
- Revoke old: Delete the old key and check the provider's logs for use after deletion.
- Hunt: New users, keys, webhooks, payout, sender or billing settings in the provider account.
What breaks if rushed: Integrations that call the provider.
- 7Payments webhook secretWebhook signing secretRotate — verify before revoke
- · Power 3/10: limited on its own.
- · Comes after CI bot personal access token, which can read or create it.
- Create: Generate a new secret at the sender; if it supports two active secrets, accept both during the switch; update the receiver.
- Verify: Send a test event and confirm the receiver validates it; confirm an event signed with the old secret is rejected.
- Revoke old: Remove the old secret at the sender and receiver.
- Hunt: Webhook endpoints added or changed at the sender; events you cannot match to real activity.
What breaks if rushed: Webhook verification — events are rejected, or worse, accepted unsigned if verification is lax.
What this tool does
- For incidents where many secrets leak at once — a malicious dependency in CI, a compromised runner, a leaked environment file.
- List each exposed secret by name and type, say how exposed it is, and mark which secrets can read or create others (a CI token that can read the database password, a cloud key that can read the secrets manager).
- The planner puts a secret that can reach another one first — otherwise the attacker simply reads the new value — then orders by power and exposure.
- Each step says whether to contain now or rotate with overlap, how to create the replacement, how to verify it, how to retire the old one, what to hunt for and what breaks if rushed.
- Copy the whole plan as a checkbox runbook. You never enter secret values.
Frequently asked questions
Why does order matter when rotating many secrets?
Two reasons. First, power: the credentials that let an attacker publish code, sign software or control your cloud account do the most harm per hour they stay valid, so they go first. Second, dependencies: if a CI token can read your database password, rotating the database password first just puts the new value where the attacker can still read it. Rotate the secret that can reach others before the secrets it reaches.
Should we revoke immediately or rotate with an overlap?
Revoke or disable immediately when there is evidence the secret is being abused, or when it is public and powerful enough that minutes matter (a publish token, a signing key, a cloud admin key). Use a reversible step where one exists — setting a key inactive, restricting network access — so you can recover if you break something. Otherwise rotate with an overlap: create the new credential, verify it works in every consumer, then revoke the old one.
How is this different from the Key Rotation Planner?
The Key Rotation Planner is for routine rotation: per-credential runbooks and a sensible cadence for keeping secrets fresh. This planner is for an incident: many secrets exposed at once, some possibly abused, and the question of which to rotate first and which depend on others. Use this one during the incident and the Key Rotation Planner to set up the rotation habits afterwards.
What about short-lived CI job tokens and OIDC credentials?
Tokens that expire at the end of a job have usually expired by the time you find out, so they rarely need rotating. What matters is the trust that issues them: a cloud OIDC trust policy that accepts any branch or any repository lets an attacker mint fresh credentials. Fix the trust policy as part of the plan.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.