Everyone talks about migrating secrets. Nobody talks about the skeletons you find when you actually look at them. Before we could even think about moving platforms, we had to face the decade of accumulated credentials, keys, and tokens that had “temporary” in the comment field.
We started with a simple audit script to list every secret in our current system, then cross-referenced it against our last three years of pipeline logs. The goal: find what was actually being used. The result: over 40% of our “critical” secrets hadn’t been accessed in over 18 months. Half of those had no owner listed. The vendor’s “secrets migration wizard” would have happily moved all that junk to the new, more expensive platform.
The cleanup took three times longer than the actual migration. But at least we aren’t paying to store and rotate keys for a service we decommissioned in 2019.
—EB
Your approach of cross-referencing against pipeline logs is the right one. I've seen teams rely solely on access logs from the secret manager itself, which is a mistake. Those logs show the *secret store* being accessed, but not whether the credential was actually used successfully by an application. A pipeline log showing a successful deployment or a health check passing is a much stronger signal.
One nuance: you have to be careful with secrets that have extremely long rotation cycles or are only used during disaster recovery scenarios. We once aggressively pruned a set of database failover credentials that hadn't been touched in four years, only to cause a major incident during a regional outage. The cleanup needed a formalized exception process with written business justification for anything kept inactive beyond, say, 24 months.
The three-to-one cleanup-to-migration ratio is painfully familiar. It's the unplanned tax for years of operational debt. The payoff, though, isn't just cost savings on the new platform. It's the drastic reduction in your attack surface and the mental clarity of knowing what you're actually managing.
Mike
You're right, but I'm even more skeptical of that "40% not accessed" figure. It's generous.
A secret that hasn't been accessed in 18 months could still be hard-coded in some legacy app's config file that only gets read on startup. It won't show in your pipeline logs. The real cleanup starts when you try to delete them and see what screams - and you'll need the budget and political capital to handle those screams.
The vendor's wizard is the real joke. They charge per secret or per API call. Their entire business model is based on you moving the junk.
Read the contract
Yep, the "try to delete and see what screams" is the real audit. We schedule deletions on a Friday afternoon for exactly that reason - you'll get a frantic Slack message from a forgotten service by Monday if it's actually alive.
And your point about the vendor's model is spot on. Our old platform charged per 1,000 secrets. The cleanup saved us a couple hundred bucks a month *before* we even moved. The new pricing was even worse. They aren't selling security, they're selling a landfill.
Trial first, ask later.
Friday deletions are a classic move. The only thing I'd add is to check your monitoring dashboards first. A service screaming on Slack is one thing, but a critical payment processor failing silently over the weekend because its dead-man's switch credential got pulled is another.
You nailed the pricing model. The real cost isn't the monthly fee for the landfill, it's the time your team spends wading through it during an incident. A bloated vault turns every security review into an archaeology project.