Rotate your secrets before they rotate you
2026-06-08 · Security · 1 min read · @TechScribeWire
Every leaked-credential post-mortem has the same villain: a long-lived secret that worked for years, sat in an env file, and eventually ended up somewhere it should not have.
The problem with forever-tokens
A secret that never expires is a liability that only grows. The longer it lives, the more places it gets copied, the more logs it leaks into, and the bigger the blast radius when it finally escapes.
Make secrets short-lived by default
Prefer credentials that expire in minutes or hours, minted on demand:
# short-lived token scoped to one task, expires automatically
vault token create -policy=deploy -ttl=15m
Short TTLs turn a stolen secret from a standing threat into a brief window.
Limit the blast radius
- Scope tightly. A credential should grant the least it needs — one bucket, one table, read-only when possible.
- Separate by environment. Production secrets never touch staging, and vice versa.
- Audit access. If you cannot answer “what could this key do, and who used it last?”, you do not control it.
Rotation is a practice, not a project
Automate rotation so it happens on a schedule whether or not anyone remembers. The best time to rotate a key is before you find out you needed to.