To rotate a secret safely, create the new credential alongside the old one, test it, move every consumer over, confirm nothing still uses the old one, and only then revoke it. Automate the cycle where you can, and prefer short-lived secrets so rotation becomes routine instead of an emergency.
Key takeaways
- Overlap old and new credentials. Revoking first causes outages.
- Test the new credential before you promote it.
- Restarting an application does not revoke a stolen secret. Only the issuer can.
- Automation lowers both leak risk and human error.
- Log who had access, when it was used and when it was last rotated.
What does a safe rotation sequence look like?
Use four steps: create, set, test, finish. OWASP's Secrets Management Cheat Sheet describes rotation in those steps in its Lambda example, and says to test the pending credential before promoting its version.
- Create the new secret at the issuer. Keep the old one active.
- Set it where consumers read it, such as your secrets manager.
- Test it with a real call against the target system.
- Finish by switching consumers, watching for use of the old credential, then revoking the old one.
How do I rotate without downtime?
Run both credentials at once for a window. OWASP lists gradual rotation and a pattern of introducing new keys for write operations while leaving old keys for read operations. That lets slow consumers catch up before the old key dies.
Watch the issuer's logs for the old credential. When it has gone quiet for a period you chose in advance, revoke it.
Which secrets need extra care?
Encryption keys. OWASP notes that rotating some keys might trigger full or partial data re-encryption, so plan capacity and a rollback before you start. A database password usually needs only a coordinated config change. An encryption key may need a data migration.
Should I rotate on a schedule or on events?
Do both. A schedule keeps the process practiced. Events, such as a departing engineer, a leaked log or a compromised laptop, trigger an immediate rotation. GitHub's Actions guidance also tells you to review secrets periodically, remove unused ones and rotate them on a schedule.
Can I avoid rotating at all?
Mostly, by using short-lived credentials. OWASP says frequent rotation means any stolen credentials will only work for a short time, and recommends dynamic secrets with short lease durations. OIDC in CI is a good example: each job gets a token valid for a single job.
What should I record?
OWASP lists the minimum audit events: who requested a secret, whether it was approved, when it was used, when it expired, and any attempts to reuse expired secrets. Protect those logs from tampering and keep timestamps accurate.
Frequently asked questions
How often should secrets be rotated?
Pick an interval per secret type and rotate immediately on any suspected exposure. Shorter lifetimes limit the damage of theft.
Does restarting the app invalidate a stolen secret?
No. OWASP says stolen credentials stay valid until the backing service expires or revokes them.
Should rotation be manual or automated?
Automated where possible. OWASP warns that manual maintenance raises the risk of leakage and of human error.
What if I find a secret in my code?
Treat it as leaked: revoke, rotate, then clean up. See our leaked API key playbook.
Sources
Last reviewed: 19 October 2026.
