Rotating a secret manually is disruptive enough that teams do it rarely, which means credentials live for years, spread into configuration files and developer machines, and become the thing an attacker finds. The response is usually a policy requiring quarterly rotation, which produces a chore people postpone.
The actual fix is different: make credentials so short-lived that rotation is continuous and automatic, at which point the manual process disappears.
What changed in 2026
- Workload identity became widely available. Platforms issuing short-lived credentials to workloads based on their identity, with no stored secret, covered a growing share of authentication needs.
- Federation reduced cross-cloud secrets. Exchanging platform identity for access to another provider removed a common category of long-lived stored keys.
- Detection tooling matured. Scanning repositories and build logs for exposed credentials became a standard pipeline stage.
- Dual-credential support broadened. More services supported having two valid credentials simultaneously, which is what makes zero-downtime rotation possible.
The hierarchy
| Approach |
Exposure window |
Operational burden |
| Long-lived secret in configuration |
Years |
Low until it leaks |
| Long-lived secret in a secret manager |
Years, better controlled |
Low |
| Periodically rotated secret, automated |
Weeks |
Moderate setup, low ongoing |
| Short-lived token from a secret manager |
Hours |
Moderate |
| Workload identity, no stored secret |
Minutes |
Lowest once established |
The bottom row is the target. When a workload proves its identity to the platform and receives a credential valid for minutes, there is no secret to store, leak, or rotate. A credential found in a log is expired before anyone could use it.
Not everything supports this. Third-party services with API keys, legacy systems, and some databases still require a stored secret, and for those the goal is automated rotation with the shortest lifetime the service supports.
Making rotation safe
The reason rotation breaks things is the instant of changeover. A credential is replaced, and anything still holding the old one fails.
Dual-credential windows solve this. Create the new credential while the old remains valid, deploy the new one everywhere, verify nothing is still using the old, then revoke it. Every step is reversible and nothing has a moment where neither works.
Verification is the step teams skip. Without checking that the old credential has stopped being used, revocation is a guess — and the thing still using it is invariably a job that runs weekly and was not in anyone's mental model. Access logging on the credential, where the service provides it, turns this from a guess into a check.
Inventory comes first. You cannot rotate credentials you do not know about, and most organizations have more than they think — in CI configuration, in a script on someone's machine, embedded in a container image built two years ago. Scanning repositories and infrastructure definitions finds most of them, and the OAuth grant review in personal AI privacy checklist is the individual-scale version of the same exercise.
Common mistakes
- Calendar-driven manual rotation. Skipped, and useless between rotations.
- Rotating without a dual-credential window. Breaks whatever still holds the old one.
- Revoking without verifying disuse. The weekly job nobody remembered.
- No inventory. Rotating the credentials you know about leaves the others.
- Secrets in container images. Baked in, distributed, and hard to rotate.
- Treating a secret manager as sufficient. Better storage for a still-long-lived secret.
FAQ
How short should a credential live?
As short as the workload's usage pattern tolerates. Minutes for platform-issued tokens; for third-party keys, the shortest the service supports with automated renewal.
What about credentials for local development?
Separate credentials with narrow scope against non-production resources, never production credentials on developer machines.
How do I handle a service that does not support two valid credentials?
Rotate during a maintenance window, or place a proxy in front that can hold both. Some services genuinely require a brief interruption.
Does a secret manager remove the need for rotation?
It improves storage, access control, and auditing. A long-lived secret in a manager is still long-lived.
Where to go next
For scoping what credentials can do, read least privilege IAM. For service-to-service identity, mTLS in a service mesh, and for infrastructure state that holds secrets, Terraform state management.