HashiCorp Vault Security Review
A Vault policy’s wildcard or sudo path can grant far more access than it looks like. We test those policies, auth methods, secrets engines and seal configuration. CREST-certified testers, fixed price from £2,310 for a 2-day single-cluster scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Sealing Vault takes only one operator with root privileges. Unsealing it again needs a quorum of key holders, whether that is Shamir key shares or auto-unseal recovery keys.
A Vault cluster is only as tightly scoped as the policies, auth methods and secrets engines your team configured
Vault’s own documentation on policies confirms that everything in Vault is path-based, and a policy grants one or more capabilities against a path, including create, read, update, delete, list and the special sudo capability needed for root-protected endpoints. A path written with a wildcard, or a capability set that includes sudo, can reach far more than a narrow reading of the policy name suggests, and Vault applies the broadest matching policy when several apply to the same path. We test what every attached policy actually grants a token, not what its name implies.
Every login to Vault goes through an auth method, whether AppRole’s role_id and secret_id pair, Kubernetes auth binding a pod’s service account token to a named role, OIDC, or plain userpass, and each one assigns the resulting token a set of policies and a time-to-live. A non-root token always expires on its TTL, but Vault documents that a root token’s TTL can be set to zero, meaning it never expires on its own. We test which auth methods are enabled, how tightly their role bindings are scoped, and whether any root or long-lived token has outlived the task it was created for.
We review the auth methods, policies, secrets engines, audit devices and seal configuration on your own Vault cluster, the same way we review a client’s own configuration on Terraform-managed infrastructure rather than Terraform itself. We never test Vault’s own codebase or attempt to find vulnerabilities in the open-source project.
SCOPE
What we review on a single Vault cluster
Policies, Paths and Capabilities
Vault documents that everything in the system is path-based, and a policy grants one or more capabilities, create, read, update, patch, list, delete, or the special sudo capability required for root-protected endpoints, against a specific path or a path written with a wildcard. Where more than one attached policy matches the same path, Vault applies the broadest result across all of them, so a broad policy attached alongside a narrow one can silently widen what a token can reach. We test every policy actually attached to every token and identity, not just the policy the business believes is in force.
AppRole Authentication
AppRole authenticates a machine or application against a Vault-defined role using a role_id and a secret_id, and Vault documents constraints that can be layered on top, including bind_secret_id, which requires the secret_id to be presented at all, and secret_id_bound_cidrs, which restricts logins to specific IP ranges regardless of which secret_id is used. A role with no CIDR binding and a long-lived secret_id behaves like a static credential that anyone holding it can use from anywhere. We test which AppRole roles exist, what constraints are actually configured on each, and what policies the resulting token carries.
Kubernetes Auth Method
The Kubernetes auth method authenticates a pod using its own service account token, and Vault’s documentation binds a named role to bound_service_account_names and bound_service_account_namespaces so only pods running under specific service accounts in specific namespaces can assume it; Vault itself warns that a pod’s JWT should never be shared with other applications, since possessing it lets a caller authenticate as that pod. We test how tightly each Kubernetes role is bound, whether a role’s namespace or service account binding is wider than the workload that needs it, and what policies the resulting token grants.
OIDC and Userpass Authentication
Vault supports OIDC as an auth method for human users signing in through an external identity provider, alongside userpass for username and password logins held directly in Vault, and both, like every auth method, map a successful login onto a set of policies rather than granting access directly. A userpass account left over from a migration or a proof of concept carries whatever policies were attached when it was created, whether or not anyone still uses it. We test which OIDC and userpass configurations exist, what policies each one maps to, and whether any userpass account is still active without a clear owner.
Root Tokens and Token TTLs
Every non-root token has a time-to-live measured from its creation or last renewal, after which it and its leases are revoked, but Vault documents that a root token’s TTL can be set to zero so it never expires on its own; periodic tokens, available to root, sudo users or certain auth methods, can also be renewed indefinitely within their period. A root or periodic token that was only ever meant for initial setup can remain valid indefinitely if nobody deliberately revokes it. We test how many root and periodic tokens exist, their actual TTLs, and whether any have outlived the setup task they were issued for.
Secrets Engines: Static and Dynamic
Vault documents secrets engines as components that store, generate or encrypt data at their own mounted path, behaving like a virtual filesystem to the caller; some, like the key/value engine, simply store and version data you write, while others connect to a database or cloud provider and generate credentials dynamically on demand with their own lease. A dynamic secret’s lease ties its lifetime to Vault rather than to a password someone has to remember to rotate, but only if the engine is actually configured to revoke access when that lease expires. We test which secrets engines are mounted, which ones issue dynamic credentials, and whether revocation actually happens when a lease ends.
KV Version 2 Versioning
The key/value version 2 engine stores and versions arbitrary static secrets, and Vault documents that deleting a version is a soft delete, the data stays recoverable until it is explicitly destroyed, at which point the underlying version data is purged and the key metadata is marked as destroyed. Old, soft-deleted versions of a secret remain readable to anyone with the right policy until someone actively destroys them, which means a rotated credential’s previous value can still be sitting in Vault’s version history. We test how many old versions of each secret still exist, and whether stale versions of rotated credentials have actually been destroyed.
Audit Devices
Vault documents that, with a small set of exempted endpoints, every audit device records every API request and response in detail, and by default hashes string values with a keyed HMAC-SHA256 to protect sensitive data in the log rather than writing it in the clear, aside from non-string values and any field explicitly exempted; specific request or response fields can be selectively exempted from that hashing per auth method or secrets engine. An audit device that was never enabled leaves no record of who read or changed what, and a field exempted from hashing without a clear reason can leak a secret straight into the log. We test whether audit logging is enabled at all, and whether any field has been exempted from hashing without justification.
Seal, Unseal and Recovery Keys
Vault documents that sealing the cluster takes only a single operator with root privileges, useful for shutting it down quickly if an intrusion is detected, while unsealing it again needs a quorum: a threshold of Shamir key shares under the default seal, or a threshold of recovery keys under auto-unseal, which delegates the unseal key itself to a trusted external key management service. Recovery keys cannot decrypt the root key on their own, so if the auto-unseal mechanism itself fails, they are not sufficient to unseal Vault by hand. We test who holds the key shares or recovery keys, how the threshold is set, and what happens if the auto-unseal service becomes unavailable.
Namespaces and HCP Vault vs Self-Managed
Namespaces are a Vault Enterprise or HCP Vault Dedicated feature that create an isolated environment with its own login paths inside a single Vault installation, intended to give each tenant team its own policies, secrets and identities without a separate cluster; Vault documents this as secure multi-tenancy with administration delegated to each namespace. HCP Vault Dedicated is a fully managed version of Vault Enterprise where HashiCorp itself operates infrastructure monitoring, cluster health, backups and upgrades, which shifts operational responsibility for those tasks away from your own team but not the responsibility for the policies, auth methods and namespace boundaries configured inside it. We confirm whether your cluster is self-managed, Vault Enterprise or HCP Vault Dedicated, and test the namespace and tenant boundaries actually configured within it.
OUR PROCESS
HashiCorp Vault Security Review: From Scope to Attestation
Scope and Access
We agree which Vault cluster, namespaces and secrets engines are in scope, plus at least one token for each auth method and policy tier in use.
Policy and Auth Mapping
We map every auth method binding, policy, secrets engine and audit device against the access it actually grants.
Manual Testing
A CREST-certified tester manually tests policy boundaries, auth method bindings, token TTLs, secrets engine exposure and seal configuration, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST HashiCorp Vault pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent HashiCorp Vault Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test HashiCorp Vault For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From HashiCorp Vault Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Vault cluster?
We need at least one token for each distinct policy and auth method in use, ideally scoped tokens rather than root, plus read access to the auth method, policy and secrets engine configuration where possible. A root token is never needed to scope or run the engagement.
Will testing touch our live data?
Testing focuses on auth method bindings, policies, secrets engine configuration, token TTLs and seal setup rather than the contents of secrets already stored in Vault. Where proving a finding needs a test secret, a test AppRole or a temporary token, we agree the exact scope with you first and remove anything we create once testing is complete.
Is this hosted on our infrastructure or HashiCorp’s?
Vault can run self-managed on your own infrastructure or as HCP Vault Dedicated, where HashiCorp operates the underlying platform on your behalf. We confirm which model applies to your cluster during scoping and test the policies, auth methods and namespace boundaries you actually control.
How long does a Vault security review take?
A single cluster with a typical set of auth methods, policies and secrets engines sits in our 2-day single-cluster scope, with a report landing around 5 working days after kickoff. A cluster running multiple namespaces or a large number of secrets engines extends that scope.
What is out of scope for a single-cluster review?
Testing Vault’s own source code, its underlying storage backend, or the key management service behind an auto-unseal configuration is not included, and we do not run denial-of-service testing against the Vault cluster. A connected secrets engine’s own target system, such as a database, is scoped and quoted separately.
Do you need our source code or admin access?
No. We test with the policy-scoped tokens and access you provide, and we do not need a root token beyond what is needed to verify a specific finding during the engagement.
Does HashiCorp have a policy on customer penetration testing?
Self-managed Vault is software you run yourself, so there is no vendor notification process to follow before testing your own cluster, and a genuine vulnerability in Vault’s own code is reported through HashiCorp’s published vulnerability disclosure process instead. HCP Vault Dedicated runs on HashiCorp’s own cloud platform, so we confirm HashiCorp’s current customer security-testing terms for it during scoping.
Are your testers CREST certified?
Yes. Every Vault engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Vault cluster
A Vault policy’s wildcard or sudo path can grant far more access than it looks like. We test those policies, auth methods, secrets engines and seal configuration. CREST-certified testers, fixed price from £2,310 for a 2-day single-cluster scope, quoted within 24 hours.
