Your team has keys older than its last two hires. A Stripe secret that predates the rebrand. An AWS access key living in someone's .env from the prototype days. A SendGrid key with full send rights that three people know by heart. Nobody rotated them — not because anyone decided against it, but because nobody has ever shown them what rotation looks like when it doesn't break production.
So the keys become permanent, and the blast radius quietly grows: a key made for a weekend script now powers your invoicing. When that one leaks, it doesn't embarrass you — it mines crypto in your cloud account or emails your entire customer list.
The fix is a boring quarterly ritual with one iron rule: create the new key before you kill the old one, always. Sixty minutes a quarter. Here's the full checklist.
1. Build the key inventory (25 minutes, once)
Sweep the usual hiding places: password manager, the .env files people actually run, CI/CD secret stores, deploy-platform env vars, server configs, the shared Google Doc from year one. Then do the step everyone skips — open the API-keys page of every provider and list what exists there, not what you remember creating. Providers are ground truth; your inventory is the diff. Keys that appear only provider-side are the scary ones.
Record four fields per key: what it's for, where it's used, who owns it, scope. Scope is the field that turns a leak from catastrophe to shrug — a read-only analytics key that expires is a non-event.
2. Decide per key: rotate, shrink, or retire
Not every key deserves rotation:
- Retire keys with no confirmed use last quarter (check the provider's last-used timestamp, not memory). Zero downtime, zero migration, one less thing to leak. Highest-yield action in the whole ritual.
- Shrink keys whose scope exceeds the job. The invoicing cron that only reads invoices does not need write.
- Rotate everything that stays: older than 90 days, known to more than one person, or ever seen in a chat, ticket, screenshot, or commit — even one you "deleted." Git history is forever.
3. The no-downtime sequence (the part nobody teaches)
Rotations break production in exactly one way: the old key dies while something still uses it. The sequence makes that impossible:
- Create the new key, narrowest scope that works.
- Deploy it to every consumer on your inventory list — verifying each one (test call, dry run, health check) before moving to the next.
- Watch one cron cycle and one deploy. Then check the old key's last-used timestamp. A hit after you deployed? Something still uses it — find it now.
- Revoke the old key. Only now.
create → deploy → verify → revoke. Until the last step, both keys are live, so a missed consumer costs a log line instead of a Saturday.
4. The platforms that quietly hold half your keys
Small teams rotate the password manager and forget the deploy platform is made of keys: CI/CD secrets (GitHub Actions, GitLab variables), Vercel/Netlify/Railway env vars, the backup box's crontab. Search across projects for the old key's prefix — rotating one project while three others still hold the dead key is the classic follow-up outage. And if a key was ever baked into an image or build log, treat it as leaked: you can't un-bake a secret.
5. Kill the shared key while you're in there
Rotation day is the cheapest moment to fix key architecture: one key per consumer instead of one key per provider. A key everyone shares is a password written on the whiteboard — the audit question "who used this key?" currently answers "yes." Split shared keys into scoped per-system keys, relocate anything you found in Slack to the secret manager (the relocation stops the re-leak; rotation alone just resets the clock), and convert whatever you can to auto-expiring or identity-based auth — every key you delete from the problem class is a line removed from next quarter's checklist.
6. The rotation log
One file, appended quarterly: date, key by prefix (never the value), action, consumers updated, verification done, revocation confirmed. That last line is what auditors, incident retros, and your next enterprise buyer's security questionnaire all look for first: "All N provider keys reviewed Q3; M retired, K shrank, J rotated, 0 exceptions."
Make it survive
- Calendar: quarterly 60 minutes — sweep, provider diff, decisions, rotations, log.
- Event-driven, regardless of calendar: staff departure, a key seen in a chat or commit, vendor breach disclosure → rotate that day via your leak runbook.
- Pair it: the same ops morning that checks backup restores carries this.
The full checklist — including third-party/vendor keys you don't control, webhook signing secrets, and the seven common failure modes — is here:
API Key Rotation Checklist for Small Teams →
It pairs with the API Key Leak Response Runbook the same way backups pair with restore tests — and the day a key does leak, that runbook makes the first 30 minutes a checklist instead of a panic.
If you want the fillable versions: the free one-page First 30 Minutes incident quick-start, Ops Starter Kit — $14 (incident response for small teams), and Automation Starter Pack — $19. Launch code **HIVE-LAUNCH30* takes 30% off any paid kit.*
Top comments (0)