A platform architect we work with put it directly in a recent design review: "I can defend a European cloud choice to the board. I cannot defend it to my engineers if the technology is worse."
That is the right standard. And it is the standard most "sovereignty stack" conversations fail at. The political case for swapping out US-controlled tooling is easy to write. The engineering case is the one that has to hold up at 3am when something breaks.
This post is a single example of that engineering case holding up — the trade-off log behind choosing OpenBao over HashiCorp Vault as the secrets engine for a European IDP. The headline conclusion is simple: we did not pick OpenBao because it is European-friendly. We picked it because it solved a technical problem Vault does not solve. The sovereignty alignment is the second reason, not the first.
That ordering matters.
The problem
The IDP runs on European infrastructure — Kubernetes on providers without a usable cloud KMS in the AWS/GCP/Azure sense. No KMS service to call out to. No managed HSM next door. Whatever secrets engine ends up in the architecture has to handle the unsealing problem locally, come up cleanly after a node restart, and not require a human to type unseal keys at 3am.
That single constraint did most of the work in the decision.
Vault's unseal model assumes a cloud you do not have
HashiCorp Vault's auto-unseal story is built around cloud KMS providers — AWS KMS, GCP Cloud KMS, Azure Key Vault, or a Transit-mode peer Vault cluster. If you have one of those, the experience is elegant: the seal key lives in the KMS, Vault calls out to decrypt on startup, no operator intervention.
If you do not have one, you have three options, all bad:
| Option | What it costs you |
|---|---|
| Shamir secret sharing (manual unseal) | Operator pages at 3am, every restart |
| Run a second Vault cluster as Transit seal | Doubles your operational surface |
| Plug into a hyperscaler KMS anyway | Undermines the entire reason you left |
For an IDP whose architecture explicitly avoids hyperscaler dependencies, none of these are acceptable. The third is the worst — it imports the exact dependency the platform exists to eliminate.
OpenBao's Static Key Auto-Unseal
OpenBao ships a fourth option. Static Key Auto-Unseal: the unseal key is provided statically — held outside the cluster, mounted at boot via your existing secret-distribution mechanism, rotated on your own schedule. The cluster comes up unattended. No cloud KMS required. No 3am pages.
This is not a feature HashiCorp Vault has. It exists in OpenBao specifically because the on-prem-without-cloud-KMS shape is the European reality — and because a community-governed project can build for that shape without protecting a managed-cloud revenue line.
For our use case, this feature alone would have been enough to pick OpenBao. The licensing story is the second reason.
The licensing story (briefly, because it has been written about elsewhere)
Three facts, all verifiable:
- HashiCorp relicensed Vault to BUSL 1.1 in August 2023. BUSL is source-available, not OSI open source. For internal use the practical difference is small. For procurement, compliance, and any organisation building on top of it, the difference is not small.
- IBM closed its acquisition of HashiCorp in February 2025. Vault is now a closed-source IBM product holding every secret in your cluster. Whatever your view of IBM, this is a governance change worth noticing.
- OpenBao is the Linux Foundation fork of the last MPL-2.0 Vault (the 1.14 branch), governed under the OpenSSF, API and CLI compatible with Vault. Genuinely open in the OSI sense.
For an IDP whose entire reason for existing is to give European organisations a credible path away from concentrated control over their infrastructure, picking the BUSL-licensed IBM product over the Linux Foundation fork would be an interesting position to defend.
Who is actually building this
This is where it stops being just a licensing argument and starts being a sovereignty proof point. The TSC governing OpenBao seats six organisations. Four of them are European:
| Organisation | Country | Role |
|---|---|---|
| Adfinis | 🇨🇭 Switzerland | TSC Chair, six dedicated engineers, Secretz Enterprise commercial offering |
| ControlPlane | 🇬🇧 UK | Sponsors Alex Scheel — #1 contributor, ~37% of project activity, ex-HashiCorp Vault crypto team |
| Wallix | 🇫🇷 France | Listed French cybersecurity specialist, TSC seat |
| SAP | 🇩🇪 Germany | TSC seat via ApeiroRA — EU NextGenerationEU-funded reference architecture for sovereign cloud-edge |
| GitLab | — | Adopted OpenBao as native secrets manager in 18.8 |
| IOTech Systems | 🇬🇧 UK | TSC seat |
The chair is European. The lead contributor is funded by European money — ApeiroRA, co-financed by NextGenerationEU and the German Federal Ministry for Economic Affairs and Energy. Orange endorsed the project for Sylva, their 100%-open-source telco cloud. EdgeX Foundry made OpenBao the default secret store in 4.0.
This is what European industrial policy looks like when it actually ships code.
What we gave up
The ecosystem is younger. The trade-off is real and worth naming:
- Third-party docs and Helm charts still reference Vault branding and the
vaultCLI. API compatibility holds, but every engineer hitting a problem on a Tuesday evening finds Vault answers first and OpenBao answers second. - Disaster Recovery and Performance Replication remain Vault Enterprise-only. If you need cross-datacentre DR replication today, you either wait for the funded roadmap (2026–2027 via ControlPlane/ApeiroRA) or you build the workaround.
- Commercial support is newer. Adfinis launched Secretz Enterprise in February 2026; ControlPlane's offering followed in March. Neither has the ten-year support track record HashiCorp has. Both are real subscriptions backed by core maintainers.
For an IDP whose threat model is "the vendor changes the licence" or "the vendor's parent company is subject to the CLOUD Act," these trade-offs are clearly worth taking. For a regulated bank that needs DR replication tomorrow, the calculation is different. Know which one you are.
The pattern, not the tool
This is the same pattern as Terraform → OpenTofu, Redis → Valkey, Elasticsearch → OpenSearch. A widely-deployed piece of infrastructure software gets relicensed. The community forks under neutral governance. Two to three years later, the question is no longer "will the fork survive" but "is there a reason left to pick the original."
For an on-prem European IDP in 2026, on this specific decision, the answer is no.
The broader lesson for platform teams: every BUSL-licensed dependency in your stack is a future migration. Not an emergency one. But it should be on the audit. If you have not mapped which of your tools are BUSL versus OSI-open-source, that is a 30-minute exercise that will surprise you.
Start here
If you are running Vault on BUSL because "it is what we have always used," you are not alone. Most European platform teams we work with have at least three BUSL or source-available dependencies they have never audited.
A Freedom to Operate Audit maps your full dependency landscape — including licensing exposure — and produces a prioritised migration plan. For the broader strategic context on the licensing wave and what it means for European platform architecture, read Towards European Cloud Independence.
The fork won. The question is whether your stack reflects that yet.