Secrets rotation schedule teams actually follow

Why rotation slips

Most teams do not ignore secrets on purpose. The usual problem is ownership.

A database password, API token, or signing key gets created during a rushed setup, works fine, and slowly becomes nobody's job. One engineer assumes ops owns it. Ops assumes the app team owns it. The app keeps running, so nobody touches it.

That is how a temporary credential ends up living for three or four years.

Timing makes it worse. A reminder on the calendar looks sensible, but it lands during a late release, a customer issue, or a week when the team is already overloaded. It gets pushed to next week, then the week after that. After a few rounds, the reminder loses all meaning.

The risk grows quietly, which is why teams tolerate it for so long. Old access can survive employee exits, team changes, contractor handoffs, and even security incidents. Someone leaves, but an old shared credential still works. A service gets rebuilt after an incident, but the same token stays in place. Nothing looks broken, yet the exposure stays there.

Small teams and growing startups run into this all the time. They move fast, ship often, and avoid work that feels separate from delivery. That instinct is understandable. It also leaves old production credentials in place with more access than anyone remembers.

Teams usually follow events better than dates. They already have habits around deployments, offboarding, and incident drills. When rotation is tied to those moments, it stops feeling like extra admin work and becomes routine maintenance.

Start with the secrets that can hurt you most

Teams often get stuck because they try to rotate everything at once. That sounds careful, but it usually turns into a huge spreadsheet and no real action.

Start with the small group of credentials that could expose customer data, ship bad code, or knock production offline. For each secret, write down three things: who owns it, which system uses it, and what damage it could cause if it leaked or stayed active after it should have been removed.

The first batch usually includes:

• production database credentials
• cloud admin access
• CI/CD tokens that can deploy code
• auth, payment, and email provider secrets tied to live customer flows
• backup and monitoring accounts with broad access

Mark the environment for every secret. Production comes first. Staging comes next if it holds copied data, talks to shared services, or offers a path into production. Internal tools matter too, but they usually sit lower unless they touch billing, support, or admin actions.

This is where ownership has to become explicit. If nobody owns a secret, it will sit untouched for years. Give each one a named owner, even if that owner is a small team rather than one person.

Skip the low risk clutter for now. Old demo tokens, sandbox accounts, and minor test keys can wait until the team proves it can rotate the dangerous set on time. Ten well managed secrets are better than two hundred ignored ones.

Use triggers your team already follows

Calendar reminders look tidy, then get ignored for six months. Rotation works better when it rides on events your team already treats as mandatory.

Deployments are one of the best triggers. Teams already pause, review changes, and touch production settings during a release. That makes release windows a natural time to rotate API keys, service tokens, and database credentials tied to the new version.

A few triggers cover most situations. Rotate some secrets during planned deployments, especially for production systems and shared services. Rotate access right away when someone leaves or changes roles. Rotate after incident drills, and again after a real incident if the team had to share credentials, create temporary access, or bypass normal controls. Then set a hard maximum age so nothing stays unchanged for years just because no other trigger fired.

Employee exits deserve special treatment because delay creates real risk. The same goes for role changes. When a developer moves off an app, or a contractor finishes work, remove old access and replace any shared credentials they could still know.

Drills help for a different reason. They expose what the written process misses. During a tabletop exercise, teams often discover an old admin token in a runbook, a shared password in chat, or a service account nobody owns. Fix those gaps right after the drill, while everyone still remembers the mess.

The maximum age is a backstop. Some systems change rarely, even when the team is disciplined. A payment secret might need a much shorter limit than a staging token, but both still need an expiry point.

The best trigger is not the most elegant one. It is the one your team will act on every time.

Build the schedule step by step

Rotation works when it feels like normal team work, not a side project that only appears after a scare.

Start with a plain inventory. If nobody can say what a secret does, where it lives, and who owns it, the schedule will drift fast. Create one record for each secret, not one record per app. A database password, a payment token, a CI variable, and a cloud access key should each have their own entry.

Keep each record short. You need the secret name, the service it affects, the owner, the trigger for rotation, the person who changes it, the person who verifies it, and a note about rollback.

Do not force one rule onto everything. Some secrets should rotate on a date. Others should rotate after a release, a vendor change, or an access change. The point is to choose one trigger per secret so nobody has to guess.

A small product team might handle this in different ways. The production database credential may rotate during a planned release window. A support tool token may rotate when the teammate who managed it leaves that role. Both rules are fine because the risk and the workflow are different.

Before anyone changes a secret, write the rollback note. Keep it blunt. Which old credential stays valid for a short overlap, who can restore it, what service needs a restart, and how do you confirm the app still works?

Keep the whole plan where release work already happens. If your team reviews deploy tasks in GitLab, a ticket system, or a release checklist, put rotation status there too. People follow the process they already open every week.

Tie rotation to releases

Most teams do not ignore releases. They ignore reminders that feel detached from the product.

If you release every Friday, pick one planned release each month and rotate a small set of deployment secrets. That might be an API token, a database credential used by the app, a webhook secret, or a cloud credential for delivery jobs. Small habits beat a rule buried in a policy doc.

Add rotation to the same release checklist your team already trusts. Put it next to config review, startup checks, and restart steps so nobody has to remember a second process.

In practice, the flow is simple. Create the new secret and store it where your team already keeps production credentials. Update the app or job config so it can use the new value. Deploy. Run a simple check to confirm the service starts and behaves normally. Only then should you remove the old secret.

That overlap prevents easy mistakes. If you remove the old credential too soon, a missed worker or scheduled task can fail later even though the main app looked fine right after deploy.

Record each rotation where people already look during releases. A short note in the release log or runbook is enough: what changed, who changed it, what systems were tested, and when the old credential was removed.

Keep emergency credentials outside the normal release flow. You may need them during an outage, and routine deploy work should not depend on them. Store them separately, review access on their own schedule, and test them in a controlled way.

Handle employee exits the same day

When someone leaves, old access becomes a problem fast. The safest rule is simple: remove their access the same day their job ends.

Start with personal accounts, then move to anything shared. If they knew a database password, copied an API token, or had access to a production admin panel, assume they can still use it until you rotate it.

A clean exit check usually starts in four places: CI variables and deploy secrets, VPN and SSH access, service accounts they created or managed, and admin panels for billing, analytics, support, and DNS.

Shared credentials need extra care because they outlive the person. A solid process ties offboarding to forced rotation, so the team does not waste time debating whether a password is probably fine. If the person could see it or export it, rotate it.

Role changes deserve the same treatment. If an engineer moves from platform work to a narrow product role, their old access should shrink right away. Plenty of leaks happen after internal moves because everyone still trusts the person, so nobody cleans up the old permissions.

One step gets missed all the time: make sure the new owner can still do the job after rotation. Teams often revoke access, change passwords, and then discover nobody can deploy, restart a job, or reach the logs. Before you close the offboarding task, confirm the right people can still work.

This process should feel a little boring. When HR, the manager, and the technical owner all know the checklist, exits stop being a scramble and stop leaving old doors open.

Use drills to keep the process honest

Teams ignore rotation when it lives only in a policy doc. A short drill every quarter turns it into a habit and shows whether the process still works when people feel rushed.

Pick one believable event and run it like it happened on a normal workday. A developer loses a laptop after travel. A token appears in a public repo. A shared admin password lands in the wrong chat. Small drills work better than giant exercises because the team can finish them in under an hour.

During the drill, track three things: how long it takes to find the secret, how long it takes to rotate it, and how long it takes to prove the old access no longer works. Those numbers matter more than good intentions. If nobody knows who owns the secret, or verification takes longer than the rotation itself, you found a weak spot.

Write down every moment when someone asks who owns this or where is that stored. Those questions point straight at the parts that will break first in a real incident. Maybe the token sits in two CI jobs. Maybe only one engineer can reach the cloud console. Maybe the runbook says rotate the key but never explains how to test the new one safely.

After each drill, cut the runbook down to the exact steps a tired teammate can follow late in the day. Add owners, locations, commands, and checks. Drills keep exposing the messy parts before a real leak does.

A simple example from a small product team

A five person SaaS team ships every Friday. Their process is not perfect on paper, but it follows real habits.

One backend engineer helped manage production access and handled part of the release flow. When he gave notice, the team did not wait for a monthly review. They used his last week as the trigger and rotated every secret he could reach.

They started with build and deploy tokens, cloud credentials for production services, shared dashboard logins, and the older service credentials stored in their secret manager. They did the work before his access ended, while he could still answer questions. That saved time because the team knew which jobs might break and which scripts still depended on older values.

On Friday, they used the normal release window to prove the new secrets worked. The build ran, the deploy finished, alerts still fired, and the team could sign in to the dashboards they actually used. That mattered more than closing a ticket.

They still found gaps. One view only dashboard account had not been on the offboarding list. A scheduled job still used an older cloud key from an environment file nobody had touched in months. They fixed both the same day.

After that, they updated the offboarding checklist. Shared dashboards, service accounts, and a quick deploy test after every access change all became part of the routine. The process stayed simple because it matched work the team already did every week.

Mistakes that make rotation fail

Most rotation plans fail for boring reasons. The team gets busy, one password change breaks a job, and everyone says they will fix it later.

A few mistakes show up again and again. Rotating everything on the same day creates panic. People rush, skip checks, and postpone the whole batch when one system looks fragile. Keeping secrets in personal notes, screenshots, or chat threads makes old copies hard to kill. Changing credentials without a test and rollback plan makes the next rotation feel risky, so it gets pushed back. Teams also forget machines. Old CI jobs, scheduled scripts, staging boxes, and migration tools often hold the oldest credentials in the company.

Another quiet problem is shared admin access with no named owner. One person should own each secret, know where it is used, and confirm the new value works.

Small teams feel these problems more because they depend on memory. That works until one engineer goes on vacation or a script nobody remembers starts failing in production.

The fix is not a bigger policy document. Keep a short inventory, assign one owner per secret, and make every rotation prove one thing: the service still works after the change. If your team cannot answer who owns a credential, where it runs, and how to test it, rotation will keep slipping.

A quick checklist

Rotation works best when it feels boring. If the team can answer a few plain questions without digging through old tickets, the process usually sticks.

Use this in your next engineering or ops meeting:

• give every secret a named owner
• write down the next trigger for each secret
• keep one short runbook for rotation, testing, and rollback
• put shared credentials into the offboarding checklist
• run a small drill and note where the team gets stuck

A good checklist should fit on one screen. If it turns into a long policy document, people stop using it.

One extra test helps. Ask a teammate who did not write the process to rotate a low risk secret. If they can finish without asking three people for help, the process is probably usable. If they cannot, fix the runbook before a real incident forces the issue.

What to do next

Choose one production system this week and write down every secret it uses. Keep the scope small so the team actually finishes it. Your main app, payment service, or CI pipeline is enough.

For each secret, note where it lives, who can change it, what breaks if it expires, and the next realistic time to rotate it. That turns a vague idea into work someone can own.

A simple first pass is enough: list the secrets for one live system, assign one owner for each, add rotation to the next release plan, add access removal to the offboarding flow, and set one review date.

Do not write a long credential policy unless your team already follows written process well. Most teams ignore long docs. A short page with clear steps works better.

Tie the work to habits that already exist. If you deploy every two weeks, rotate the secrets that support that service during a release that already has engineering attention. If someone leaves the company, remove access the same day and check shared credentials right away. If you run incident drills, include a fast access review so people practice under a little pressure instead of guessing during a real problem.

If your setup is messy and nobody is sure who owns what, an outside review can save time. Oleg Sotnikov at oleg.is works with startups and smaller teams as a Fractional CTO, and this kind of access cleanup and infrastructure review fits naturally into that work.

Keep the schedule short enough to fit on one screen. The team should know what to rotate, when to do it, and who owns it.