A support agent's laptop had a copy of the production .env. Not hacked — copied, to "test something" four months ago. Nobody rotated anything, because "rotate your secrets" sounds like a quarterly calendar task and the calendar said January.
The scary part wasn't the copy. It was that nobody could list which credentials were even in that file. You cannot rotate what you cannot name.
I keep a running file of small-team incidents, and this shape — long-lived keys, unknown inventory, rotation fear — is the default state of most five-person teams. Here's the checklist we'd hand them instead of the calendar. It's shorter and it actually gets done.
Step one is the grep pass
Before any rotation policy, run the inventory: CI variables, cloud consoles, the password manager's item list (names only), and then the pass that always finds something — grep -r your repos for known key prefixes (sk_, AKIA, ghp_). The surprise finding justifies the whole exercise. If your inventory fits on one page, good. That page is the policy.
Rotate on triggers, not on a calendar
Calendar rotation produces fatigue and copy-pasted "new" passwords. Real triggers rotate now, no exceptions:
- A person leaves. The sacred one. "We'll rotate after Sam's last day" is how former employees keep production access. Same day, every time.
- A key appears somewhere it shouldn't. A repo, a screenshot, a ticket. And no — deleting the message is rotation theater. Clones, caches and forks keep copies you'll never find. A leaked key is burned, not deleted.
- A vendor has an incident. Your keys live inside their blast radius.
- A key is older than a year with no short-lived replacement — rotate once, then fix the design.
The best rotation is the one you never run
Every long-lived credential you replace with a short-lived one permanently removes a rotation from the calendar:
| Instead of | Use |
|---|---|
| Long-lived API keys in CI | OIDC / workload identity federation |
| Static DB passwords | Short-lived certs or IAM auth |
| Personal tokens in scripts | Machine-scoped, least-privilege, expiring tokens |
| Root account in daily use | Scoped accounts + sealed break-glass root |
The rotation nobody wants: pre-stage it
Rotating the deploy key or the main DB password is feared for a good reason — done carelessly it's a self-inflicted outage. Make it boring in advance: confirm the provider supports two live credentials (add new before remove old), write the cutover as exact steps, do it mid-morning with everyone awake, and write the rollback before you need it. If rollback is impossible, the rotation isn't ready.
The full one-page version — the inventory table, the trigger list, and the scorecard with effort estimates — lives on the ops notes:
📄 Secrets Rotation Checklist for Small Teams (Rotate What Leaks, Not Everything) — free, no signup.
If you want the incident side drilled — what to do in the first 30 minutes while the leaked key is still live — the Ops Starter Kit ($14) covers it, 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.
A free companion: The First 30 Minutes — the one-page incident quick-start checklist.
More free checklists — server hardening, offboarding, ransomware recovery — at HIVE80lab Ops Notes.
Top comments (0)