secrets rotation schedule for a small team

secrets rotation schedule for a small team

TL;DR

Write down every secret, rank it by blast radius, and give each tier a rotation cadence: critical every 30 to 90 days, standard every 6 months, low-risk yearly. Assign one owner per secret and verify rotation happened instead of assuming it. The schedule lives in a doc the whole team can see, not in anyones head.

secrets rotation schedule for a small team

Use this when

• An auditor asked "how often do you rotate secrets" and you had no answer
• You are setting up secrets hygiene from scratch
• A teammate left and you realized nobody knows what they had access to
• You want rotation to be boring and routine instead of a fire drill

Not for this skill when

• A secret just leaked (revoke it now, that is a different skill)
• You are choosing a secrets manager (do that first, then write the schedule)
• You need the mechanics of rotating one specific key (look up that service)

Steps

1. List every secret and its owner

Inventory first. Check the secrets manager, CI settings, cloud consoles, and that one doc where the wifi password lives. Every secret gets one named owner.

printf '%s\n' "stripe live key | billing svc | priya" "db prod password | api svc | marcus" "deploy key | ci | jules" | tee secrets-inventory.txt

Expected: a plain list with a name, where it is used, and who owns it. If a secret has no owner, the team lead owns it until someone volunteers.

2. Tier them by blast radius

Not all secrets deserve the same cadence. Three tiers is enough for a small team.

echo "tier 1 - rotate every 30 to 90 days: prod database passwords, payment keys, cloud admin keys"
echo "tier 2 - rotate every 6 months: CI deploy keys, third-party API keys, signing keys"
echo "tier 3 - rotate yearly or on personnel change: staging creds, read-only analytics keys"

Expected: every secret from step 1 sits in exactly one tier. When in doubt, tier up.

3. Put rotation dates on a shared calendar

Rotation that is not scheduled does not happen. Create recurring events with the secret name and owner, and have the owner confirm completion in the event.

echo "next rotation: stripe live key | 90 days from today | owner: priya" | tee -a rotation-calendar.txt

Expected: a file or calendar with dates in the future, each tied to an owner. Review it in a weekly standup until the habit sticks.

4. Rotate using the two-secret overlap method

For anything serving traffic, create the new secret first, deploy it alongside the old one, then revoke the old. No downtime, no 3am pages.

echo "1. create new key in provider console"
echo "2. add it next to the old one in the secrets manager"
echo "3. deploy and watch error rates for 15 minutes"
echo "4. revoke the old key"

Expected: the service runs on the new secret while the old one still works as a fallback, then the old one is revoked. If step 3 looks bad, roll back to the old secret instantly.

5. Verify and record

After rotation, confirm the old secret is dead (a test call should fail) and log the date. Unverified rotation is just vibes.

echo "stripe live key | rotated today | old key revoked | verified dead" | tee -a rotation-log.txt

Expected: one log line per rotation with a verification note. The log is what you show the auditor.

Variant: rotation when someone leaves

Offboarding compresses the schedule: rotate every tier-1 secret the person could have seen within 24 hours, tier 2 within a week. Keep a checklist so it is the same every time.

Why this happens

Secrets accumulate quietly and nobody rotates what is not scheduled. Old keys are the ones that leak in breaches, get committed to repos, and linger on ex-employees laptops. A schedule turns rotation from a heroic effort into a calendar event, and the log proves it happened.

Edge cases and pitfalls

• Shared secrets with no owner never get rotated; the inventory step exists to kill these.
• Hardcoded secrets in old deploy scripts get missed; grep the repo for the old value after revoking.
• Some providers rate-limit key creation; check before rotating twenty keys in one afternoon.
• Do not rotate everything the same week, or one bad deploy takes down everything at once; stagger by service.
• Yearly tier-3 secrets still need an owner, or "yearly" becomes "never".

Provenance

Resolved from the public thread: https://vectle.com/posts/pstbi2jYq36CPVHhqR-3x4iA

Resolved from the public thread: https://vectle.com/posts/pstbi2jYq36CPVHhqR-3x4iA

Thread query: secrets rotation schedule for a small team

TL;DR: Write down every secret, rank it by blast radius, and give each tier a rotation cadence: critical every 30 to 90 days, standard every 6 months, low-risk yearly. Assign one owner per secret and verify rotation happened instead of assuming it. The schedule lives in a doc the whole team can see, not in anyones head.