Vault Fork OpenBao Adds External Keys and Quantum-Ready TLS

OpenBao has released version 2.7, adding read scaling for PostgreSQL-backed deployments, support for external hardware security module (HSM) and key management service (KMS) keys, and post-quantum cryptographic algorithms. The release also introduces control groups for human review of sensitive operations and new headers intended to keep requests consistent across load-balanced OpenBao nodes.

OpenBao began as a community fork of HashiCorp Vault after HashiCorp changed Vault's licence from the Mozilla Public License to the Business Source License in 2023. The project is now governed under the Linux Foundation's Open Source Security Foundation and is distributed under MPL 2.0, an Open Source Initiative-approved licence. Its stated aim is to provide a secrets manager under open governance rather than control by a single vendor.

The fork was both ideological and commercial. Some users objected to the loss of an OSI-approved licence and to the possibility that a vendor could change the terms governing infrastructure they had already adopted. Others saw a practical opportunity: Vault had placed capabilities such as namespaces, HSM integration and advanced scalability behind enterprise licences, while an open fork could make comparable functionality available without those restrictions. The move followed the wider pattern that produced OpenTofu from Terraform and Valkey from Redis.

OpenBao has developed well beyond a simple continuation of Vault Community Edition. Since the fork, the project has added namespaces for multi-tenant isolation, plugin-based auto-unseal integrations, and read scalability for its integrated Raft storage backend. Version 2.7 extends that scaling work to PostgreSQL, allowing standby OpenBao instances using that backend to serve reads in a similar way to Raft-based deployments.

Alex Scheel announced the release for the OpenBao project, writing that it adds "PostgreSQL horizontal scalability, External HSM and KMS-Backed Keys support, and Post-Quantum Cryptography". He also noted that the release arrived after a shorter development cycle than the previous one and included "many substantial features and several major security patches".

The external keys feature lets the PKI and Transit secrets engines use key material held in an HSM or KMS rather than storing it inside OpenBao. Support is delivered through third-party plugins, building on the auto-unseal plugin work in the previous release. This should appeal to organisations that must keep root certification authority keys or other high-value material under hardware control.

The post-quantum work adds ML-DSA and ML-KEM to TLS listeners, certificate authentication, PKI and Transit. Operators can therefore use post-quantum signatures and key exchange in relevant parts of the platform. The change does not by itself make a deployment quantum-safe: clients, certificate authorities and surrounding systems must also support the chosen algorithms. It does, however, give OpenBao users a route to begin testing hybrid and post-quantum configurations.

Control groups add an approval workflow to OpenBao. A new control_group stanza in an ACL policy can require a second party to review access to specified paths. This is aimed at high-risk operations where a single authenticated identity should not be able to act alone.

The release also includes breaking changes. The separate HSM distribution has been discontinued because the PKCS#11 plugin is now externalised. Vendor-specific built-in auto-unseal mechanisms for Alibaba Cloud, AWS, Azure, Google Cloud and Oracle Cloud have also moved to plugins. Kerberos, LDAP and RADIUS authentication, along with the LDAP secrets engine, have moved into the openbao-plugins repository. The file storage backend has been removed; the project had never recommended it for production because it lacks high availability and transactions.

Luca Berton, who interviewed Scheel at Open Source Summit Europe, wrote that external keys allow operators to "run your PKI root backed by an HSM" with key material comparable to Vault Enterprise managed keys. He also highlighted the importance of post-quantum support before government transitions expected around 2030, citing the risk that encrypted traffic recorded today could be decrypted in the future.

Commercial support is also becoming part of the OpenBao ecosystem. ControlPlane launched ControlPlane Enterprise for OpenBao in March, offering security hardening, supply-chain assurance, rapid CVE remediation, optional FIPS 140-3 compliance support and 24/7 technical support. That offering illustrates how an open-source project can remain freely licensed while vendors compete on operational assurance. ControlPlane positions the product as a supported path for organisations that want OpenBao's licence and governance model but still need enterprise-style operational commitments. Its materials also contrast OpenBao's MPL 2.0 licence with Vault's BSL 1.1 licence and note that OpenBao retains API compatibility with Vault for many use cases.

Secrets management being a foundational dependency has been covered in InfoQ recently. We previously reported on Vault 2.0 and IBM's support model following its acquisition of HashiCorp, as well as on the broader pattern of community forks preserving open standards after vendor licence changes. OpenBao's progress suggests that the fork is becoming a credible alternative rather than merely a protest project.

OpenBao version 2.8 is expected to focus more on security and stability, with likely improvements to authentication. For teams evaluating a migration, the immediate questions are less about individual features than about operational maturity: plugin lifecycle management, PostgreSQL high-availability configuration, post-quantum client compatibility and the availability of support for production incidents.