Azure Key Vault or OpenBao: which fits your secrets estate
If your renewal, per-operation bill or data center requirement is pushing you to look at alternatives, the decision mostly turns on where your workloads run and who will operate the service. Azure Key Vault fits best when most workloads sit in Azure, identities already live in Entra ID, and the consumers that read secrets are Azure-native services such as App Service, Functions or AKS with managed identity. In that setup you hand availability and patching to Microsoft, and the integration work is already done. Key Vault is also a reasonable choice when you need Azure services that rely on customer-managed keys, since those keys stay in Key Vault regardless of what else you adopt.
OpenBao fits when secrets have to reach beyond one cloud, into on-premises systems or into air-gapped networks, and when you want the control plane inside your own infrastructure. Its dynamic secrets engines issue short-lived database or Kubernetes credentials that Key Vault does not generate on its own, and its encryption as a service lets applications encrypt data without exposing key material. Auth methods such as AppRole, JWT/OIDC, Kubernetes and TLS certificates let one service cover many environments. The trade-off is that your team owns the servers, storage, backups, upgrades and on-call response. Before committing, confirm that your target storage backend and HA design match your recovery targets, and check which hardware security module option you need for key protection, since Key Vault's managed HSM tier and OpenBao's external HSM support are not interchangeable.
Which option fits which scenario
This table maps common scenarios to the option that usually fits better and the condition under which the other option wins. Read each row against your own identity model, residency rules and operations capacity, since the right answer often depends on one requirement rather than on feature lists.
| Scenario | Better fit | Reason and condition for the other option |
|---|---|---|
| Azure-only application secrets | Azure Key Vault | Managed identity and Entra ID RBAC give Azure workloads access without extra servers to run. OpenBao wins if you need a single secrets service across several platforms or want to avoid per-operation billing at high read volumes. |
| Workloads across Azure and other clouds | OpenBao | One OpenBao service can use auth methods such as JWT/OIDC or Kubernetes for each environment, instead of a separate Key Vault per subscription. Key Vault remains the better fit if nearly all workloads stay in Azure. |
| Database credentials that need dynamic issuance | OpenBao | OpenBao offers dynamic secrets for SQL databases and Kubernetes with leasing and automatic revocation. Key Vault stores static values, so choose it only if credentials can be rotated on a schedule your applications already handle. |
| Customer-managed keys for Azure services | Azure Key Vault | Azure services that require customer-managed keys integrate with Key Vault and Managed HSM directly. Keep those keys in Key Vault and use OpenBao for application secrets, unless you confirm the specific service accepts keys from your own store. |
| Strict data residency or air-gapped requirement | OpenBao | Self-hosted OpenBao runs in your own data centers or isolated networks with no required outbound calls to a vendor control plane. Key Vault is the better fit if Azure regions meet your residency terms and you accept the Microsoft-operated service. |
| Hardware-backed key protection requirements | Depends on HSM design | Compare Key Vault HSM-protected keys and Managed HSM with an OpenBao deployment using an HSM integration. Confirm with the vendor and your assessor which HSM options and certifications apply before choosing. |
| Team with no platform operations capacity | Azure Key Vault | Key Vault needs no servers, upgrades or unseal procedures from your team. OpenBao fits if you can staff operations for HA storage, backups, upgrades and on-call, or contract that work out under a written scope. |
Where the data lives and who controls it
Key Vault keeps secrets, keys and certificates inside Azure regions under Microsoft's operation, while OpenBao runs wherever your team deploys it. The cards below cover the decisions that follow from that difference: where data sits, who operates the service, how identities are trusted, what evidence an assessor will ask for, and which license terms apply to the software you depend on.
Data location and residency
A Key Vault instance is created in one Azure region, and its backups are only restorable within the same subscription and geography. With OpenBao, you choose the location: your own cloud accounts, data centers or an air-gapped network. Map every region, backup location and replica your secrets would touch, including disaster recovery targets. Confirm with your legal team whether any data classes must stay inside a specific country or facility, and confirm where OpenBao's storage backend (integrated Raft or PostgreSQL) will physically reside.
Hosting and operating model
Key Vault is a managed service: Microsoft runs the infrastructure, patching and availability design, and you consume it through the Azure control plane. OpenBao is software your team or a partner installs, configures and runs, including the unseal process, high availability nodes, upgrades and backups. Decide who holds the on-call rotation, who approves upgrades and who tests restores. A quote for a self-hosted build should list these operating tasks explicitly, because they are the recurring cost that a managed service hides.
Identity integration with Entra ID
Applications running on Azure typically reach Key Vault through managed identities and Entra ID role assignments, so no static credential is stored in code. OpenBao offers its own auth methods, including JWT/OIDC, Kubernetes, AppRole, TLS certificates and LDAP. Entra ID workloads can often be trusted through OIDC or JWT, but each workload class needs a mapped policy and a test. Inventory every consumer, then confirm which of them can present an OIDC token and which still depend on a managed identity that OpenBao cannot verify directly.
Compliance evidence and assessment
DeployOpen prepares systems, controls and evidence for compliance assessments, including access logs, key management procedures, backup and restore records and change history. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor early which controls they expect to see evidenced for secrets and key management, and whether Azure's own attestations already cover the Key Vault part of your scope. Those attestations do not transfer to a self-hosted OpenBao deployment.
License terms and governance
In August 2023, HashiCorp moved future Vault releases from the Mozilla Public License 2.0 to the Business Source License 1.1, while its APIs and SDKs stayed under MPL 2.0. OpenBao is a fork that remains under MPL 2.0 and is managed under the Linux Foundation's OpenSSF as a Sandbox project with open governance. Confirm with counsel which terms apply to your planned use, and check the license of every plugin or client library you intend to ship alongside it.
Why dynamic secrets and auth methods change the design
The main design change is that OpenBao can issue dynamic secrets for databases and Kubernetes, each tied to a lease that OpenBao tracks and revokes automatically when the lease ends. Azure Key Vault stores secrets that teams create, version and rotate themselves, and it does not provide dynamic database credentials of this kind. If your applications currently share a static database password held in a vault, moving to OpenBao means deciding which database roles will issue short-lived credentials, how long each lease should run, and how applications renew or re-request credentials before expiry. The OpenBao documentation on dynamic secrets and leasing describes the lease and revocation model, and bulk revocation gives you a way to cut off a compromised set of credentials quickly. Confirm the current Key Vault behavior for your database and rotation scenario with Microsoft before you assume a gap.
Authentication changes as well. Azure workloads often rely on Entra ID managed identities, which Key Vault trusts directly. OpenBao documents JWT/OIDC, Kubernetes, TLS certificates, AppRole, Userpass and other methods, and its guidance is to use Userpass for developer machines and AppRole for servers. For Entra ID workloads, the practical question is whether the workload can present a signed token that OpenBao can verify through the JWT/OIDC method, with roles that map claims such as the tenant, application or resource identity to policies. Each choice needs a test: confirm that the token issuer, audience and claim names match what you configure, and that each application receives only the paths it needs. Check the auth methods reference against your identity provider before you commit to a mapping.
HSM options, throttling limits and availability design
Hardware-backed keys are a tier decision before they are a product decision. In Azure Key Vault, protection by a hardware security module is selected per key, and Managed HSM is a separate, dedicated pool. With OpenBao, the equivalent question is whether your organization will operate or buy an HSM at all. OpenBao can run without one, and the facts we can cite do not establish how it integrates with specific HSM appliances or cloud HSM services, so confirm that with the OpenBao project and your HSM vendor before you design around it. Also confirm which key types you need to protect in hardware, because some Azure services only accept Key Vault-held customer-managed keys, and those stay in Key Vault regardless of your OpenBao decision.
OpenBao high availability uses one active node that holds a lock in the data store, while standby nodes forward or redirect requests to it. The two officially supported HA backends are integrated storage (Raft) and PostgreSQL. Your choice matters for operations: the storage documentation describes PostgreSQL as easier to operate safely than Raft, which shifts effort toward database administration you may already run. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended that to PostgreSQL, so read traffic can be spread across nodes. Writes still go through the active node, so read scaling does not remove the single writer. Review the OpenBao high availability documentation for failover behavior and the exact node counts you need.
Before comparing availability designs, check the throttling limits that apply to your Key Vault vaults and Managed HSM pools in Azure documentation, since these limits are set by Azure and can change. Then measure your own request volume over a representative period, separating secret reads, key operations, cryptographic operations and certificate requests, and note peak bursts from autoscaling fleets or CI pipelines. Those measurements, not a general rule, determine whether a single OpenBao cluster with read scaling is enough or whether you need separate clusters per environment or region. Ask your team to size the cluster against peak load plus failover headroom, and to test a node loss under that load before cutover.
What each option costs and what drives it
Azure Key Vault and self-hosted OpenBao charge for different things. Key Vault bills by operation, key, certificate renewal and HSM tier, while OpenBao moves the cost into infrastructure, storage, operations staff and the time your team spends running it. The cards below list each component, whether it is one-time or recurring, and what to request in a quote.
Key Vault operation and key billing
Key Vault charges per operation for secret, key and certificate requests, and per key version for stored keys. Your bill follows how often applications read secrets, not how many secrets you hold, so a fleet that reads on every request costs more than one that caches values. Check the published Azure pricing for your region and tier, then model read volume from application logs. Ask your team which services call the vault on startup and which call it per request.
HSM tier and protected keys
Keys protected by a hardware security module cost more than software-protected keys in Key Vault, and Managed HSM is a separate pool billed on its own terms. Decide which keys must be hardware-backed by policy or by a regulator's expectations before comparing totals. On the OpenBao side, an HSM is optional and recurs as hardware, support contracts and rack space, or as a cloud HSM service. Ask the vendor for the HSM model, redundancy design and support terms in writing.
Certificate renewal billing
Key Vault certificate issuance and renewal is billed per renewal request from integrated certificate authorities. Renewal volume grows with the number of certificates and with shorter lifetimes, so short-lived certificate designs can raise this line even as they reduce risk. OpenBao's PKI secrets engine moves issuance into your own infrastructure, which shifts cost to the CA design, key protection and operations. Confirm which public CAs you need, since their fees are separate from the platform.
OpenBao servers and storage
Self-hosted OpenBao is paid for in compute, disks and backup storage, normally bought once for hardware or recurring for cloud instances. An HA layout needs several nodes, and the choice of integrated storage (Raft) or PostgreSQL decides how many database systems you run and back up. OpenBao's storage documentation notes PostgreSQL is easier to operate safely than Raft, which can change staffing needs. Ask for the node count, storage class and backup retention behind any estimate.
Load balancing and high availability
Clients need a stable endpoint across OpenBao nodes, which means a load balancer or DNS design, certificates for it and health checks. Since v2.7.0, PostgreSQL standbys can serve read-only operations, so read-heavy traffic can be spread out, but this must be designed and tested. Each region or availability zone you add multiplies these components. Ask who owns the network path and what failover is expected when one zone is lost.
Setup, upgrades and on-call staffing
Setup is one-time: design, migration from Key Vault, auth method rewiring and cutover testing. Recurring costs come from upgrades, security patch cycles, backup restore tests, monitoring and on-call coverage, which is usually the largest line and depends on who is available after hours. Track the OpenBao release notes, since minor lines receive fixes on separate dates. Ask a partner for the fixed scope, the included upgrade cycle and the support hours in writing, and compare that with your own rota.
Who runs it: Microsoft-managed or your team
Key Vault removes servers, storage, patching and high availability design from your team's list. Microsoft operates the service, so your effort goes into vault layout, access policies, managed identity assignments, diagnostic logging and key lifecycle decisions. Most of this work is configuration that is done once per subscription and region, then reviewed on a schedule.
- Setup effort: Vault design, access model, managed identity assignments and network rules, built inside your landing zone and documented for each subscription.
- Recurring effort: Access reviews, diagnostic log routing, key and certificate lifecycle, and checks that soft-delete and purge protection settings match your retention policy.
- Vendor-side operations: Availability, patching and underlying hardware sit with Microsoft under its service terms. Confirm current availability commitments in Microsoft's documentation and your contract.
- Billing: Charges follow operations, keys and renewals, so volume growth appears on the invoice. Model your expected operation counts in your own environment before committing.
- Identity scope: Access is tied to Entra ID and Azure identities. Workloads outside Azure need a separate authentication design.
Before choosing, confirm which Azure regions and subscriptions your data residency rules allow, who on your team owns vault configuration, and what Microsoft's current terms say about availability and HSM options.
Running OpenBao yourself means your team owns installation, high availability, storage, unseal procedures, upgrades, backups, auth method configuration and monitoring. The software is free to use under MPL 2.0, so staff time, infrastructure and on-call coverage become the main costs. Failover in OpenBao depends on an active node holding a lock in the data store, with standbys ready to take over, so the design of that layer needs to be understood before go-live. The OpenBao high availability docs describe the mechanics your team will have to operate.
- Initial build: Cluster design, storage backend choice between integrated Raft and PostgreSQL, TLS, unseal method and auth method setup. This is the largest one-time effort.
- Recurring operations: Following each release, including security fixes such as those in v2.7.1, plus on-call coverage for failover and unseal events.
- Kubernetes path: The OpenBao Helm chart is the documented install route and requires Helm 3.6 or later. Keep chart and server versions under your change control.
- Skills required: Staff who can operate Raft or PostgreSQL, test restores and manage secret lifecycle. This is ongoing hiring or training cost.
- Support path: OpenBao is a community project under the OpenSSF. If you need a contractual support route, confirm who provides it before you rely on it.
Confirm that you can staff an on-call rotation for failover and unseal events, that backups have been restored in a test, and which storage backend and upgrade path your platform team will commit to.
DeployOpen plans, implements, customizes, hardens, backs up, upgrades, documents and supports OpenBao inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Your team keeps ownership of the infrastructure and the secrets, while DeployOpen carries the build and operating work described in the agreed scope.
- Fixed-scope build: Scope, deliverables and timeline are set in writing before work begins. The quote follows from that written scope.
- Retainer for operations: Support, upgrades and testing under a retainer recur over the term. Agree response expectations and release handling in writing.
- Client-side effort: Identity owners supply Entra ID and workload identity inputs, application teams change how they read secrets, and approvers sign off access policy.
- Compliance evidence: DeployOpen prepares systems, controls and evidence for assessments. Independent auditors and certification bodies issue any audit report or certification.
- Handover at exit: Confirm that documentation, runbooks, administrative credentials and data export procedures transfer to your team at close, and what the retainer covers afterward.
Ask for the written scope, the named deliverables, the exclusions in any retainer, and which of your staff must be available during cutover.
What a move from Key Vault to OpenBao involves
The sequence turns Key Vault secrets, keys and certificates into an OpenBao service that your teams operate, with each application moved and checked before Key Vault is retired. Each step ends with a written check so the cutover rests on evidence rather than assumption.
Inventory secrets, keys and certificates by consumer
List every vault, its secrets, keys and certificates, and the applications, Azure services and pipelines that read them through managed identity or service principals. Record the owner, rotation practice and whether each item is a static value, a key or a certificate. The step is done when each item maps to a named consumer and an owner has signed off the inventory.
Confirm what can be exported and what must be re-created
Key Vault backup blobs restore only inside Azure, in the same subscription and geography, so they cannot seed OpenBao. Secret values can be read through the API and written to OpenBao, but keys that are not exportable must usually be re-created and re-issued. Confirm each category with your Azure administrator and document which consumers need a new key or certificate. The output is a migration register with a method per item.
Deploy and harden OpenBao with the chosen storage and HA design
Your platform or security team deploys OpenBao in your own cloud account, data center or air-gapped network, selecting integrated storage (Raft) or PostgreSQL based on the operating skills you have and the OpenBao storage and HA documentation. Set up TLS, unseal method, audit devices, backups and monitoring. The step is complete when a restore test and a failover test have passed and the results are recorded.
Move authentication from managed identity to OpenBao auth methods
Map each Entra ID managed identity or service principal to an OpenBao auth method, such as JWT/OIDC for workloads that can present an identity token, AppRole for servers, or Kubernetes auth for cluster workloads. Write policies that grant the least access each consumer needs. The step is done when a test workload authenticates and reads only its permitted paths, and denied paths fail as expected.
Migrate application by application with dual running
Move one consumer at a time, changing its code or configuration to read from OpenBao while the Key Vault copy remains in place. Run both paths in parallel for a period you set, comparing returned values and error rates in logs. Keep a rollback switch per application. The step is done when each application has run on OpenBao with no unexplained failures and its owner has accepted the change.
Re-issue keys and certificates where export is blocked
For keys that cannot be exported and certificates tied to Azure consumers, use OpenBao's secrets engines or your existing certificate authority to issue replacements, then update trust stores, bindings and dependent services. Coordinate changes with the owners of App Service and other Azure consumers. The step is complete when each re-issued item is in use and the old item is no longer referenced in the register.
Cut over and decommission Key Vault
After every consumer runs on OpenBao, disable writes to Key Vault, keep it readable for a retention window your compliance owner approves, and confirm soft-delete and purge protection settings before deletion. Retain audit records from Key Vault as required. The step is done when a written decommission record lists each deleted vault, the evidence kept, and the approver.
Detailed steps are in the migration guide
The step-by-step procedure, including commands, rollback criteria and cutover order, is covered on the migration page for Key Vault to OpenBao. Read it before planning the work, since it expands each stage above. Confirm all version-specific details against the OpenBao migration documentation for the release you deploy.
Questions buyers ask before switching
Can our team migrate from Azure Key Vault to OpenBao without outside help?
Yes, a team with Linux, networking and Kubernetes or virtual machine operations experience can do it, but the work needs named owners. Someone must own the storage backend, unseal and key custody, backups, monitoring, and the change to every application's authentication. Key Vault secrets are read through the API, so the team must script that export, and keys usually have to be re-created rather than copied. If the team lacks this skill set, DeployOpen plans, implements and documents the migration under a fixed scope agreed in writing before work starts, and a quote follows from that scope.
How long does a migration from Key Vault to OpenBao take?
The supplied sources do not give a duration, so treat any figure you hear, including ours, as a hypothesis until it comes from a written scope. The main drivers are the number of secrets, certificates and keys, how many applications and pipelines read from the vault, and how many of those need their authentication changed from managed identity to an OpenBao method. Keys that must be re-created, and any consumer that depends on a Key Vault feature with no equivalent, add work. Ask for a phased plan with a cutover order for each application group, and check it against a staging copy of your largest vault.
What does running OpenBao cost compared with Key Vault?
Key Vault charges per operation, per key, and per certificate renewal, at Azure's published prices, so its cost rises with request volume and key count. Running OpenBao moves that spend into infrastructure you control: servers or Kubernetes capacity, storage, backups, any optional hardware security module, and the staff time for upgrades and on-call. Most of the infrastructure cost is recurring, while setup and migration are one-time. Your own Azure invoice and request logs show the current baseline. Ask any provider, including DeployOpen, for a quote that lists each component, who pays for it, and what changes with volume.
Can OpenBao verify Entra ID users and workload identities?
OpenBao documents JWT/OIDC among its auth methods, and that is the route to test for Entra ID identities, but the supplied sources do not describe an Entra-specific configuration. Confirm the exact token claims, audience values and role mappings against OpenBao's documentation for the version you deploy, and test them with a real token from your tenant. For servers and automation, the docs recommend AppRole, and for developer machines they recommend Userpass, so an identity provider integration is one option among several. Managed identities used today will need a replacement for each application, which is usually the largest part of the migration.
Do encryption keys in OpenBao need hardware security modules?
No supplied source makes a hardware security module (HSM) mandatory for OpenBao, and whether you need one depends on your policy, not on the product. Key Vault offers HSM-protected key tiers and a managed HSM service, so teams with a contractual or regulatory requirement for HSM-backed keys should confirm the exact options, supported integrations and operational steps in OpenBao's documentation for their version before they commit. Keys in Key Vault that are marked as non-exportable generally cannot be copied out, so plan to re-create them and to update every consumer that uses them. Ask for a written decision on key custody before the design is signed off.
How do OpenBao upgrades work after we migrate?
The OpenBao migration guide covers a node-by-node, in-place upgrade from Vault Community 1.14.1 running on Raft storage with Shamir unseal, and the guide says that path was tested only against that version. Mounts that use plugins OpenBao does not ship are skipped, and new tokens use a shorter OpenBao format, so check both before cutover. Once you run OpenBao, upgrades follow its release line, such as v2.7.1, released October 1, 2026 with security fixes. Test each release in staging, read its release notes, and schedule node-by-node upgrades. DeployOpen offers upgrades and ongoing support as a retainer.
Does DeployOpen issue compliance certifications for our OpenBao deployment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and decide the outcome. In practice, DeployOpen can document how secrets are stored, how access is granted through each auth method, how keys are handled, how backups and upgrades are run, and what logs exist, so your auditor has evidence to review. Ask your auditor which controls and evidence they expect before the engagement starts, and include that list in the written scope.
How DeployOpen helps you evaluate and implement OpenBao
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted OpenBao inside your own cloud accounts, data centers or air-gapped networks. For a Key Vault replacement, that work usually starts with an inventory of what Key Vault holds today: secrets, keys, certificates, access policies, the Entra ID identities and managed identities that read them, and the applications that depend on each. We can also run security testing against the resulting OpenBao deployment and prepare the systems, controls and evidence that your auditors will ask for. DeployOpen prepares that evidence but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
Most engagements are fixed-scope. Before any work starts, we agree the scope, deliverables and timelines in writing. Typical decisions in that scope include which OpenBao auth methods replace each Entra ID or managed identity path, whether storage runs on integrated Raft or PostgreSQL, how the HA design maps to your availability targets, whether an HSM is needed for keys, and how the Key Vault secrets are read out through the API for migration, since Key Vault backups only restore inside Azure. The quote follows from that written scope, so the cost reflects the components you actually choose. Ask us to name each deliverable, the environment it lands in, and the acceptance check for it.
After go-live, ongoing support, version upgrades and continuous testing can be covered by a retainer rather than a new project each time. This matters for OpenBao because releases move quickly, and each upgrade needs a tested path, so confirm the current release line and the upgrade procedure against the OpenBao releases page before you commit to a timetable. Before you request a quote, decide who on your side owns unseal keys, on-call response and access reviews, and ask us to document which of those we run and which stay with your team.
