Secrets Rotation Checklist for Small Teams

"Rotate your secrets" is advice that sounds responsible and is usually done wrong: either everything is rotated on a calendar nobody keeps, or nothing is rotated because the blast radius scares everyone. The honest version is smaller and sharper: inventory where credentials live, rotate on real triggers, prefer short-lived tokens over long-lived ones, and pre-stage the rotation nobody wants to do — the one that locks people out.

1. Inventory first (you cannot rotate what you cannot name)

Where secrets hide	How to find them	Owner
CI/CD variables	Export the secrets list from each pipeline config; screenshot-or-text it into one file	Whoever owns deploys
Cloud consoles	One screen per provider: keys, tokens, service accounts	Same
Shared password manager	Export the item list (names only, not the values)	Owner + one other
Config files & .env copies	`grep -r` for known prefixes (sk_, AKIA, ghp_) across repos	Lead engineer
People's laptops	Ask, in writing: "what tokens do you hold that nobody else can revoke?"	Everyone, 15 minutes

The grep pass is the one that finds the surprise. It almost always finds one: a production key in a repo nobody remembered, a backup of the .env in a support agent's downloads folder. That finding justifies the whole exercise.

2. Rotate on triggers, not a calendar

Calendar rotation (every 90 days, whether or not anything happened) mostly produces fatigue and copy-pasted "new" passwords. Real triggers:

A person leaves — rotate every credential they could reach. This is the only trigger with no exceptions.
A key appears somewhere it shouldn't — a repo, a screenshot, a support ticket, a chat message. Rotate immediately, and treat "we deleted the message" as rotation theater.
A vendor has an incident — if your vendor's keys were exposed, yours live in their blast radius.
A credential is older than a year with no short-lived replacement available — rotate it once and spend the savings on making the next one short-lived.

3. Prefer dying credentials over rotated ones

The best rotation is the one you never run. Where a provider offers it:

Instead of	Use	Why it wins
Long-lived API keys	OIDC / workload identity federation from CI	Nothing to leak — the trust is role-based, not a string
Static DB passwords	Short-lived certificates or IAM auth	A stolen token expires before it's useful
Personal access tokens in scripts	Machine-scoped tokens, least privilege, expiry set	Blast radius is one job, not one human
Root/everything accounts in daily use	Scoped accounts + break-glass root, MFA'd, envelope-sealed	Rotation of the root account becomes rare and deliberate

Every long-lived credential you replace with a short-lived one permanently removes a rotation from the calendar.

4. The rotation nobody wants (pre-stage it)

Rotating the credential that everything uses — the deploy key, the main DB password — is feared for a good reason: done carelessly it is a self-inflicted outage. Make it boring in advance:

Verify the provider supports two live credentials (add-new before remove-old). Most do.
Write the cutover as exact steps: add new → update the one place it's read from → verify the smoke path → revoke old → verify again.
Decide the timing: inside business hours with everyone awake, never before a weekend.
Write the rollback: re-enable the old credential, fix whatever the new one broke. If rollback is impossible, the rotation plan isn't ready.

5. The checklist

Control	Effort	Done looks like
Secrets inventory, one file	2 hrs	Every credential has a name, location, owner
Repo grep for leaked prefixes	30 min	Zero hits, or hits rotated + purged from history
Trigger list written down	30 min	Departure / leak / vendor-incident rotate-now rule in the runbook
Short-lived tokens for CI	half a day	CI has no static cloud keys left
Dual-credential cutover plan	1 hr	The scary rotation has a written, reversible script
Leak-response mini-runbook	1 hr	"Key exposed" page: revoke, rotate, audit, postmortem — in that order

The three rules that make the checklist work

Rotate on evidence, expire on a timer. A credential that dies on its own schedule never needs an emergency rotation; a calendar rotation nobody believes in just trains people to ignore the policy.
The departure rotation is the sacred one. Calendar rotation can slip a quarter. "We'll rotate after Sam's last day" is how former employees keep production access. It rotates same-day, every time.
A leaked key is burned, not deleted. Delete the commit, then still rotate: copies exist in clones, caches, and forks you will never find. Rotation is cheap compared to assuming nobody saw it.

---

The Ops Starter Kit ($14) covers the incident side of a leaked credential — what to do in the first 30 minutes while the key is still live — and Vol. 2 ($27) adds the DR plan and evidence log for the audit after. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout (ends Sep 11, 23:30 ACST).