HashiCorp Vault and BSL 1.1: What It Means and What to Do About It
Apr 14, 2026
ArticlePlan a Vault-to-OpenBao migration after HashiCorp BSL: keep the API, cut licensing cost and protect unseal keys with customer-held MPC.
Read articleA HashiCorp Vault alternative is another secrets manager that can store, issue and rotate application secrets in place of Vault. The closest one is OpenBao, an open-source fork of Vault that keeps its API. The others (cloud secret managers, CyberArk Conjur, Infisical) mean new client code and a new access model.
Teams usually start looking for three reasons: the 2023 licence change, cost as clients and clusters grow, and a wish to run secrets on infrastructure they choose. This page compares the main options and is upfront about DuoKey's role. DuoKey is not a general-purpose secrets manager. It runs OpenBao as a managed service and protects the key that unseals OpenBao or Vault, using multi-party computation (MPC), an HSM or a software vault.
Table of Contents
- Why teams look for a Vault alternative
- HashiCorp Vault alternatives compared
- OpenBao: the drop-in option
- Cloud secret managers
- CyberArk Conjur and Infisical
- Staying on Vault: what you can still change
- Where DuoKey fits
- How to choose
- FAQ
Why teams look for a Vault alternative
Licence. In August 2023 HashiCorp moved Vault from the Mozilla Public License 2.0 to the Business Source License 1.1 (BSL). The source stays readable, but the licence restricts some commercial uses. The background and a migration checklist are in HashiCorp Vault and BSL 1.1.
Ownership. IBM completed its acquisition of HashiCorp on 27 February 2025 (IBM press release). Some buyers want to reassess roadmap and contract terms after a change of owner.
Enterprise-only features. Several controls that regulated teams ask for are Vault Enterprise features. HashiCorp's documentation states that "auto-unseal and seal wrapping for PKCS11 require Vault Enterprise", and that seal wrapping requires Enterprise (PKCS#11 seal, seal concepts).
Application rewrite risk. This is usually what blocks a move. Many estates have years of code that reads secrets, logs in with AppRole or Kubernetes auth and calls the Transit engine. An alternative that changes the API turns a platform decision into an application programme.
HashiCorp Vault alternatives compared
| Option | Type | Licence or model | Vault API | Typical fit |
|---|---|---|---|---|
| OpenBao (self-run) | Open-source fork of Vault | MPL 2.0, OpenSSF project under the Linux Foundation | Kept (validate plugins and Enterprise-only features) | Teams that want Vault behaviour without BSL and can operate it |
| OpenBao managed by DuoKey | Managed OpenBao with MPC auto-unseal | OpenBao (MPL 2.0) plus a DuoKey service | Kept | Teams leaving Vault Enterprise that want the unseal key outside any single host or appliance |
| AWS Secrets Manager | Cloud provider service | Pay per use, AWS only | No | Workloads that run mostly on AWS |
| Azure Key Vault | Cloud provider service (secrets, keys, certificates) | Pay per use, Azure only | No | Workloads that run mostly on Azure |
| Google Cloud Secret Manager | Cloud provider service | Pay per use, Google Cloud only | No | Workloads that run mostly on Google Cloud |
| CyberArk Conjur | Secrets manager from a PAM vendor | Open-source server (LGPL v3) and commercial editions | No | Organisations already standardised on CyberArk |
| Infisical | Developer-focused secrets platform | Open-source core (MIT) and commercial tiers | No | Teams that want a newer UI and SDK-first workflow |
Licences and models are taken from each project's official site or repository at the time of writing; check them before you decide. The list is not exhaustive.
OpenBao: the drop-in option
OpenBao describes itself as "an open source, community-driven secrets manager and fork of Vault managed by the Linux Foundation's OpenSSF". It forked from the last MPL-licensed Vault code, so the HTTP API, CLI patterns, auth methods and secrets engines that most applications use are the same. In practice, a migration is an endpoint change plus testing, not a rewrite of every client.
Points to check before you commit:
- Enterprise-only Vault features. OpenBao did not inherit Vault Enterprise code. Map anything you use from Enterprise (replication modes, Sentinel, specific plugins) to what OpenBao offers today.
- Seal choice. OpenBao ships cloud KMS, KMIP, PKCS#11, static key and Transit seals. HSM auto-unseal through PKCS#11 is part of open-source OpenBao, not a paid add-on. The OpenBao auto-unseal guide compares each seal.
- Who operates it. Self-running OpenBao means you own upgrades, backups, monitoring and on-call.
Cloud secret managers
AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager are managed services. You get no servers to run, native IAM and pay-per-use billing. The trade-offs:
- New client code. Each has its own API and SDK. Vault calls have to be rewritten or wrapped.
- One cloud per service. A multi-cloud estate ends up with one secrets store per provider, each with its own policy model and audit log.
- Custody. The provider runs the service and holds the keys that protect your secrets, unless you add customer-managed or external keys. See hold your own key (HYOK) for what that changes.
They fit well when a workload lives in one cloud and the team is happy with that provider's IAM.
CyberArk Conjur and Infisical
CyberArk Conjur is a secrets manager from CyberArk. The Conjur Open Source repository states the server is licensed under LGPL v3, with commercial editions adding enterprise features. It suits organisations that already run CyberArk for privileged access.
Infisical is a newer secrets platform with an open-source core under the MIT licence and paid tiers, available as cloud or self-hosted (Infisical). It focuses on developer workflows: SDKs, CLI and syncing secrets to CI/CD and cloud platforms.
Neither speaks the Vault API, so plan for client changes.
Staying on Vault: what you can still change
Not every team needs to leave. If the issue is the unseal process rather than the licence, you can keep Vault and change where the unseal key lives:
- Vault Community supports auto-unseal with a cloud KMS or another Vault cluster's Transit engine.
- Vault Enterprise adds HSM auto-unseal over PKCS#11, seal wrapping and entropy augmentation. DuoKey's PKCS#11 provider for Vault plugs in here: Vault's root key is wrapped by an AES-256 key held in a DuoKey Cockpit-managed vault. The step-by-step is in Vault auto-unseal with an HSM.
Where DuoKey fits
DuoKey does three things around Vault and OpenBao. It does not replace them as the place applications read secrets from.
| What you need | What DuoKey provides |
|---|---|
| A Vault-compatible secrets platform without BSL | OpenBao + DuoKey SD-HSM: OpenBao run as an EU-hosted managed service, with a free migration assessment |
| Auto-unseal without a dedicated HSM per cluster | The OpenBao or Vault Enterprise PKCS#11 seal backed by DuoKey. The AES-256 seal key sits in MPC (DuoKey SD-HSM), an HSM or a software vault, and unsealing stops if the key is deactivated in Cockpit |
| One place for keys beyond secrets | The same Cockpit manages keys for KMS, database encryption, PKI and cloud external key stores, with one audit trail |
How MPC changes the unseal key's risk profile compared with a hardware module is covered in MPC vs HSM. A customer example is the Vault to OpenBao migration story.
How to choose
- List what calls Vault today. Count applications, auth methods, secrets engines and plugins. If most of it is standard Vault API, OpenBao keeps that code working.
- Decide who runs the platform. Self-run OpenBao, managed OpenBao, or a cloud provider service.
- Decide where the unseal and encryption keys live. Cloud KMS, an HSM, MPC, or a static key you inject. This is a custody decision, not a detail.
- Check Enterprise dependencies. Replication, namespaces, Sentinel and HSM features need a mapping, whichever option you pick.
- Pilot one environment. Migrate a non-production cluster, run your test suite, then plan the cutover.
FAQ
Q: What is the best HashiCorp Vault alternative?
It depends on how much Vault API code you have. If you want to keep that code, OpenBao is the closest match because it is a fork of Vault. If your workloads sit in one cloud and you can rewrite clients, that cloud's secret manager is simpler to run.
Q: Is OpenBao compatible with HashiCorp Vault?
OpenBao is a fork of Vault and keeps its API, CLI patterns and most auth methods and secrets engines, so most clients only need a new address. Features that were Enterprise-only in Vault were not part of the fork, so test your plugins and any Enterprise features before cutover.
Q: Is there a free alternative to HashiCorp Vault?
Yes. OpenBao is open source under MPL 2.0. The Conjur server and the Infisical core are also open source. Running any of them still costs infrastructure and operations time.
Q: Does DuoKey replace HashiCorp Vault?
Not as a secrets manager in its own right. DuoKey runs OpenBao, which is the Vault-compatible part, as a managed service, and protects the key that unseals OpenBao or Vault Enterprise. Applications keep reading secrets from OpenBao or Vault.
Q: Can I keep Vault and still avoid a dedicated unseal HSM?
With Vault Enterprise, yes: the PKCS#11 seal can point at DuoKey, which keeps the AES-256 wrapping key in MPC, an HSM or a software vault. Vault Community supports cloud KMS and Transit auto-unseal, but not PKCS#11.
Q: How long does a Vault to OpenBao migration take?
It depends on the estate. DuoKey's product page describes a 2 to 4 week path where the estate fits that window; the free migration assessment checks this against your clusters, auth methods and plugins.
References
Written by
Nagib Aouini
Related Resources
Secrets, keys and migration
Discuss the decisions that matter most to your security programme.
Tell us where control is difficult today. We will help you identify a practical next step.