It’s time for an identity-centric approach to secrets.
There’s something odd about Secrets Management.
It’s 2024 and Identity Security is top mind for everyone. Most hacks start with compromised credentials, so we enforce MFA everywhere, and we embrace just-in-time access wherever possible. But when it comes to secrets - such as access keys or database passwords - we still use long-lived credentials that are rotated manually.
And the number of secrets in your org is just growing. Every new microservice, new third-party integration, or AI agent you deploy comes with a new set of secrets.
What’s broken in Secrets Management today? Here are the five main challenges and one path forward.
Challenge 1: Your secrets are not secret; they’re everywhere.
You store your secrets in a secrets manager or a vault. That’s great because vaults are pretty safe and are unlikely to get hacked. But the truth is that your secrets live in many places outside of your vault. Secrets live in the memory of your applications and microservices, and they may be written to logs. Your developers have access to secrets and they may store them locally. And there are lots of secrets stored across your CI/CD pipeline.
The problem with that is that sending secrets outside of your secrets managers requires you to trust that applications and developers handle those secrets carefully.
Challenge 2: We’re still rotating keys like we’re in the 90’s
There’s one security “best practice” that hasn’t changed since the dawn of time: key rotation. Rotation is a tedious manual process that hinders productivity. Rotating a key every 90 days is like changing your house key every 90 days. It just feels wrong. Also, what if your key got exposed on the 89th day?
NIST and other frameworks are actually proposing to stop this practice and rotate passwords only if there’s evidence of compromise. But with most secrets, we lack the means to monitor that.
Challenge 3: We’re still using secrets where we shouldn’t
The best way to manage secrets is to just not have them in the first place. When you authenticate without a secret, there’s nothing for hackers to steal and compromise. Gartner analysts and others rightfully encourage organizations to go secretless, but that’s easier said than done.
Cloud providers are doing a good job of educating users on secretless authentication methods (for example, moving from access keys to IAM Roles in AWS). But many SaaS providers are still failing their side of the shared responsibility model; using long-lived API keys is still the only way to integrate with most third-party services.
Challenge 4: We’re missing an ownership model for secrets
A single secret may have multiple parents. There’s the person who has access to the secret vault where the secret is stored. And there may be another person who’s in charge of the underlying service that the secret is linked to. And then maybe there’s a third person who owns the service that consumes the secret. Having too many cooks in the kitchen makes secrets management confusing and difficult.
Challenge 5: We’re missing a security risk model for secrets
Secrets have proven to be a critical piece of recent attacks, and that’s only getting worse. Last Thanksgiving, Cloudflare reported that they rotated over 5000 production credentials and were still hacked through a single key they failed to rotate.
A single compromised secret can wreak havoc, but not all secrets carry the same risk. Out of all your secrets, do you know which are the ones you should really care about?
Hope for a brighter future?
Let’s imagine a future where we manage secrets exactly like we manage identities. We share access instead of sharing passwords. We know exactly who has access to what, and we reduce manual work to zero. Does that sound too good to be true?
If this piques your interest and you’d like to share notes - let’s connect.
