The Database Password That's Three Years Old and Everyone's Afraid to Touch

Teams avoid rotating old secrets not because rotation itself is hard, but because nobody's confident they know every place a given credential is used. Rotating something with an unknown blast radius risks breaking a service nobody remembered depended on it.

The fix starts with mapping usage before touching the value: search configs, environment variables, and secret manager access logs for every place a credential is actually read. This turns 'we're afraid to touch it' into 'we know exactly what touches it,' which is what makes rotation safe.

A service that only accepts one active credential value forces synchronized rotation across every service using it, a genuinely risky coordination problem. A service that accepts two valid values during a transition window, the old and the new, lets you rotate consumers one at a time without a hard cutover moment.

This pattern, common in OAuth token refresh and increasingly supported by modern secret managers, turns rotation from a scheduled outage risk into a background operation nobody notices.

The strongest fix for the fear of rotation is removing long-lived secrets from the picture entirely where you can. Short-lived credentials, issued for minutes or hours and automatically renewed, mean there's no old value sitting around for years accumulating risk and reluctance.

This isn't possible for every credential type, some third-party integrations only support static API keys, but wherever your infrastructure supports it, dynamic short-lived credentials remove the entire category of problem this article is otherwise solving for.

Say a database password set at launch has never been rotated, and searching for it turns up references in four services, an old cron job, and a data export tool nobody remembers who owns. Rotating it blind would risk breaking whichever of these still actively depends on the old value.

Adding the new password as a second valid credential, confirming each known consumer has switched over by watching connection logs for the old value's use dropping to zero, then revoking the old one only once nothing's touched it in two weeks, turns a nerve-wracking unknown into a monitored, reversible process.

• A secret manager holding values that were still uploaded manually and never automated for rotation
• No usage mapping, so nobody's confident what breaks if a given credential changes
• Services that only support one active credential value, forcing risky synchronized cutovers
• Rotation policy that exists on paper but has no actual owner or schedule enforcing it

Not every secret needs the same rotation cadence. Prioritize by blast radius: database and infrastructure credentials that touch customer data first, low-risk internal tooling credentials later. The same federal patch-remediation standard used for software vulnerabilities is a reasonable urgency bar to borrow here: critical, internet-facing vulnerabilities get remediated within 15 days, and anything already under active exploitation within 14¹, which is roughly how fast a credential you know is exposed deserves to be rotated.

Start with automated rotation for your two or three highest-risk credentials rather than trying to solve every secret in the system at once. A working rotation process for the credentials that matter most beats a stalled plan to rotate everything.

Rotating a routine credential on a calm Tuesday and rotating one during an active incident, because it may have leaked, are very different situations, but they should follow the same steps. Writing the runbook down in advance, who approves it, how consumers are notified, how you confirm the old value is no longer in use, means an incident rotation follows a tested process instead of being improvised.

A runbook that's only ever been read, never actually exercised, tends to have gaps that only show up the first time someone tries to follow it under pressure. Running through it once on a low-stakes credential is worth the hour it takes.