Secure your HashiCorp Vault surface
Policy scope, auth method configuration, and root tokens that were never meant to persist. We don’t connect to HashiCorp Vault to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where HashiCorp Vault goes wrong
Vault goes wrong through leftovers: a root token generated during an incident and never revoked defeats everything Vault exists to enforce.
- Root tokens generated for an incident and never revoked
- Policies granting broad path access rather than the specific secrets a service needs
- Auth methods configured with long or unlimited token TTLs
- Audit devices disabled or writing somewhere nobody monitors
- Unseal key shares held by too few people, or by people who have left
[02] What We Secure
What we watch, catch and fix on HashiCorp Vault
On Vault we treat the existence of a live root token as an incident in itself, not as a configuration observation.
- Root token existence treated as an incident in itself
- Policy paths resolved to effective secret access per role
- Token TTL and renewal behaviour reviewed against the threat model, since a long-lived token defeats the point of Vault
- Audit device configuration monitored as a control
- Unseal key custody reviewed as both a security and continuity risk
[03] Where It Lands
Where HashiCorp Vault lands in your registers
Directory data drives your access reviews directly: reviewers see live entitlements rather than a spreadsheet exported three weeks ago, and leaver revocation is verified against the systems themselves. The asset register records each identity provider as a critical dependency, and the risk register carries the concentration risk that comes with it — because if this tier fails, everything behind it fails with it.
[04] How We Engage
On HashiCorp Vault specifically
On HashiCorp Vault, we revoke lingering root tokens and tighten policy paths under agreed authority. Auth method redesign, TTL reduction, and unseal key redistribution we run as a scoped project given the availability risk.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] HashiCorp Vault FAQs
What Vault access does Konfirmity need?
Konfirmity needs a token bound to a read-only policy covering sys/ endpoints, auth method configuration and policy definitions. We read how Vault is configured, never the secrets it holds. The token is short-lived and renewed rather than long-lived.
Do you check token TTLs?
Yes, because a long-lived token defeats the point of using Vault at all. We review TTL and renewal behaviour per auth method against your actual threat model, and flag where a token would survive long past a revocation you believed was effective.