Rotate credentials by risk, not by one fixed rule. Rotate powerful or long lived keys on a set schedule, rotate any credential immediately after a leak or a departure, and prefer short lived credentials that expire on their own. Keep a calendar so rotation actually happens.
What rotation is for
Rotation limits how long a stolen or leaked credential stays useful. It is one part of a credential's life. The OWASP Secrets Management Cheat Sheet lays out the secret lifecycle as creation, rotation, revocation and expiration, and recommends automating secrets management where possible. Treat rotation as one step in that cycle, not the whole answer.
No standard interval fits every key. Choose intervals you can keep, because a promised monthly rotation that nobody performs is worse than a clear quarterly one.
Triage your credentials
| Tier | Examples | Approach |
|---|---|---|
| High | Cloud admin keys, production database passwords, signing keys, registry publish tokens | Shortest interval, or short lived tokens, with an owner |
| Medium | CI tokens, third party API keys with write access | Scheduled rotation, scoped narrowly |
| Low | Read only keys, non production test keys | Rotate on event, or longer schedule |
Where a provider supports short lived or workload identity based credentials, use them. They rotate by design and remove the calendar entry.
Build the calendar
- List every credential with location, owner, scope and creation date. Your tool inventory is a good start.
- Assign a tier and an interval.
- Put each rotation in a shared calendar or ticket tracker with the owner's name.
- Write one rotation procedure per credential type: create the new one, deploy it, confirm it works, revoke the old one.
- Record the date of each rotation.
The order in step four matters. Revoke the old credential only after you confirm the new one works, or you cause an outage.
Event triggers
Rotate right away when a person with access leaves, when a laptop is lost, when a credential appears in a log, chat or repository, or when a vendor reports a breach. Revoke first, investigate second. Include these triggers in your offboarding checklist.
Reduce what needs rotating
Fewer long lived secrets means less work. Remove unused keys. Narrow scopes. Use separate credentials per service so one leak does not open everything. Keep secrets in a store, not in code or chat.
Practice the hard one
Once a year, rotate a credential that many services share and see what breaks. Better in a drill than in an incident. The tabletop in this guide can include a leaked key scenario.
Write down who can rotate
For each high tier credential, name two people who know the procedure. If only one person can rotate the database password, the rotation will slip when they are on leave. A short runbook per credential type, tested once, is enough.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
Is monthly rotation the standard?
There is no single standard. Pick intervals by risk that you can sustain, and rotate at once after any leak or departure.
What is better than rotation?
Short lived credentials that expire automatically, where your providers support them.
Sources
Last reviewed: 19 October 2026.
