No authority gives one number. OWASP says to rotate secrets regularly, so stolen credentials only work for a short time, and to automate it. GitHub says to rotate periodically. Pick intervals by risk, favor credentials that expire on their own, and always rotate immediately after a suspected exposure.
What the guidance actually says
OWASP's Secrets Management Cheat Sheet states that you should regularly rotate secrets so any stolen credentials will only work for a short time, and that rotation discourages reuse. It also says manual rotation is hard and can lead to mistakes, so automate where possible. It gives no specific interval, noting only that lifetimes range from minutes to years depending on purpose.
GitHub's secure use guidance says to rotate secrets periodically to reduce the window in which a compromised secret is valid, and to review and prune registered secrets.
One exclusion worth knowing: OWASP says user credentials are excluded from regular rotation, and should be rotated on suspected or confirmed compromise. This applies to human passwords, not to machine secrets in CI.
A practical tiering
Use your own risk view. This table is a starting point, not a standard.
| Credential type | Suggested approach |
|---|---|
| Cloud access via OIDC | No stored secret; token expires with the job |
| Pipeline credential to a secrets manager | Short lived, expiring after the job completes, per OWASP |
| Dynamic secrets from a secrets manager | Short lease; revoke when no longer needed |
| Long lived API keys you cannot replace | Rotate on a schedule you can actually keep, and on every departure |
| Signing keys and certificates | Follow the expiry of the certificate and your key policy |
Steps to set a schedule you will keep
- Inventory the secrets first. You cannot schedule what you cannot list.
- Remove what you can. Replace stored cloud keys with OIDC, and delete unused secrets.
- For what remains, pick an interval based on blast radius: broad, high value secrets rotate more often; narrow, low value ones less often.
- Automate. Use the provider's rotation feature or a scheduled job that creates a new credential, updates the CI secret, and revokes the old one.
- Use an overlap window so both old and new work briefly, then retire the old.
- Record each rotation with date and owner as evidence.
- Rehearse. A rotation you have never practiced will fail on the day you need it.
Event driven rotation
Schedules matter less than events. Rotate immediately when:
- A secret appears in a log, a chat, or a pull request.
- Someone with write access to the repository leaves.
- A third party action or dependency you ran in CI is reported compromised.
- A provider tells you of an exposure.
OWASP's incident guidance says exposed keys should undergo immediate revocation, and that a new secret must be quick to create, preferably through an automated process.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a single control, such as credential rotation, maps to several framework requirements, which helps when an auditor asks for your rotation evidence.
Quick check
Is rotating every 90 days a requirement?
Not in the sources reviewed here. OWASP and GitHub both say to rotate regularly without naming a period. If a framework or contract you are bound by names one, follow that.
Is rotating more often always better?
Not if it breaks deployments and teams start bypassing it. Automate first, then shorten the interval.
Safeguard compliance and evidence automation can help keep dated rotation records, and policies and gates can review changes to pipeline credentials. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
