OpenBao vs HashiCorp Vault in 2026: Linux Secrets, Migration, and the Attacker's View

Updated: June 30, 2026

OpenBao vs HashiCorp Vault in 2026 comes down to one trade-off. OpenBao is the MPL 2.0, Linux Foundation–governed fork of Vault 1.14.0 with feature-parity for almost every self-hosted use case (including free Namespaces and horizontal read scalability since v2.5.0), while HashiCorp Vault (now an IBM product under the BUSL) keeps the lead on Disaster Recovery replication, Sentinel policies, FIPS 140-3 builds, and HCP Vault Dedicated. If you run Vault Community Edition 1.14.x, in-place migration to OpenBao is real. From Vault 1.15+ or Enterprise, plan an API-driven re-import instead.

• OpenBao 2.5.0 (released February 4, 2026) is an OpenSSF Sandbox project under Linux Foundation governance, forked from Vault 1.14.0 before the BUSL relicense.
• API and Terraform-provider compatibility means existing application code, sidecars, and hashicorp/vault Terraform modules keep working when pointed at bao.
• OpenBao ships Namespaces, horizontal read scalability, the Transform engine, and PKCS#11 auto-unseal in the open-source tree (all Enterprise-only on Vault).
• HashiCorp Vault Enterprise still wins on DR/Performance Replication, Sentinel, FIPS 140-3 builds, and HCP Vault Dedicated managed service.
• In-place migration is only documented from Vault CE 1.14.x. From 1.15+ or Enterprise you re-import via the API, not a snapshot transplant.
• From an attacker's view, both products have the same blast radius if you mishandle unseal-key custody, root-token rotation, or the audit pipeline. The product choice doesn't fix that.

Why this comparison exists in 2026

In August 2023, HashiCorp moved Vault (and Terraform, Consul, Nomad, Packer, Boundary) from MPL 2.0 to the Business Source License 1.1. That license forbids "competitive" hosting of the software, which excludes it from the OSI definition of open source. Vault 1.14.0 was the last MPL 2.0 release. The community forked it the same week. Within a year the fork had a name (OpenBao), a binary (bao), and a home at LF Edge, later promoted to an OpenSSF Sandbox project in June 2025.

The other thing that changed: IBM closed its $6.4B acquisition of HashiCorp on February 27, 2025. Vault is now an IBM Software product. As of mid-2026, the BUSL has not been reversed, and there's no public signal it will be. So when a procurement team or auditor asks "is this OSI-approved open source?", Vault Community Edition is no longer the right answer. OpenBao is.

Honestly, I'm writing this from the perspective of someone who breaks into things for a living. The question I care about isn't which logo is shinier. It's: where does each product fail open under attack, and what hardening controls do you owe the box on day one? That answer is mostly the same for both. The interesting differences are the ones I'll spend most of this article on.

Is OpenBao a fork of Vault?

Yes. OpenBao is a direct fork of HashiCorp Vault, branched from commit v1.14.0 in August 2023, when Vault was still under MPL 2.0. The binary is renamed from vault to bao, the HTTP API path prefix is still /v1/, and the storage and seal formats are byte-compatible. Most Vault SDK code (Go, Python, the Terraform hashicorp/vault provider, Vault Agent templates) talks to OpenBao without modification once you change the VAULT_ADDR endpoint.

The fork is not just a rename. Since v2.0, the project has merged things HashiCorp gated behind Enterprise. OpenBao 2.5.0 (released February 4, 2026) shipped:

• Namespaces. Multi-tenant isolation with separate policies, auth methods, and secret engines. Free.
• Horizontal read scalability. Standby (performance-standby-style) nodes that serve read traffic instead of forwarding everything to the leader.
• Transactional storage. Atomic multi-key writes in the Raft backend, useful for migrations and bulk policy updates.
• CEL policy engine. Common Expression Language as an alternative to HCL policies, OpenBao-only.
• Self-Init. Automated initialization for ephemeral clusters, where Shamir key ceremony makes no sense.
• PKCS#11 auto-unseal. HSM-backed unsealing without an Enterprise license.

One operational change worth flagging before you copy a Vault config across: OpenBao 2.0+ does not call mlock(2). If your Vault HCL has disable_mlock = true, remove the line. It's no longer recognised. If you relied on mlock to prevent secrets being paged to swap, you now need swap off or an encrypted swap partition. That's a hardening control you owe the box anyway, but the default has flipped.

OpenBao vs Vault feature comparison

Here's the short version. The two products are close enough day-to-day that you'll only notice the differences at the edges: replication, FIPS, namespaces, and the support contract.

Dimension	OpenBao 2.5	HashiCorp Vault 1.18 CE	Vault Enterprise
License	MPL 2.0 (OSI-approved)	BUSL 1.1 (source-available)	Commercial
Governance	Linux Foundation / OpenSSF	IBM (HashiCorp)	IBM (HashiCorp)
Namespaces	Yes (free)	No	Yes
Horizontal read scalability	Yes (v2.5.0)	No (followers forward to leader)	Yes (performance standby)
DR Replication	No (workarounds via Raft snapshots)	No	Yes
PKCS#11 / HSM auto-unseal	Yes	No	Yes
FIPS 140-3 build	No	No	Yes
Sentinel policies	No (CEL instead)	No	Yes
Terraform provider	hashicorp/vault works	hashicorp/vault	hashicorp/vault
Commercial support	Third-party (Adfinis, ControlPlane)	IBM	IBM

If you're running open-source Vault today, and your workloads don't touch DR replication or FIPS builds, OpenBao is at minimum a drop-in equal. On several axes (Namespaces, read scalability, HSM unseal), it's strictly more capable. If you're paying for Vault Enterprise specifically because you need cross-region DR, Sentinel governance, or FIPS, the calculus is different. OpenBao isn't there yet, and the project is honest about it.

What's the real licensing and governance difference?

MPL 2.0 is a weak copyleft, OSI-approved license. You can use it commercially, embed it, sell hosted services on top of it, and the only obligation is that modifications to MPL-licensed files must be shared back under MPL when you distribute them. There is no field-of-use restriction.

The BUSL 1.1 is different. It permits use, modification, and redistribution, but explicitly prohibits "production use of a Licensed Work that is competitive with HashiCorp's products". In practice, that bites managed-service providers and integrators more than end users. But procurement, FOSS-policy boards, and auditors don't get to apply a tactical reading. To a CISO with a "no source-available licenses in production" rule, BUSL Vault is out. Each BUSL release converts to MPL 2.0 four years after publication, which is a real consolation but not one you can plan a 2026 roadmap around.

Governance is the other axis. OpenBao has a Technical Steering Committee under the Linux Foundation, with seats including GitLab (which uses OpenBao as the native CI/CD secrets backend) and IBM engineers. No single vendor can relicense the project unilaterally, the same property that made OpenTofu attractive. Vault's roadmap, conversely, is set by IBM's commercial priorities for HashiCorp's product line. Neither model is "wrong", but they optimise for different things, and that's the call you have to make.

Attack surface and blast radius, a pentester's view

Forget feature matrices for a minute. When I get a foothold on a Linux server that talks to either Vault or OpenBao, my objective is the same: get a long-lived token, pivot to a powerful auth method, or compromise the unseal keys. The product brand doesn't change the attack tree. What changes it is your operator discipline. Here's how a typical attack chain runs, mapped to the hardening control on the defender side.

Step 1. Recon for tokens on disk

On compromise, I look for ~/.vault-token, VAULT_TOKEN in process environment via /proc/*/environ, sidecar tokens at /vault/secrets/ or /var/run/secrets/openbao/, and any token_helper entries in ~/.vault. Both products write tokens to disk identically.

Hardening: use response-wrapping (-wrap-ttl) for any token handed off to a CI job, set short TTLs on the role (default token TTL ≤ 1h), and use systemd's LoadCredential= with systemd-creds instead of EnvironmentFile= so the token never lands in /proc/PID/environ. Our Linux secrets management guide walks through the systemd-creds pattern in detail.

Step 2. Abuse the auth method

If there's no token to grab, I look at the auth method. AppRole secret-IDs in plaintext config, Kubernetes auth role bound to * service accounts, JWT/OIDC auth with bound_audiences = ["*"], AWS auth with no bound_iam_principal_arn. These are misconfigurations equally available in Vault and OpenBao.

Hardening: bind every auth role narrowly. For Kubernetes auth, never use the wildcard service account name or namespace. For AppRole, set secret_id_bound_cidrs and secret_id_num_uses. Prefer SPIFFE-based workload identity for service-to-service traffic, so there's no long-lived secret-ID to steal in the first place.

Step 3. Escalate via policy gaps

Policies are HCL (both products) or CEL (OpenBao only). The classic mistake is granting "sys/*" or "auth/token/create" with no role restriction. Once I can mint tokens with arbitrary policies, the game is over.

Hardening: deny "sys/*" by default, restrict "auth/token/create" to specific role names, and use required_parameters on policy paths to force structured calls. Audit token-creation activity in the audit device.

Step 4. Compromise unseal keys

This is the prize. Shamir unseal key shares stored on the same operator's workstation, all in ~/Documents/vault-keys.txt. Or auto-unseal via cloud KMS with the unseal IAM role permissioned to anyone who can sts:AssumeRole from the CI account.

Hardening: distribute Shamir shares to physically separate humans and store them on YubiKey HSMs or in offline paper backup. For auto-unseal, use OpenBao's PKCS#11 against a Nitro Enclave, AWS CloudHSM, or YubiHSM 2, and lock down the IAM policy of the unseal role so only the Vault/OpenBao service identity can call Decrypt. Log every Decrypt call in CloudTrail and alert on calls from outside the cluster's service identity.

How do you migrate from Vault to OpenBao?

The official path is in-place migration from Vault CE 1.14.x. Anything older needs to be upgraded to 1.14.1 first. Vault 1.15+ and Vault Enterprise are explicitly out of scope for the binary-swap migration. For those, you re-import via the API.

In-place migration from Vault CE 1.14.x

This works because OpenBao 2.x and Vault 1.14.x share the storage format. I hit this exact path last summer on a CE 1.14.7 cluster, and the only sharp edge was the mlock change. The process, condensed:

# 1. Take a snapshot. This is your rollback.
vault operator raft snapshot save vault-pre-migration.snap

# 2. Stop Vault on every node.
sudo systemctl stop vault

# 3. Install OpenBao alongside (separate binary, separate unit).
curl -L https://github.com/openbao/openbao/releases/download/v2.5.0/bao_2.5.0_linux_amd64.tar.gz \
  -o /tmp/bao.tar.gz
tar -xzf /tmp/bao.tar.gz -C /usr/local/bin/

# 4. Point bao at the existing Vault data directory.
sudo install -d -o openbao -g openbao /etc/openbao
sudo cp /etc/vault.d/vault.hcl /etc/openbao/openbao.hcl
sudo chown -R openbao:openbao /opt/vault/data  # or wherever raft lives

# 5. Edit /etc/openbao/openbao.hcl:
#    - remove `disable_mlock = true` if present (OpenBao 2.0+ no longer uses mlock)
#    - rename `api_addr`/`cluster_addr` only if hostnames changed
#    - keep storage path identical so Raft replays cleanly

# 6. Start bao on one node, watch the logs, then expand to the cluster.
sudo systemctl start openbao
bao status
bao operator raft list-peers

Token TTLs, leases, audit-device configs, policies, and KV data come across because they live in the storage backend. The only data that doesn't is anything held in Vault Enterprise-only engines (Transform, KMIP, Key Management). But the OSS Vault you're migrating from didn't have those anyway.

API-driven migration from Vault 1.15+ or Enterprise

For these, the supported pattern is two clusters running side by side, then a scripted re-import of policies, auth method configs, secret engine mounts, and (for static secrets) data. Tools like vault-migrator and homegrown scripts read from the source via the Vault API and write to OpenBao via the identical API. Dynamic secrets are re-bound. You don't migrate the leases, you re-issue them. Plan for an application cutover window where consumers swap from vault.internal to openbao.internal. Because both expose the same Go SDK behaviour, application code doesn't change.

Kubernetes integration: ESO vs Vault Secrets Operator

This is where the two ecosystems diverged most visibly in 2026. HashiCorp ships and maintains the hashicorp/vault-secrets-operator, a first-party Kubernetes operator with custom resources (VaultStaticSecret, VaultDynamicSecret, VaultPKISecret). OpenBao briefly maintained a fork, openbao-secrets-operator, but archived it on February 20, 2026 without ever cutting a release. The decision was to consolidate behind the External Secrets Operator (ESO), which has a stable OpenBao provider and a much broader community.

If you're standing up Kubernetes integration today, the patterns are:

• ESO with the OpenBao or HashiCorp Vault provider. Secrets sync into native Secret objects. Best for legacy apps that read from mounted files or env vars.
• Vault Agent / Bao Agent sidecar injection. Both products ship a mutating admission webhook (Helm chart openbao or vault) that injects an init container which writes templated secrets to an in-pod tmpfs. Best when you need lease renewal and dynamic secrets.
• CSI Secrets Store driver. Secrets mount as files via a CSI volume, with the Vault/OpenBao provider plugin. Works identically against both.
• Direct API + Kubernetes auth. Applications use the Go/Python SDK with the Kubernetes auth method. Cleanest for greenfield Go services.

For a production hardening blueprint of the surrounding pipeline (runners, image signing, the secrets injection layer), see our Linux CI/CD hardening guide. The trap to avoid is using the operator with a service account bound to cluster-admin "temporarily" during setup. That makes the operator a root-equivalent target inside the cluster.

A hardening checklist that applies to both

This list is product-agnostic. Walk it once for whichever you deploy.

1. Listener TLS only. Disable tls_disable = true. Force TLS 1.3 (tls_min_version = "tls13") and a modern cipher list. Re-issue the listener cert from your internal CA, not a self-signed one.
2. Audit devices to two destinations. File + syslog, or file + socket. The cluster refuses requests if all audit devices fail to write. That is a feature, not a bug. Two destinations means an attacker can't disable logging by filling one disk.
3. Root token rotated and revoked. Generate a fresh root only for break-glass with operator generate-root, store the OTP-protected output in a sealed envelope, then revoke. Day-to-day admin uses an admin policy via OIDC.
4. OIDC for human auth. No more userpass for operators. Bind to your identity provider, require MFA at the IdP, and map IdP groups to Vault/OpenBao identity groups.
5. Lease TTLs short by default. default_lease_ttl = "1h" at the system level. Database, AWS, GCP, PKI roles all override down to minutes for short-lived tokens.
6. Auto-unseal with HSM or KMS. Shamir is fine for ephemeral test clusters. Production uses PKCS#11 against a real HSM (or AWS KMS / GCP KMS / Azure Key Vault for cloud-native).
7. Network policy. Only application service accounts and operator workstations can reach 8200/tcp. The unseal-key custodians don't even need network reach to the cluster.
8. Systemd sandboxing. NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes, PrivateTmp=yes, CapabilityBoundingSet=CAP_IPC_LOCK (or empty for OpenBao 2.0+ which doesn't mlock), SystemCallFilter=@system-service. Same unit file works for both binaries.
9. SELinux or AppArmor profile. Both projects publish reference SELinux policy. Enforce mode in production.
10. Backup the raft snapshot off-host. Encrypted with age or GPG, stored on object storage with object-lock enabled. Restore-tested quarterly.

Which one should you choose?

Default to OpenBao if you're a self-hosted user, want OSI-approved licensing, value Linux Foundation governance, or need free Namespaces or HSM auto-unseal. The project is production-ready, GitLab runs it as their CI/CD backend, and there are now multiple commercial support vendors (Adfinis, ControlPlane, Bespinian) if you want a paid SLA without IBM in the loop.

Stay on HashiCorp Vault (and specifically Vault Enterprise) if you need DR replication across regions with automatic failover, Sentinel for policy-as-code governance, FIPS 140-3 validated builds for federal or regulated workloads, or HCP Vault Dedicated as a managed offering. Those are real, specific reasons that OpenBao does not yet answer. The roadmap is heading there, but the dates are not committed.

For greenfield deployments in 2026, my default recommendation is OpenBao. The licensing risk runs the other way. Adopting BUSL Vault today and then needing to back out when your FOSS policy tightens is the more expensive path. Adopting OpenBao and later finding you need Enterprise features is a less painful migration because the API matches both directions.

Frequently Asked Questions

Is OpenBao production ready?

Yes. OpenBao 2.5.0 (released February 4, 2026) is the current stable, and GitLab uses it in production as the native secrets manager for its CI/CD pipelines. It has had five CVEs responsibly disclosed and patched during 2025, and it ships under Linux Foundation / OpenSSF governance, which is a stronger production signal than most newer secrets backends can claim.

Does the HashiCorp Vault Terraform provider work with OpenBao?

Yes, the hashicorp/vault Terraform provider works against OpenBao because OpenBao maintains API compatibility with Vault 1.14. Point the provider's address at your OpenBao listener and existing modules continue to function. There's no guarantee that compatibility lasts indefinitely as the projects diverge, but it holds for OpenBao 2.5 and is expected to hold for the v2.x line.

Can I migrate from Vault Enterprise to OpenBao?

Not as an in-place binary swap. The supported migration path covers Vault Community Edition 1.14.x only. From Vault Enterprise or Vault 1.15+, the practical path is to stand up an OpenBao cluster in parallel and re-import policies, auth methods, and engine configurations via the API. Static secrets can be copied; dynamic secrets are re-issued under the new cluster.

Does OpenBao support Kubernetes Vault Secrets Operator?

No. The openbao-secrets-operator repository was archived on February 20, 2026 without a release. The OpenBao project officially supports Kubernetes integration through the External Secrets Operator (ESO) using its OpenBao provider, along with the Bao Agent sidecar injector and the CSI Secrets Store driver. ESO is the path the maintainers actively recommend.

Is OpenBao under the CNCF?

No, OpenBao is not a CNCF project. It joined LF Edge in April 2024 and was moved to the OpenSSF as a Sandbox project in June 2025. The OpenSSF is a Linux Foundation sub-foundation focused on open-source security, which is a closer thematic fit for a secrets manager than the CNCF would be.

What happened to disable_mlock in OpenBao?

OpenBao 2.0 removed the use of mlock(2), so the disable_mlock configuration directive no longer has any effect and should be deleted when copying a Vault configuration to OpenBao. To prevent secrets being paged to disk, disable swap on the host or use an encrypted swap partition. These are operational controls you should be applying regardless of the binary.