Key rotation has a reputation as compliance theatre, and when it is done badly that reputation is earned. Rotating a key on a schedule while having no idea where it is used produces an outage and no security benefit. Done with an inventory behind it, it is one of the more useful routines a small team can have.
The reasoning is not about cryptographic strength. A 32-byte random key is not more guessable next year than this year. What changes over time is everything around it.
What rotation is actually for
Keys leak quietly. Not usually through a dramatic breach, but through the accumulation of ordinary events:
- It was pasted into a Slack message during a debugging session in 2024.
- It appeared in a CI log that anyone in the organisation can still read.
- It was committed to a repository, then removed in a later commit, and is still in the history.
- Four people who have since left the company could read it in the shared vault.
- It sits in a developer's local environment file on a laptop that was replaced without being wiped.
Any one of these might be harmless. Collectively, they mean an old key has been in more places than anyone can now enumerate. Rotation is the mechanism that makes all of those copies worthless at once, without needing to find them.
Put differently: rotation converts "we hope nobody kept a copy" into "any copy anyone kept has stopped working."
The inventory comes first
This is the part people skip, and skipping it is why rotation goes wrong. Before rotating anything, write down for each key: what it is, which service issued it, what it can do, and every place it currently lives.
That last column is the work. Keys live in more places than the deployment environment:
- Production, staging and preview environment variables. Preview deployments frequently inherit production secrets, which is rarely intended and easy to check.
- CI and deployment secret stores.
- The shared password manager.
- Developers' local environment files, which you cannot inspect but can ask about.
- Third-party services you connected to your systems: a BI tool, a no-code automation, a data pipeline. These are the ones people forget, because the key was pasted into somebody else's interface months ago.
A short table covering this is worth more than any policy document, and it is also what a security questionnaire is really asking for when it asks about key management. Building it is usually a twenty-minute job that produces at least one surprise.
Rotating without an outage
The safe pattern is overlap. Never revoke first.
- Create the new key alongside the old one.
- Deploy it everywhere on your list.
- Watch for evidence the old key is still in use. Many providers show last-used timestamps, which turn this from guesswork into observation.
- Revoke the old key once it has been unused for long enough to cover your slowest job. If something monthly uses it, that means waiting more than a month.
Where a service permits only one active key, coordinate a short switch and do it at a quiet hour. Where a service permits several, rotation is almost uneventful, which is a reasonable thing to weigh when choosing vendors.
The step most often skipped is the third. Revoking immediately after deploying feels efficient and is how the quarterly report job discovers, three weeks later, that its credential is gone.
A schedule that survives contact with reality
Ambitious schedules get abandoned. Something like this is achievable and defensible:
- Annually: ordinary keys with narrow scope.
- Quarterly: anything with broad privileges, particularly service-role and admin keys.
- On departure: every key the leaver could see. This is the trigger that matters most and the one most often missed, which is why it belongs on the offboarding checklist rather than in a separate calendar.
- On exposure: immediately, and rotate before cleaning up. A tidied repository with a still-valid key in its history is a cosmetic fix.
Put the recurring ones in a calendar with a named owner. An unowned quarterly task is an annual task at best.
Reducing how much rotation you need
The less a key can do, the less urgent its rotation. A credential scoped to read three tables is a smaller problem than one that can drop the database, and it can sit on an annual cycle without anyone worrying.
Short-lived credentials are better still. Cloud providers increasingly support issuing tokens that expire in minutes, obtained by a workload proving its identity rather than by holding a long-lived secret. Where that is available it removes the rotation question rather than answering it. It is more setup, and worth it for the highest-privilege paths.
Knowing when a key was last used
Most providers record when each credential was last used, and almost nobody looks. It is one of the more useful five-minute exercises available to a small team, because it answers two questions at once.
Which keys are dead? A credential unused for six months is either attached to something seasonal or attached to nothing. The second is far more common. Every one of those is exposure with no corresponding benefit, and revoking it costs nothing. Do it one at a time and watch, rather than in a batch, so that if something does break you know immediately what caused it.
Which keys are being used from somewhere unexpected? Where the provider logs source addresses as well as times, a key used from a region you do not operate in is worth an immediate look. This is the closest thing to detection most small teams have for a leaked credential, and it costs nothing beyond remembering to check.
Add it to the same calendar entry as rotation. Reviewing last-used dates and rotating the keys that matter is one task, not two, and the review is what makes the rotation safe.
When rotation is not the right answer
Two cases where scheduled rotation is the wrong tool, and reaching for it anyway produces work without benefit.
Where the credential can be short-lived instead. If a workload can obtain a token that expires in fifteen minutes by proving its identity, rotating a long-lived key for it is solving a problem you could remove. Cloud providers increasingly support this between their own services, and between a CI system and a cloud account. It is more setup once and no recurring task afterwards.
Where the key is already scoped to almost nothing. A read-only credential for one public dataset does not repay a quarterly routine. Spending the same attention on the one key that can modify customer records is strictly better. Rotation effort should follow privilege, not spread evenly for the sake of a tidy policy.
A schedule that treats every credential the same is easier to write and harder to sustain, and the first thing abandoned when a quarter gets busy is usually the part that mattered.
Where the effort is better spent
If you have limited time, the order is: inventory first, then scope, then rotation cadence. An inventory tells you what exists. Scoping reduces what each key can do, which reduces how much rotation matters. Rotation then closes the remaining exposure window.
Teams often start at the end, announcing a quarterly rotation policy before anyone knows where the keys live. That produces a document and an outage. Starting at the beginning produces a short table that makes every subsequent step straightforward.
The short version
Rotation without an inventory causes outages. Rotation with one is straightforward and closes off every copy of a key that anyone kept, including the copies you do not know exist. Build the list first; the rest is mechanical.