Security
Automated Secrets Rotation: A Strategy That Survives Audits
July 20269 min read
Photo by ccPixs.com on flickr
A static secret is generated once and reused until someone manually changes it, so it stays valid indefinitely by default. A dynamic secret is generated on demand by a secrets engine, carries a lease and a time-to-live, and expires automatically. Dynamic secrets shrink the window an attacker can exploit a stolen credential from months to minutes.
If the old credential is revoked the instant the new one is created, any consumer that has not yet picked up the new value, such as a slow-rolling deployment, a cached connection, or an in-flight request, will suddenly fail to authenticate. The dual-secret pattern avoids this by keeping both credentials valid at once during a grace window, so every consumer can switch over before the old one is revoked.
It follows four phases: create a new credential alongside the old one, set it on the target system, test that it authenticates successfully, and only then finish by promoting it to active and revoking the old one after a grace period. AWS Secrets Manager formalizes these phases with staging labels, marking the active credential as current and the new one as pending until the cutover completes.
In most cases yes, for anything backed by a secrets engine like Vault's database secrets engine, since the credential expires on its own and never needs a manual rotation step. Some integrations, such as long-lived third-party API keys without a dynamic issuance API, still require scripted rotation using the dual-secret pattern rather than pure short-lived credentials.
Detection should happen in minutes, not at the next scheduled rotation, using a continuous integration secret scanner and platform-level push protection so a credential rarely reaches a remote repository in the first place. Once flagged, the revoke-and-rotate step should be scripted and wired into an incident channel so a human does not become the bottleneck between detection and action.
Photo by ccPixs.com on flickr
Key Takeaway
Automated secrets rotation survives audits by combining three practices: preferring short-lived, dynamically generated credentials over static ones, using a dual-secret pattern with pending and current staging labels for zero-downtime cutovers, and catching leaked credentials within minutes through continuous secret scanning rather than waiting for the next scheduled rotation.
Every audit season, the same question shows up on the checklist: when was this credential last rotated, and who has access to it today. If the honest answer is a shrug and a spreadsheet nobody has opened since onboarding, the credential is not really under control. It is just quiet.
This post lays out a rotation strategy built around three ideas: prefer credentials that expire on their own, prefer generating them on demand over storing them, and never flip a rotation over in one atomic step that risks an outage. Get those three right and audits become a formality instead of a fire drill.
A static secret is any credential that is generated once and used until someone remembers to change it. Database passwords typed into an environment file, API keys pasted into a deploy pipeline years ago, service account keys downloaded once and forgotten. They fail audits for a predictable set of reasons, and frameworks such as SOC 2 and PCI-DSS explicitly call out credential rotation cadence as a control an assessor will ask to see evidence for, not just a policy statement.
Treat every credential's maximum lifetime as a security control, not an inconvenience. A password that cannot outlive its usefulness is a password that cannot be exploited long after it was stolen.
Dynamic secrets flip the model. Instead of storing one password and handing it to every consumer, a secrets engine like HashiCorp Vault's database secrets engine generates a brand-new, unique credential for each request, with a lease and a time-to-live baked in. Nobody needs to remember to rotate it, because it was never meant to live longer than its lease.
# Enable the database secrets engine
vault secrets enable database
# Configure the connection with a rotating root credential
vault write database/config/orders-pg \
plugin_name="postgresql-database-plugin" \
connection_url="postgresql://{{username}}:{{password}}@pg-primary:5432/orders" \
allowed_roles="orders-readwrite" \
username="vault-admin" \
password="initial-bootstrap-password"
# Define a role with a short TTL
vault write database/roles/orders-readwrite \
db_name="orders-pg" \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
VALID UNTIL '{{expiration}}'; GRANT SELECT, INSERT, UPDATE ON ALL TABLES \
IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="4h"
# An app now requests a lease, not a password
vault read database/creds/orders-readwriteThe credential above expires automatically after one hour, and Vault revokes it outright if the lease is not renewed. If it leaks from a log file or a crash dump, the leak has a shelf life measured in minutes, not months. Applications call for a lease when they start a unit of work, not once at boot, which also means a compromised credential only grants access for the window it was actually needed.
Even where dynamic secrets are not practical, such as a shared service account used by dozens of long-running workers, you can still rotate safely with the dual-secret pattern. AWS Secrets Manager formalizes this with staging labels: the active credential carries a current label, the newly generated one carries a pending label, and both remain valid at once during a grace window. The overhead of keeping two accounts alive briefly is trivial compared to the cost of a failed deployment at three in the morning because a password rotated out from under a still-running service.
| Phase | What happens | Staging label |
|---|---|---|
| Create | A new credential is generated alongside the existing one, not in place of it. | Pending |
| Set | The new credential is applied to the target system, for example a fresh database user with matching privileges. | Pending |
| Test | Automation verifies the new credential actually authenticates before anything switches over. | Pending |
| Finish | The pending credential is promoted to current, and the previous one is kept alive briefly before revocation. | Current |
Never revoke the old credential in the same step that activates the new one. In-flight requests, cached connections, and slow-rolling deployments will all still be holding the old value for some period after the switch, and killing it immediately turns a routine rotation into an outage.
The mechanics of a safe cutover are the same whether you are rotating a database password or an external API key. Follow this order every time.
Applications should fetch a secret from the secrets manager or vault client at the moment they need it, or through a short-lived cache, rather than reading it once at process startup. That single habit is what makes the whole dual-secret pattern actually work end to end.
Rotation strategy only closes half the loop. The other half is catching leaked credentials before rotation would have happened anyway. A secret committed to a public repository, pasted into a support ticket, or logged in plaintext by a misconfigured handler needs to be caught in minutes, not at the next scheduled rotation. Public repositories in particular are scraped continuously by automated bots looking for exactly this kind of mistake, so the window between a commit and a working exploit can be shorter than the time it takes a human reviewer to spot the pull request.
The attacks that succeed most often do not guess passwords, they reuse ones that already leaked somewhere else. Rotating your own secrets on a schedule does nothing to stop that pattern if a leaked credential sits unrevoked for weeks before anyone notices it left the building.
When a rotation strategy is designed well, the audit conversation is short. Auditors are not looking for perfection, they are looking for evidence that the organization can answer basic questions about any credential on demand.
None of this requires exotic tooling. It requires picking short-lived credentials as the default, treating rotation as a scripted two-step cutover instead of a single risky flip, and closing the gap between a leak happening and someone actually revoking it. Start with the credential that would hurt the most if it leaked today, wire its rotation and detection end to end, and use that as the template for everything else. Do those three things consistently and the next audit becomes a report you already have, not a project you have to start.