Vault Community Edition (CE) covers the vast majority of use cases in secrets management (this is the author's opinion, not a measured statistic). Before considering Enterprise, assess your real needs objectively: most teams do not need the advanced features.
This page details the differences between the editions and helps you make an informed choice. It compares the editions of Vault; the comparison with the open source fork is in Vault vs OpenBao, and the license is covered in Vault's BSL license.
What you will learn
- The features included in each edition
- The real Enterprise needs versus the perceived ones
- The HCP Vault option (managed Vault)
- An objective decision grid
What are the Vault editions?
One detail that avoids a bad surprise at the end of a project: the two editions
are shipped as separate binaries. HashiCorp's release catalog exposes, for
the same version, a CE variant and variants suffixed +ent, +ent.hsm and
+ent.fips1403 (HSM stands for hardware security module, a tamper-resistant
device that holds cryptographic keys, and FIPS for the US federal
cryptography standard). Moving to Enterprise therefore means replacing the
binary or the container image, not just dropping in a license file.
Read the "License" column before the "Price" column: since Vault 1.15, the code
is no longer under MPL 2.0 (Mozilla Public License 2.0, an open source
license) but under BUSL 1.1 (Business Source License 1.1, a source-available
license that is not open source), and the licensor named in the repository's
LICENSE file is now IBM, which bought HashiCorp. This constraint weighs on
your choice long before the budget question, especially if you resell a service
built on Vault. The details are in
Vault's BSL license.
| Edition | License | Price | Use case |
|---|---|---|---|
| Community (CE) | BSL 1.1 (free, but not open source) | Free | Most organizations |
| Enterprise | Commercial | $$$ | Multi-region, strict compliance |
| HCP Vault (IBM Vault Dedicated) | SaaS | $/hour | Managed Vault, sold by IBM |
HCP stands for HashiCorp Cloud Platform, the vendor's managed service: the option is detailed in its own section below.
Full feature comparison table
The three tables that follow are split by the moment the question arises: what you store (secrets engines, authentication methods), what you operate (storage, high availability, unsealing), then what you govern (isolation, policies, audit). A "No" does not mean "impossible in CE": it means "not provided by Vault CE, to be assembled differently". The matching alternatives are detailed further down.
Which core features does each edition include?
This first table covers the product's functional surface, the one developers consume daily. It is also the least discriminating: the engines that cover the vast majority of uses, namely KV, Transit, PKI and the dynamic database secrets, are in both editions. The two rows that switch to Enterprise, KMIP and Transform, answer precise needs: speaking the key management protocol of storage arrays and HSMs for the first, tokenizing credit card or social security numbers for the second.
| Feature | CE | Enterprise |
|---|---|---|
| Secrets Engines | ||
| KV (Key-Value) | Yes | Yes |
| Transit (encryption) | Yes | Yes |
| PKI (certificates) | Yes | Yes |
| Database (dynamic secrets) | Yes | Yes |
| SSH (OTP, CA) | Yes | Yes |
| AWS, Azure, GCP secrets | Yes | Yes |
| KMIP | No | Yes |
| Transform (tokenization) | No | Yes |
| Auth Methods | ||
| AppRole, UserPass | Yes | Yes |
| Kubernetes, LDAP | Yes | Yes |
| OIDC, JWT | Yes | Yes |
| AWS, Azure, GCP auth | Yes | Yes |
| Login MFA (TOTP, Duo, Okta, PingID) | Yes | Yes |
| SAML, Step-up MFA | No | Yes |
Which operational features does each edition include?
This is where the real price difference plays out. Look first at the High availability block: a CE cluster already runs Raft (the consensus protocol behind Vault's built-in storage) with automatic leader failover on a single site, which covers the failure of one node. What CE does not do is replicate to a second cluster on another site. The Unseal block reads the same way: auto-unseal through a cloud KMS (key management service), which many believe is reserved for Enterprise, has been available in CE since Vault 1.0. Only sealing through an HSM over PKCS#11 (the standard interface to talk to an HSM) and Seal Wrap remain in Enterprise, both driven by a FIPS certification, not by an operational need.
| Feature | CE | Enterprise |
|---|---|---|
| Storage | ||
| Integrated Storage (Raft) | Yes | Yes |
| Consul, etcd, etc. | Yes | Yes |
| High availability | ||
| HA cluster (single site) | Yes | Yes |
| DR replication | No | Yes |
| Performance replication | No | Yes |
| Autopilot | Yes (basic) | Yes (advanced) |
| Unseal | ||
| Shamir | Yes | Yes |
| Auto-unseal (KMS, Transit) | Yes | Yes |
| HSM PKCS#11 | No | Yes |
| Seal Wrap | No | Yes |
Which governance features does each edition include?
This third table concerns organizations, not machines. The row that most often triggers license purchases, in the author's experience, is Namespaces: without it, isolating several teams means multiplying clusters or enforcing discipline on path prefixes. Sentinel and Control Groups answer written compliance requirements, never an operational convenience. Note that audit logs are in CE: it is the point auditors check first, and it costs nothing.
| Feature | CE | Enterprise |
|---|---|---|
| Multi-tenancy | ||
| Namespaces | No | Yes |
| Advanced policies | ||
| ACL policies | Yes | Yes |
| Sentinel (policy-as-code) | No | Yes |
| Control Groups | No | Yes |
| Audit | ||
| Audit logs | Yes | Yes |
| Entropy augmentation | No | Yes |
Which Enterprise features do you really need?
Each of the six sections below is built the same way: what the feature does, the organization profile that really justifies it, then the equivalent setup in CE. Read the third part above all. In most decision files, it is not the Enterprise feature that is missing, it is the operations work that its CE equivalent demands, and that work has a cost too.
Replication DR and Performance
Vault replication works at the level of the whole vault, not of a single secret: a primary cluster continuously pushes its log to one or more secondary clusters. What hurts in CE is not availability but the RPO (recovery point objective), that is, the amount of data you accept to lose. With Raft snapshots every hour, you lose at worst one hour of writes; with replication, the loss is counted in seconds. Quantify that difference before opening a commercial discussion.
What it is:
- DR Replication (disaster recovery): a secondary cluster on standby for recovery after a disaster
- Performance Replication: active secondary clusters that spread the load
Who really needs it:
- Organizations with very strict SLAs (service level agreements) of 99.99%+
- Multi-region infrastructures where latency is critical
- Regulatory requirements for geographic DR
CE alternatives:
- Regular Raft snapshots + a tested restore procedure
- Single-site HA cluster (already very resilient)
- Several independent clusters
Namespaces
A namespace is a Vault inside the Vault: it has its own tree of mounts, its own policies and its own tokens, and a namespace administrator sees nothing of the others. It is the Enterprise feature whose absence is felt most often in practice (the author's observation, not a measured figure), because it is paid for in cluster sprawl: without namespaces, each autonomous team ends up demanding its own three-node Raft cluster, to back up and update separately. Count that operating cost before concluding that CE is free.
What it is:
Full isolation of tenants inside a single cluster. Each namespace has its own secrets, auth methods and policies.
Who really needs it:
- Managed service providers
- Large organizations with autonomous teams
- Multi-customer environments
CE alternatives:
- Separate clusters per team/environment
- Strict path prefixes with ACL policies
- OpenBao: namespaces included for free
MFA: Login MFA in CE, Step-up in Enterprise
This is a point on which some comparisons get it wrong, some reseller
pages included. MFA at login does exist in Community Edition, and has
for a long time: the HashiCorp documentation states "Starting with Vault
version 1.10, Vault Community Edition provides MFA on login only", with the four
methods TOTP (time-based one-time passwords), Okta, Duo and
PingID. Configuration goes through the identity/mfa/method/:type and
identity/mfa/login_enforcement API endpoints.
What Enterprise reserves is Step-up MFA: asking for a second factor not
at login anymore, but at the moment a specific sensitive path is reached, for
example pki/root/sign-intermediate. It is configured through
sys/mfa/method/:type/:name and requires Sentinel policies. Enterprise also
adds TOTP self-enrollment and a per-namespace variant.
Who really needs Step-up:
- Operations with a wide, irreversible effect (signing a root CA, rekey)
- Regulatory requirement for re-authentication per action, not per session
- Shared administration accounts that cannot be removed in the short term
CE alternatives:
- Native Login MFA on local methods like
userpass, with no license - MFA enforced by the IdP (identity provider) upstream, for OIDC or LDAP logins
- Shorter token lifetimes, to force frequent reconnection
Do not confuse the two API endpoints, it is a frequent source of error:
sys/mfa/method/* is the Enterprise Step-up API, whereas
identity/mfa/method/* is the Login MFA API of the Community edition. On a
CE Vault, a vault write sys/mfa/method/totp/… returns a 404 code while
vault write identity/mfa/method/totp issuer=… period=30 does return a
method_id. A 404 on the first path therefore does not signal a broken binary,
only an Enterprise API called without a license.
Sentinel (policy-as-code)
A classic ACL policy answers a single question: does this token have the right to this path? Sentinel adds the request context, which an ACL cannot express: the time, the source address, the authentication method used, or the value of a request parameter. The decision criterion is therefore simple to state: if your rules are always of the form "who accesses what", ACLs are enough; if they contain an "unless" or an "only when", Sentinel becomes relevant.
What it is:
An advanced policy language that allows complex rules based on identity, time and request properties.
Who really needs it:
- Organizations with strict compliance
- Needs for complex contextual policies
- Automated compliance auditing
CE alternatives:
- ACL policies (they cover most needs)
- Validation in the applications
- Manual approval processes
Control Groups
A Control Group intercepts the reading of a secret and puts it on hold: the requester receives a request identifier instead of the value, and the secret is only delivered once the required number of approvals is reached. The difference with a ticket-based validation is that the control is enforced by Vault, not just documented: nobody can bypass it by connecting directly. It is precisely this non-bypassability that auditors ask for when they require a separation of duties.
What it is:
Requires several approvals for certain sensitive operations.
Who really needs it:
- Regulatory "four eyes principle" requirements
- High-risk financial operations
- Highly regulated environments (PCI-DSS, strict SOC2)
CE alternatives:
- Documented manual procedures
- External approval workflow (tickets, chat)
- Split root token (Shamir) = multi-person control
- OpenBao: a
control_grouppolicy stanza was added in 2.7.0
HSM and Seal Wrap
The distinction between these two features often goes unnoticed, and it changes everything. The HSM Seal only concerns the unseal key: the HSM decrypts the root key at startup, then Vault works in memory as usual. Seal Wrap goes further and routes every write of data marked as sensitive through the HSM, which costs one hardware round trip per operation and is paid for in latency. Enable the second only if a certification requires it, never as a precaution.
What it is:
- HSM Seal: master key stored in a hardware HSM
- Seal Wrap: additional encryption of sensitive data by the HSM
Who really needs it:
- FIPS 140-2/140-3 Level 3+ requirements
- Highly regulated sectors (defense, critical finance)
- Protection against advanced insider threats
CE alternatives:
- Auto-unseal through a KMS (AWS KMS, GCP KMS, Azure Key Vault)
- Transit seal (another Vault/OpenBao cluster)
- Shamir with strict procedures
How these sealing mechanisms work is detailed in Auto-unseal and Recovery Keys.
Real needs or perceived needs?
The two tabs below are meant to prepare an arbitration meeting. The first lists the arguments you hear that do not survive examination; the second, the situations where the license is justified without discussion. The dividing line is always the same: a real Enterprise need rests on a verifiable external constraint, a contract clause, a compliance framework, a signed SLA commitment. A perceived need rests on an intuition of robustness. If you cannot cite the document that imposes the feature, you are in the first tab.
| Perceived need | Reality |
|---|---|
| "We need DR" | An HA cluster + automated snapshots + a tested procedure is enough in most cases |
| "We want MFA" | The IdP often already covers OIDC and LDAP logins; Login MFA, free in CE, covers the local methods |
| "We need namespaces" | Separate paths with strict policies, or OpenBao, may be enough |
| "Enterprise = more secure" | CE is just as secure, Enterprise adds operational features |
| Validated need | Why Enterprise |
|---|---|
| Multi-region with critical latency | Performance Replication reduces latency |
| 99.99%+ SLA with automatic DR | DR Replication with automatic failover |
| Commercial multi-tenant | Namespaces fully isolate the customers |
| FIPS 140-2 Level 3 compliance | HSM Seal mandatory |
| Regulatory four-eyes principle | Native Control Groups |
What is the HCP Vault option?
HCP Vault Dedicated (HashiCorp Cloud Platform) is a Vault Enterprise cluster deployed and operated by HashiCorp in your cloud region. The product is now sold by IBM under the name IBM Vault Dedicated; this page keeps the name "HCP Vault", still the name in common use. The official documentation describes three tiers: Development, single-node and explicitly reserved for non-production; Essentials, in high availability; and Standard, which adds Performance replication and Sentinel. A point to remember before reading the next two lists: namespaces are included from the Development tier, which makes HCP the shortest path to this feature if you want neither an Enterprise license nor OpenBao.
What are the advantages?
These advantages all come down to the same thing: it is HashiCorp that carries the on-call duty. The line about updates is easy to underestimate: on a self-managed cluster, upgrading a three-node Raft cluster is an operation teams tend to postpone, and that is how you end up with an unpatched Vault facing a published CVE (a publicly catalogued vulnerability).
- No infrastructure to manage
- Automatic updates
- Built-in backups
- Available in minutes
- Some Enterprise features included
What are the drawbacks?
The first point to examine is not latency but coupling: your Kubernetes clusters, your CI runners and your machines now authenticate against a third-party service, and an outage of that service freezes your deployments. Second point, the billing per authenticated client of the Essentials and Standard tiers: a cluster that is cheap per hour can see its bill soar as soon as every pod, every runner and every virtual machine counts as a distinct client.
- Recurring cost (hourly billing)
- Network latency (not on-premises)
- Dependency on HashiCorp's cloud
- Less control over the configuration
When should you consider HCP Vault?
The table below is read through the most rigid constraint of your context, not through the average. A single "No" row, typically data sovereignty or an on-premises hosting obligation, rules the option out whatever the other advantages. The "experienced ops team" row is the only one that requires a real calculation: compare the annual HCP cost with the time your teams actually spend operating Vault, on-call duty and version upgrades included.
| Situation | Is HCP Vault relevant? |
|---|---|
| Startup without an infrastructure team | Yes |
| Quick POC/prototype | Yes |
| Critical on-premises infrastructure | No |
| Experienced ops team | To assess (cost vs time) |
| Sovereignty constraints | No |
Which edition should you pick? The final decision grid
The four lists below are not exclusive and are not read in order. Treat them as entry criteria: start with the Enterprise list, because it is the only one whose criteria are imposed from outside and therefore non-negotiable. If none applies to you, go back down to CE, OpenBao or HCP depending on the resource you lack most, team time or license budget.
Start with CE if...
These criteria describe an organization whose constraints remain internal: you choose your service level instead of enduring it. The last point is the most discriminating, and also the one teams state out loud the least. Ask the question the other way round to answer it honestly: how much does a half-hour outage of your deployments and of your secret renewals cost?
- It is your first Vault
- You are a team of fewer than 50 people
- You have no strict regulatory requirements
- Your infrastructure is single-region
- You can tolerate 15-30 minutes of downtime in case of a disaster
Consider Enterprise if...
Unlike the previous list, each criterion except the last must be able to rest on an enforceable document: a customer contract, a compliance framework, a signed service-level commitment. It is this document, and not a team's judgment, that will justify the expense in front of a finance department. A single criterion met among the first four is enough to open the file; the budget alone never is.
- Multi-region with a 99.99%+ SLA
- FIPS, strict PCI-DSS, SOC2 Type II compliance
- Multi-tenant business (namespaces mandatory)
- Regulatory four-eyes principle
- Substantial IT budget
Consider OpenBao if...
OpenBao is the Vault fork carried by the Linux Foundation, under the
MPL 2.0 license. The first criterion is the most concrete: namespaces are
built in since version 2.3.1, published on June 25, 2025 (2.3.0 was never
published as stable), and the control_group policy stanza appeared there in
2.7.0. The API comes from the Vault 1.14 code base, and the two APIs have
diverged since. The other two criteria are about strategy, not about features,
and are worth settling at the technical management level rather than in a
comparison of tables.
- Need for namespaces without an Enterprise budget
- Strict OSI open source policy
- Independence from HashiCorp/IBM
Consider HCP Vault if...
The common denominator of these four situations is not the budget but the scarcity of operating time. HCP buys team time, not security: a managed cluster that is badly partitioned stays badly partitioned. Also keep in mind that the Development tier is explicitly non-production in HashiCorp's documentation, which makes it a good basis for a mock-up but forbids letting it drift into real use.
- No dedicated ops team
- Quick POC needed
- Early-stage startup
- Limited time budget
How much do the editions cost?
The table below compares four items, and it is the Human cost column that decides in practice. The three self-managed solutions are even on paper, but the real workload depends above all on the number of clusters you will end up operating: without namespaces, isolation per team is paid for in extra clusters, hence in multiplied backups, version upgrades and on-call duty. Treat the amounts given as orders of magnitude to confirm, since no Enterprise price is published and the HCP prices change by tier.
| Solution | Infrastructure cost | License cost | Human cost |
|---|---|---|---|
| Vault CE | Servers/cloud | €0 | In-house ops |
| Vault Enterprise | Servers/cloud | On quote (contact sales) | In-house ops |
| HCP Vault (IBM Vault Dedicated) | €0 | Hourly rate per tier (see below) | Minimal |
| OpenBao | Servers/cloud | €0 | In-house ops |
The Enterprise price is not published: it depends on the number of nodes, the features and the commercial negotiation. Never budget without a quote. For IBM Vault Dedicated, the public price grid is readable, and the table below reproduces it to give the order of magnitude.
| Tier | Size | Indicative rate ($/h) |
|---|---|---|
| Development | Extra Small | 0.616 |
| Essentials | Small | 1.578 |
| Essentials | Medium | 3.163 |
| Essentials | Large | 7.489 |
| Standard | Small | 1.843 |
| Standard | Medium | 3.691 |
| Standard | Large | 9.406 |
These rates were collected on October 14, 2026 from
ibm.com/products/hashicorp/pricing. The Essentials and Standard tiers
add $72.92 per month and per "Product Client". Over a 730-hour month, an
Essentials Small cluster therefore costs around $1,150 before the clients, and
a Standard Large around $6,900. These amounts are dated orders of
magnitude: reread the vendor's page before any budget.
Can you migrate from CE to Enterprise later?
Good news for those who hesitate to commit: starting with CE does not lock you in. The data stays in the same Raft storage and the API does not change, so your applications, your policies and your AppRole roles survive the switch without modification. The work concentrates on replacing the binary and activating the license.
- Binary switch: replace the CE version with a
+entvariant of the same Vault version, node by node - License addition: drop in the license file, then check with
vault read sys/license/status - Additional configuration: namespaces, replication, Sentinel
To install the starting CE version, follow the Vault installation guide.
Two caveats so you do not feel safe too early. The switch remains an upgrade of a stateful cluster: Raft snapshot before starting, a tested restore, and a maintenance window. Above all, the reverse path does not exist cleanly: once you have created namespaces or enabled replication, going back to CE means dismantling that organization. Only take this step for an identified need.
Key points
- CE covers the vast majority of needs: do not assume you need Enterprise
- Namespaces: the Enterprise feature teams miss most often (the author's observation), included in OpenBao since 2.3.1
- Replication: assess your real RPO, not your comfort
- MFA: Login MFA is in CE since Vault 1.10; only the per-request Step-up MFA is Enterprise
- HSM and Seal Wrap: only for a written FIPS requirement
- HCP Vault Dedicated (IBM Vault Dedicated): three tiers, namespaces included, billed by the hour and per authenticated client; rates collected on October 14, 2026
- Separate binaries: Enterprise ships as
+entvariants, the switch is not just a license file
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Vault's BSL 1.1 license: what it allows and restricts
A new full quiz with random questions
Work again only on the questions you missed