The Vault Illusion: Are We Really Securing Secrets, or Just Feeling Better?
After more than two decades designing and operating systems, I’ve come to accept an uncomfortable truth about security:
There is always a root trust.
Everything else is just layers built on top of it.
Recently, I found myself in a familiar conversation — one many engineers and architects will recognize. The topic was secret management: property files, encrypted values, master keys, vaults, HSMs. And, almost reflexively, the conclusion:
“Move secrets to a vault. That’s more secure.”
But is it really?
Or are we sometimes just playing a more elaborate game of hide-and-seek?
This post isn’t an attack on vaults or security teams. It’s an attempt to question the fundamentals honestly, and to ask whether we sometimes confuse layering with eliminating risk.
The Original “Problem”
The setup is common:
- An application stores sensitive values (database passwords, API keys) encrypted in configuration files.
- The encryption key exists somewhere on the same system.
- A security review flags this as a concern: “If someone breaks into the host, they can misuse the key.”
That concern is valid.
The proposed fix is equally common:
“Move secrets to a Vault or HSM.”
That’s where my questioning begins.
The Question No One Likes to Sit With
Let’s pause and ask a simple question:
How does an application access a vault?
Applications aren’t humans. They don’t type passwords or unlock safes. They authenticate using something:
- a service account
- a machine identity
- an IAM role
- a certificate
- a token derived from one of the above
Whatever mechanism we choose, that identity is persistent.
Every time the app starts:
- it uses the same service account
- on the same machine
- with the same permissions
Yes, a vault might issue a short-lived token.
But the initial trust anchor that allows the application to obtain that token is permanent.
So let’s be honest:
If an attacker compromises the host deeply enough to abuse that identity, the vault does not magically save us.
At that point, the system is compromised.
“But the Blast Radius Is Smaller”
This is the argument I hear most often.
And it deserves careful examination.
If an attacker gains:
- OS-level access
- control over the application identity
- the ability to run code as the application
Then:
- In a property-file model → secrets can be decrypted
- In a vault model → secrets can be fetched
The blast radius is functionally the same.
What does change is:
- auditability
- revocation speed
- visibility
- operational discipline
These are valuable improvements.
But they are operational benefits, not a fundamental removal of risk.
Calling this out isn’t denial — it’s accuracy.
Are We Solving Risk, or Managing Optics?
Sometimes the industry narrative feels like this:
- Property files → “bad”
- Vault → “good”
- HSM → “very good”
But the root trust remains unchanged.
So I ask, genuinely and respectfully:
- Are we reducing risk — or redistributing it?
- Are we improving security — or improving how it looks in a review?
- Are we being honest with leadership about what vaults do — and don’t — solve?
Vaults add layers, not absolution.
And layers can be useful — as long as we don’t pretend they remove the foundational dependency on a trusted runtime identity.
In practice, security decisions are often influenced by process and scale. Checklists, standards, and prescribed controls are necessary to manage complexity, but they can also encourage a mindset where the presence of a control is treated as a proxy for actual risk reduction. Over time, it becomes easy to focus on whether a box is ticked rather than whether the underlying threat model has meaningfully changed.
An Unusually Honest Take from the Tomcat Project
While thinking through this topic, I was reminded of a refreshingly candid explanation from the Apache Tomcat documentation. In response to the question “Why are plain text passwords in config files?”, the maintainers write:
“Because there is no good way to ‘secure’ them.
When Tomcat needs to connect to a database, it needs the original password. While the password could be encoded, there still needs to be a mechanism to decode it. And since the source to Tomcat is freely available, the attacker would know the decoding method.
So at best, the password is obscured — but not really protected.
Please see the user and dev list archives for flame wars about this topic.”
— Apache Tomcat Wiki
I find this one of the most honest statements in mainstream infrastructure documentation. It doesn’t promise a silver bullet. It doesn’t confuse obscurity with security. It simply acknowledges reality.
If software must use a secret, that secret must be recoverable.
And if it’s recoverable, it exists within a trust boundary that must be defended.
Why I’m Writing This
This isn’t an anti-vault post.
It’s not an argument against HSMs.
And it’s certainly not an attack on security teams.
It’s a call for intellectual honesty.
Security isn’t about pretending risk disappears.
It’s about understanding where it moves.
If the real threat model is:
“An attacker gains deep control of the host or application identity”
Then no amount of secret shuffling will fully save us.
What Am I Missing?
This is where I genuinely want feedback.
If you believe:
- vaults fundamentally change the threat model,
- HSMs eliminate risks I’m underestimating,
- or my reasoning has blind spots,
I’d love to hear it.
Not marketing answers.
Not compliance checklists.
Real-world reasoning.
Because the worst thing we can do in security is stop asking uncomfortable questions.