Secrets Rotation

Secrets rotation is the practice of periodically replacing sensitive credentials — API keys, database passwords, encryption keys, TLS certificates, service tokens — with new ones. The core idea is to bound the lifetime of any secret so that a leaked or compromised credential is useful to an attacker for as short a time as possible. The shorter a secret lives, the smaller the window of exposure.

How It Works

Rotation can be scheduled (every N days), event-driven (on suspected compromise, employee departure, or audit finding), or on-demand. Done well it is automated by a secrets manager — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager — that generates new credentials, updates the backing system, and distributes the new value to consumers without downtime.

The hard part is rotating without breaking running services. The standard technique is overlapping validity: issue the new secret while the old one still works, deploy the new one to all consumers, then revoke the old one. For database credentials, managers create a fresh user, swap applications over, and delete the old user. Dynamic secrets take this further: short-lived credentials generated per-session that expire automatically, eliminating long-lived secrets entirely. Applications should read secrets from the manager at runtime rather than embedding them, so rotation requires no redeploy.

When to Use It

Rotate any long-lived credential, especially high-value ones: production database passwords, cloud access keys, signing and encryption keys, and third-party API tokens. It is required by compliance frameworks (PCI DSS, SOC 2) and is the mandatory first response to any suspected leak. Where possible, prefer short-lived dynamic secrets and workload identity over static secrets you must rotate at all.

Trade-offs

Rotation adds operational complexity and risk: a botched rotation can cause outages if a consumer still holds the old secret when it is revoked, which is why overlapping windows and automation are essential. Building rotation for legacy systems that hardcode credentials is painful. Frequent rotation of secrets that are still embedded in configs or images can create churn without much benefit — the real win comes from centralizing secrets and automating the lifecycle, not from manual periodic resets.

Related Patterns

Secrets rotation complements least privilege (limit what each secret can do) and defense in depth (assume secrets will leak). Secure-by-default systems avoid shipping static default credentials in the first place. A sidecar can inject and refresh secrets into a workload transparently.

Example

A zero-downtime database password rotation managed automatically: the secrets manager creates app_user_v2 with the same least-privilege grants, the application — which fetches its credentials from the manager at startup and on a refresh interval — picks up the new password, traffic shifts over, and once no connections use app_user_v1 it is dropped. No code change, no redeploy, and the old credential is valid for only the brief overlap window.