Six Feet Under: Giving Dormant Credentials a Proper Burial Without Breaking Production

Every mid-sized engineering organization in the United States has one: a graveyard of credentials. A Stripe key from a 2021 proof-of-concept. A Google Maps token still embedded in a retired React Native app that a handful of ride-share drivers never uninstalled. A service token minted by a platform engineer who left for a startup in Austin eighteen months ago, still quietly authenticating a cron job nobody has opened since.

These keys are not merely clutter. They are standing invitations — valid, unexpired, and unmonitored. And unlike the credentials your team uses daily, dormant ones have a nasty property: nobody notices when they're stolen.

Why Dormancy Is a Security Problem, Not a Housekeeping One

Attackers do not brute-force your most actively rotated admin key. They look for the opposite: a credential that appears in a public GitHub commit from 2019, attached to a service whose logs go to a dashboard no one checks. The lack of usage makes it safe for the attacker, not for you.

The risk profile inverts. An actively used key has anomaly detection, rate alerts, and an owner who notices strange traffic. A dormant key has none of that. It is the unlocked storage unit of your security posture.

This is why credential audits should be treated with the same seriousness as dependency vulnerability scans — as recurring infrastructure work, not a one-time cleanup project.

Step One: Build the Inventory Before You Touch Anything

The most common audit failure is starting with revocation. Teams get motivated, delete a handful of keys, break a build, lose executive support, and abandon the effort. Resist that instinct.

Instead, spend the first phase purely on discovery:

1. Enumerate from the provider side. Pull every active key from your cloud consoles, mapping providers, payment processors, and identity vendors. Providers are the source of truth — your internal documentation is a rough sketch at best.
2. Sweep your repositories. Tools like trufflehog or gitleaks, run across full git history (not just the current tree), will surface keys committed years ago and never rotated.
3. Inspect your CI/CD configuration. GitHub Actions secrets, environment variable groups in CircleCI, and pipeline variables in GitLab are where credentials go to be forgotten. Export and review each one.
4. Check the human perimeter. Former employees' workstations, personal Dropbox folders used during a crunch, and Slack threads where someone pasted a token "temporarily."
5. Catalog, don't judge. For each credential, record: provider, creation date, last-used timestamp (most providers expose this), associated service, and a best-guess owner.

The output should be a spreadsheet or, better, a record in your internal tooling. You cannot safely bury what you haven't mapped.

Step Two: Establish a Dormancy Threshold

"Nobody uses it" is not a decision criterion — it's a hypothesis. You need a defensible threshold, and it should vary by credential type:

• Map and geolocation API keys: 90 days without a successful request is a strong signal, but check for long-tail traffic from cached mobile apps. A legacy iOS build can produce one-off requests for months.
• Service-to-service tokens: 30 days of silence for machine credentials is usually sufficient; services either run or they don't.
• Human-scoped keys: 60 days, aligned with typical access-review cycles.

Two caveats matter in a US business context. First, seasonality: a retail credential may look dormant in February and very much alive in November. Second, batch processing: some integrations run quarterly or annually, such as year-end reconciliation jobs. When in doubt, extend the observation window rather than shorten it.

Step Three: Revoke in Stages, Never All at Once

The safest revocation workflow mirrors a canary deployment:

1. Disable, don't delete. Most providers — AWS, Google Cloud, Mapbox, Stripe among them — let you disable a key while preserving the ability to re-enable it. This is your rollback path.
2. Watch the error streams. For 72 hours after disabling, monitor authentication failure logs across production, staging, and any third-party integrations. A spike in 401s tells you exactly which service was still leaning on that key.
3. Communicate before the second stage. Post the pending revocation in your engineering channel with a deadline. Half the time, an owner surfaces within a day.
4. Delete after the quiet period. Only after a full week of zero errors should the credential be permanently destroyed.

The staging approach transforms revocation from a gamble into a controlled experiment with a built-in undo.

Step Four: Make the Graveyard Impossible to Rebuild

An audit that isn't paired with prevention is a subscription to repeat work. Three structural fixes pay for themselves quickly:

• Expire by default. Wherever your providers support it, set maximum lifetimes on new keys. A credential that self-destructs in 90 days can never become archaeological.
• Gate key creation. Require a ticket or an owner field at issuance time. Keys minted with a named owner get rotated; keys minted anonymously get lost.
• Scan continuously. Run secret detection in your CI pipeline on every pull request, so new credentials never reach git history in the first place.

The Quiet Payoff

Teams that complete a first full audit typically retire 30 to 50 percent of their credential inventory. The blast radius of any future leak shrinks proportionally, compliance reviews get dramatically easier, and — less tangibly but no less importantly — engineers stop being afraid of the key management console.

Dormant credentials aren't a mystery. They're an inventory problem with a known solution. Map the graveyard, set a threshold, revoke in stages, and then build the fences that keep it from refilling. Your future incident response team will thank you for the shorter list of things that can go wrong.