OpenBao security hardening guide

Why OpenBao security hardening starts before the first secret is stored

If your team already has an OpenBao cluster running, or is about to deploy one, the question that matters is not whether it works but what must change from its defaults before production data arrives. The answer is a set of decisions made together, not a checklist applied item by item. TLS on every listener, how the cluster is unsealed and where the unseal material lives, how the initial root token is handled, which policies govern day-to-day access, which audit devices record what happens, and where the nodes sit on the network all shape each other. A weakness in one area reduces the protection of the others, so hardening has to be planned as one design.

Key custody is the decision most often left for later, and it is the one that undermines the rest fastest. If unseal keys or recovery material are stored on the same hosts, in the same cloud account, or in the same configuration repository as the cluster, anyone who can read the cluster's storage can also recover the keys that protect it. Before the first secret is written, confirm where each unseal or recovery share is held, who holds it, how many holders are needed to reconstruct it, and how a share is replaced when a person leaves. Also confirm whether auto-unseal is used, and if so, which key management service holds the wrapping key and which identities are allowed to use it.

Root token handling needs a written answer too. The initial root token is intended for setup, not for operations. Decide who may generate a root token in an emergency, what approval that requires, how the token is revoked afterward, and where the audit trail of that event is stored. Pair this with policies that give humans and workloads only the paths they need. Authentication method choice belongs to a separate identity discussion, but the policy design is part of hardening, and it is easier to write narrow policies before teams start asking for broad ones. Audit devices should be enabled and tested before onboarding, so that a failed write to the audit log is visible and the operator knows whether requests will be refused when logging fails.

Network placement closes the picture. Confirm which clients may reach the API port, which nodes must reach each other for cluster traffic, and whether the storage backend is reachable from anywhere other than the OpenBao nodes. Plan this in your own environment's network terms, including firewall rules, security groups or segmentation, and test that unexpected sources are refused. Validate each of these controls against your own infrastructure and your organization's policy, because the right answer depends on your topology and the storage backend you choose.

This page covers the hardening decisions and the checks that confirm them. It does not cover the rollout plan, a migration from HashiCorp Vault, identity integration, PKI, or dynamic database credentials, which have their own pages. All work described here runs inside your cloud accounts, data centers or air-gapped networks, so the people who approve each control, and the evidence that proves it, stay under your governance. Ask any implementation partner to show the hardening decisions in writing before any production secret is stored.

Which OpenBao components carry the security load

Hardening an OpenBao deployment means setting a small number of components correctly, and most of them fail quietly if left at defaults. The cards below cover each component that protects secrets at rest, in transit, during unseal and during daily use, with the place where a misconfiguration usually appears.

Listener and TLS configuration

The listener is where clients, standby nodes and load balancers connect to OpenBao, so it protects every secret in transit. Check that TLS is enabled on every listener, that certificates chain to a CA your clients trust, that the private key is readable only by the service account, and that the TLS minimum version is set explicitly. Misconfigurations usually appear as clients silently disabling verification or as plaintext listeners left open for health checks.

Seal stanza and key custody

The seal determines how the master key is protected and how the cluster comes back after a restart. Compare Shamir key shares held by named people against auto-unseal through an external key service, and document who controls that service and its access logs. A common failure is an auto-unseal key held in the same account and with the same administrators as the cluster it unlocks.

Storage backend and encryption at rest

OpenBao encrypts secrets before they reach storage, but the storage backend still holds ciphertext, metadata, and the data needed for cluster coordination. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and each needs its own access controls, disk or database encryption, and snapshot handling. Check who can read snapshots and backups, since those copies move outside the cluster's normal controls.

Audit devices

Audit devices record requests and responses so that access to secrets can be reconstructed after an incident. Confirm that at least one audit device is enabled before any client is onboarded, that logs leave the cluster to a store its operators cannot edit, and that the audit configuration is part of change control. The usual gap is a single audit device whose failure blocks requests, or logs that stay on the node where they were written.

Auth methods and policies

Auth methods decide which identities can obtain tokens, and policies decide what those tokens can read or change. OpenBao recommends Userpass for developer machines and AppRole for servers, so review which methods are enabled, remove unused ones, and scope each policy to specific paths and capabilities. Overly broad wildcard paths and shared AppRole credentials are the most frequent findings in policy reviews.

Root token and recovery material

The initial root token and recovery keys grant unrestricted control, so they should be generated for a specific purpose and then revoked or sealed away. Record who holds each recovery key, where it is stored, and the procedure for generating a new root token under dual control. Misconfigurations show up as a root token still active months after initialization, or recovery shares stored together in a shared document.

Which unseal, storage and auth choices fit your hardening goals

This table compares the four choices that set the hardening baseline: how the cluster unseals, where it stores data, how people authenticate and how servers authenticate. Read each row for the situations where an option fits and the operational work it adds, then confirm the details against the OpenBao documentation for your release.

Decision	Option	Operational cost	When it fits
Seal type	Manual Shamir unseal: operators enter key shares after each restart or seal event	Needs trained operators on call to unseal, secure custody of multiple key shares and a tested procedure for reconstituting them	Small or lab environments where tight control over each unseal event matters more than fast recovery
Seal type	Auto-unseal with an external key service that holds the wrapping key	Adds a dependency on the key service and its access policies, plus a cloud or HSM account to set up and monitor	Production clusters that must restart unattended and where key custody sits with a managed key service or HSM
Storage backend	Integrated storage (Raft): data stays inside the OpenBao cluster nodes	Requires snapshot and restore procedures per node, careful handling of node membership changes and disk monitoring	Teams that want fewer external components and can own cluster-level backup and recovery
Storage backend	PostgreSQL: OpenBao uses a database for storage and HA locking	Requires database backup, access control, patching and capacity planning in addition to OpenBao operations; the OpenBao docs describe PostgreSQL as easier to operate safely than Raft	Organizations that already run a hardened, backed-up PostgreSQL service with a database team to support it
People authentication	Userpass: username and password accounts managed inside OpenBao	Lowest integration effort, but account lifecycle, password policy and offboarding become your responsibility	Developer machines and small teams, consistent with the OpenBao recommendation for that use
People authentication	OIDC or LDAP through your identity provider	Requires identity provider configuration, group-to-policy mapping and testing of login and MFA paths	Enterprise access where joiners, movers and leavers are already managed centrally
Server authentication	AppRole with role ID and secret ID delivered to each workload	Needs a delivery method for secret IDs, rotation rules and an owner for each role	Servers and automation, the method OpenBao documents as its recommendation for that use
Server authentication	Other workload methods such as Kubernetes or TLS certificates	Depends on the platform's identity model and extra configuration for each environment	Container platforms or workloads already issued certificates; confirm fit with your architecture team

How to harden an OpenBao cluster in sequence

This sequence moves an OpenBao cluster from default settings to a state where access is restricted, keys are controlled by named people, and every request is recorded outside the cluster. Each step ends with a check the team can run and record. Run the steps in order, because later steps assume the earlier controls are already in place.

Restrict network paths and enforce TLS
The network and platform teams limit which hosts can reach the API and cluster ports, then bind listeners only to the interfaces they need. Each node gets a certificate from an internal authority the organization controls, and both API and cluster traffic require TLS. Confirm this from a host that should not have access: the connection to the API port should be refused or time out. From an approved client, run bao status -address=https://<node>:<api-port> and inspect the chain with openssl s_client -connect <node>:<api-port> -showcerts, which should terminate in your own CA.
Configure auto-unseal or document manual key custody
The platform team decides how nodes unseal after a restart. With auto-unseal backed by a key management service the organization controls, nodes unseal without someone entering keys, but the KMS key and its access policy become critical controls to protect and review. Without auto-unseal, record who holds each unseal key, where it is stored, and how a restart is performed, then rehearse that procedure in a non-production cluster. Check: restart one node in the test cluster and run bao status. With auto-unseal, Sealed should read false without manual input. Without it, the rehearsal should be recorded in the custody procedure.
Lock down the storage backend and its credentials
The database or Raft data directory should be reachable only by the OpenBao service account and by administrators who need it. For PostgreSQL, the OpenBao role receives only the privileges the storage backend requires, and its password is kept out of the plain configuration file where your secrets tooling allows. For integrated storage, restrict filesystem ownership and permissions on the data path. Check: read the data directory as a different local account and confirm a permission error, then query the database role's grants and confirm it holds no superuser or database owner rights.
Initialize with recovery material held by separate custodians
An operator runs bao operator init once, and the recovery or unseal material is split so that no single custodian can rebuild the cluster keys alone. Each custodian receives one share through a channel the team has approved and stores it under their own control. Output is never written to a shared chat, ticket or CI log. The share count and threshold are recorded in the key custody register. Check: bao status reports Initialized as true, and each custodian confirms in writing that they hold one share, with the register matching the threshold chosen.
Revoke or avoid the initial root token
The root token created at initialization is used only to configure the first auth methods and policies, after which it is revoked or not used again. Break-glass access is re-created through the root token generation process documented for your version, which requires the custodian threshold, so emergency access does not depend on a standing root credential. Before revoking, confirm that a named administrator identity can perform the administrative tasks the team needs. Check: after running bao token revoke on the initial root token, run bao token lookup with it and confirm the call fails with an invalid or permission error.
Load least-privilege policies without sensitive wildcards
Policies are written per team and per workload, granting the narrowest capabilities on each path. Wildcard grants are excluded from paths that expose secrets, PKI roots, auth configuration, audit configuration and the sys paths. A reviewer who did not write each policy signs off on it before it is loaded. Check: bao policy list shows only the policies in the approved register, bao policy read <name> for each one contains no broad wildcard on the sensitive paths, and a test token for each workload can read its own path and is denied a neighboring one.
Enable an audit device and ship logs off the cluster
Enable at least one audit device so that authenticated requests and responses are recorded, then forward the audit output to a log system the cluster nodes cannot modify or delete, such as an append-only store or an account controlled by the security team. Confirm in the documentation for your version how audit write failures affect requests, and set the device so the OpenBao process can append entries but not rewrite earlier ones. Check: bao audit list shows the device enabled, a test request produces a new entry in the external log system, and an attempt by the cluster service account to alter an earlier entry fails.
Remove obsolete settings inherited from Vault
Clusters that started on HashiCorp Vault may still carry settings OpenBao no longer uses. OpenBao stopped using mlock in 2.0.0, so disable_mlock must be removed from configuration. Clusters bootstrapped before Vault 1.3 may also need a rekey before the move, as the migration guide describes, so confirm that step was completed. Apply configuration changes through your configuration management, roll them through nodes one at a time, and confirm each node starts cleanly. Check: a search of the configuration repository for disable_mlock returns no results, bao status reports the expected version on every node, and the node logs show no warnings about unknown configuration keys.

How to retire the root token without losing recovery

The initial root token is created when an OpenBao cluster is first initialized, and it can do anything: change policies, mount engines, read every secret and alter audit configuration. It does not expire on its own and it is not tied to a person, so it behaves as a standing high-privilege credential. Retiring it is the step that turns OpenBao from a cluster with a master key into a system where administrative actions are attributable and bounded. The aim of this section is to remove the everyday use of the root token without losing the ability to recover the cluster when identity systems, policies or auth backends fail.

Before revoking anything, build the replacement path. Create administrative policies that follow least privilege, split by duty: one set for managing auth methods and policies, one for mounting and tuning secrets engines, one for reading audit and health status. Bind these to named identities through the auth method you have chosen for people, such as OIDC with group mapping, and confirm that at least two people can log in and perform each duty. Test the policies by attempting the actions you expect to be denied, not only the ones you expect to succeed. Keep the policy files in version control so changes are reviewed like other infrastructure code.

Revoking the root token is a decision to make with a rollback in mind. Verify that audit devices are writing before you revoke, because the revocation itself should appear in the audit log and your team should be able to show who acted. Confirm that the unseal keys or recovery keys are held by the custodians you named, and that each custodian can locate their share. Revocation removes the token, not the ability to generate a new one, but generating a new root token later requires the documented recovery process with a quorum of key holders. Check the current OpenBao documentation for the exact commands and quorum rules for your version (see the resource links) rather than relying on memory or on older Vault guides.

Plan for the two ways break-glass access will be used. A procedure that is rarely exercised is safer to guard, but teams forget its steps, and key holders may not remember how to assemble a quorum at 2 a.m. A procedure that teams run often under incident pressure is easier to execute, but it is more likely to be used when it is not needed. Most regulated teams settle between these by running a tabletop exercise on the recovery path at a fixed interval, and by requiring two-person approval plus a ticket reference for any root generation. Ask your implementation partner or your security team to define which situations justify the procedure and who can declare them.

Write down the procedure in a runbook that is stored separately from the cluster, for example in an offline or independently administered location that custodians can reach during an outage. Record the custodian roster, the quorum threshold, the steps to generate and revoke a root token, the audit log location, the expected verification checks and the contact path for each step. Store unseal and recovery shares in separate custody with documented access, and do not store the root token itself. Review the runbook after each OpenBao minor release, because recovery and key handling details can change between versions, and confirm each change against the release notes before updating your copy.

How hardening changes for single node, HA, Kubernetes and air-gapped clusters

A single node suits a test or small environment, but it concentrates risk. With one server, a failed disk, a bad upgrade or a host reboot stops every application that reads a secret, and recovery depends on the backups and unseal material you kept. Hardening here focuses on recovery discipline more than on cluster controls.

Storage backups: Schedule snapshots of the storage backend, and restore them to a separate host on a cadence your team agrees and tests.
Unseal material custody: Record where unseal or recovery keys are stored, who can reach them, and how many people must agree before they are used.
Restart runbook: Document how the node is unsealed after a reboot, since a sealed node serves no requests until someone acts.
TLS on the API: Terminate TLS with certificates your clients trust. If the configuration came from an earlier Vault cluster, remove disable_mlock as the migration guide requires.
Audit output: Confirm the audit device writes to a location that survives loss of the host.

Confirm the restore time you have actually demonstrated, and whether your applications can tolerate the outage that a single failure causes.

Hardening controls for access, secrets and the audit trail

These controls remain once the baseline is set. Each one limits what a stolen credential, an over-privileged administrator or a lost unseal key can do, and each comes with a check you can run against your own cluster. Confirm the exact behavior for your OpenBao release before you rely on it.

Least-privilege policies per path and role

Write policies that grant only the paths and capabilities each application or role needs, such as read on one KV path for one service. Limit the principals allowed to write policies or mount secrets engines to a short, named admin group, and keep those rights separate from everyday read access. To check, list every policy, confirm that no wildcard path grants broad read or sudo, and test each policy against paths it should and should not reach.

Short token TTLs and leases

Set short default and maximum TTLs on tokens and keep dynamic secret leases brief, so a leaked credential expires soon after exposure. Require applications to re-authenticate when a token reaches its limit rather than renewing it indefinitely. To check, review the configured TTLs on each auth method and secrets engine, confirm that renewable leases have sensible maximums, and test that lease revocation and bulk revocation remove access as expected.

Namespace separation for tenants

Where several teams or customers share one cluster, place each tenant in its own namespace with separate policies, auth methods and secrets engines. Namespace administrators should be unable to change root-level settings. To check, confirm that a policy in one namespace cannot read paths in another, that namespace-scoped admin roles stop at their boundary, and that audit entries identify the namespace of each request. Confirm the model against the namespace documentation for your release.

MFA on login for people

Require a second factor for human logins using OpenBao's login MFA support on the auth methods your people use, such as userpass, LDAP or OIDC. Reserve AppRole, Kubernetes and certificate methods for workloads, since services cannot answer a prompt. To check, confirm that every human-facing method enforces MFA, that enrollment follows your identity provider's lifecycle, and that a break-glass account exists, is documented and has been tested.

Seal and recovery material custody

OpenBao starts sealed, and its encryption key is protected by unseal keys, recovery keys or an auto-unseal key management service. Decide who holds each share or recovery key, where auto-unseal credentials live, and who can administer that key service. Split recovery material across people, store it separately, and log every custody handover. To check, confirm that no single person can unseal the cluster alone and that a recovery drill has been run and documented.

Audit log integrity, retention and alerting

Enable an audit device and send its output to storage that OpenBao operators cannot silently edit. Agree a retention period with your compliance team and confirm that backups of the log stream are covered by the same rules. Alert on root token use, policy and mount changes, seal operations and repeated failed logins. To check, send a test event through the full path to the alerting system and confirm that integrity verification runs on a schedule.

What drives the effort and cost of OpenBao security hardening

This table lists the factors that most change how much work an OpenBao hardening engagement involves, with how each one grows the scope and what keeps it contained. Read each row against your own estimate of environments, teams and controls to see where your scope will sit. The main takeaway is that decisions made early about unseal, policy design and evidence formats usually matter more to effort than the size of the cluster itself.

Driver	How it grows scope	How to keep it down
Number of environments (dev, staging, production, DR)	Each environment needs its own TLS certificates, unseal material, audit devices, policies and tested restore path. Production and DR usually need the most review time.	Keep non-production configuration generated from the same templates as production. Limit DR to the hardening controls it must match, and document the differences in writing.
Number of applications and teams that need policies	Every team and workload identity adds policies, auth roles and test cases. Least-privilege reviews scale with the number of distinct access paths.	Use one policy template per team with parameterized paths. Reuse existing identity groups instead of creating a new group for each application.
Identity provider complexity	Multiple identity sources, nested groups, MFA requirements or inconsistent claims add mapping work and edge cases to test for both people and workloads.	Confirm group names and claim structure with the identity team before configuration starts. Agree a single source of truth for group-to-policy mapping.
Unseal approach and key custody model	Manual unseal with Shamir key shares needs documented custodians and ceremonies. Auto-unseal with a cloud or external key service adds key policy design, access reviews and failure testing.	Pick one unseal model early and document the custody roles. Test seal and unseal recovery in a non-production environment before production cutover.
Storage backend and its backup needs	Integrated storage (Raft) and PostgreSQL each bring different backup, restore and HA testing. Restore testing across environments adds time that scales with backup frequency and retention.	Choose the backend against the operating skills you already have. Define one backup and restore runbook, and test restores on a schedule the team can sustain.
Compliance evidence required	Each control mapped to an assessor's request needs an artifact, such as configuration exports, audit log samples, access review records or change records. Evidence formats often need rework late in the project.	Agree evidence formats and sampling expectations with the assessor or internal audit before work starts. Generate evidence from configuration and logs where possible.
Existing HSM or cloud key service	If you already run an HSM or cloud key service, integration needs key policy, network path and access review. If you do not, the team may need to select and approve a key service as part of the project.	Confirm which key services are approved and whether they support the unseal method you intend to use. Ask whether an existing key policy template can be reused.
Audit device and log destination design	Each audit device, log format and retention target adds validation work. Logs that feed a SIEM need parsing rules and tests to confirm events arrive intact.	Standardize on one log format and destination per environment. Confirm the SIEM team's ingestion requirements before enabling audit devices.

What to monitor, back up and document after hardening

Hardening an OpenBao deployment is a starting point, not an end state. The items below are the signals, checks and records that show whether the controls you set up still hold after the team that built them has moved on.

Audit log volume and failure alerts

Audit devices record every request and response, and if an audit device cannot write, OpenBao can stop serving requests. Track log volume per device, alert on write failures, and confirm that at least one audit device stays enabled in every cluster. Check that log shipping has not silently dropped entries and that sensitive fields remain hashed in the stored records.

Seal status and unseal events

Each node reports whether it is sealed, and an unexpected seal event usually means a restart, a failed auto-unseal call to your key management service, or an operator action. Alert on any node that stays sealed, and record every manual unseal with the operator and reason. Confirm which unseal method each node uses and that the key management dependency is monitored on its own.

Certificate expiry for listener and cluster TLS

Listener certificates serve clients, and cluster certificates secure traffic between nodes in HA. Either one expiring can take the cluster offline or break replication between nodes. Inventory each certificate, its issuer and its expiry date, and alert well before renewal is due. Test that the renewal path, including reloading or restarting the service, works in your environment.

Storage backup and tested restores

A backup of the storage backend is only useful if it restores into a working cluster that unseals with your existing key material. For integrated storage (Raft) and PostgreSQL, schedule backups, keep copies outside the cluster's failure domain, and run restore tests on a schedule. Record how long a restore took and which unseal material it needed, because that is what the recovery runbook depends on.

Root token and recovery material custody reviews

Root tokens and recovery keys should exist only in controlled circumstances, and each holder should be known. Review who holds unseal or recovery shares, confirm that no standing root token remains, and check that revocation was recorded when emergency access ended. Repeat the review on a fixed cadence and after any staff change in the custodian group.

Policy drift review

Policies tend to widen over time as teams request exceptions for urgent work. Compare the live policies and auth role bindings against the approved policy inventory, looking for wildcard paths, broad capabilities and tokens with more policies than their owners need. Confirm that every change went through the agreed review path and that stale roles and unused secrets engines are removed.

Upgrade tracking against release lines and patches

OpenBao publishes minor release lines and patch releases, and the current line changes over time. For example, v2.7.0 was released on September 23, 2026, followed by v2.7.1 on October 1, 2026, with v2.6.4 released the same day for the previous minor line. Track release notes and security fixes for the line you run, test patches in a non-production cluster, and confirm the migration notes before each minor upgrade.

Configuration baseline, custody roster, policy inventory and recovery runbook

Handover needs four records: the configuration baseline showing each node's listener, storage, seal and audit settings; the key custody roster naming every unseal and recovery holder and their backup contacts; the policy inventory listing each policy, its owner and its auth bindings; and a recovery runbook covering seal, restore, unseal and root token steps. Keep them under version control, review them after each change, and test the runbook against a non-production cluster.

How to test that OpenBao hardening works and fails safely

Hardening is only proven when each control is tested against the failure it is meant to stop. For an OpenBao deployment, that means a set of repeatable checks covering TLS, unseal, root token handling, policy boundaries, audit behavior and recovery. Run these checks against a staging cluster built the same way as production, then repeat the important ones after every configuration change, upgrade or node replacement. Record the expected result before you run each test, so a pass means the control did what the design says, not merely that the command returned.

Transport and access checks. Confirm that the listener rejects plaintext HTTP connections and that clients offering deprecated protocol versions or weak cipher suites are refused. Test each client type you actually use, including the CLI, application SDKs, the Kubernetes or CI integrations and any load balancer in front of the nodes. Check that the cluster does not accept client certificates from an unexpected certificate authority, and that node-to-node traffic is also encrypted. Your TLS configuration and accepted cipher lists should be confirmed against the OpenBao configuration reference for the exact version you run, since defaults change between releases.

Seal, restart and recovery checks. Restart one standby and then the active node, and confirm each returns through the intended unseal path. If you use auto-unseal with an external key management service, the node should come back without a manual key entry, and you should test what happens when the key service is unreachable at startup. If you use Shamir key shares, confirm that the required threshold of custodians can unseal the node and that no single custodian can do it alone. Sealing a node on purpose in a drill is the only reliable way to see whether monitoring alerts fire and whether your runbook matches reality.

Root token and recovery checks. Confirm that the initial root token has been revoked once administrative accounts and policies are in place, and that no automation still depends on it. Then run a recovery drill: generate a recovery token or use the documented recovery key process with the custodians who would actually be called, and time how long the steps take in your environment. Do not assume the recovery path works because it is written down. Record who holds each key share, how they are reached out of hours, and where the drill evidence is stored.

Policy and audit checks. Using test identities bound to each role, attempt to read and write paths outside each policy's scope and confirm that every attempt is denied. Include wildcard paths, list operations and access through alternative auth methods, since these are common gaps. Then confirm that each request produces an audit record with the expected identity and path. Test the failure mode deliberately: with one audit device unavailable, verify whether requests are blocked as your documented design requires, and check that you are alerted before that happens in production. Confirm this behavior against the audit device documentation for your version rather than relying on memory.

Failover, restore and incident rehearsal. Stop the active node and confirm that a standby takes over, that clients reconnect without manual intervention and that no writes are lost. For Raft or PostgreSQL storage, restore a backup into an isolated environment and verify that secrets, policies and audit configuration come back intact. Finish with a tabletop or live exercise that simulates a suspected leaked token, and time the revocation steps. Each exercise should end with a short list of gaps, an owner for each gap and a date for re-test.

Questions teams ask before hardening OpenBao themselves or hiring help

How much effort does hardening an OpenBao cluster take?

Effort depends on scope more than on the product itself. The main drivers are the number of nodes, the storage backend (integrated storage with Raft or PostgreSQL), the unseal approach and whether an external key manager is involved, the number of auth methods and secrets engines in scope, and whether you are migrating an existing Vault cluster. Network zones, change windows and the number of applications that need policy redesign also add work. Ask for a written scope that lists each item separately, so you can see which parts are one-time work and which parts recur.

Can our team harden OpenBao alone using the official documentation?

Yes, many teams can, provided they already run TLS, key management and Linux service hardening well. The OpenBao documentation covers configuration, auth methods, storage and high availability. It does not map those settings to your control framework, your network design or the evidence your auditor will ask for. Plan time for failover testing, policy review, root token and recovery key procedures, and runbooks. Have a second engineer review the custody steps, since mistakes there are hard to reverse.

What does our side need to provide for an OpenBao hardening engagement?

Expect to provide five things. First, identity provider access, such as a test application registration, metadata and the group claims you want mapped to policies. Second, key custody decisions: who holds unseal or recovery keys, and whether auto-unseal uses a cloud key service or an HSM. Third, network change windows for TLS and listener changes, which can interrupt clients. Fourth, named custodians who own key ceremonies and root token procedures. Fifth, access to the hosts, cloud accounts or data center networks where OpenBao runs, plus a test environment that matches production.

Does hardening OpenBao make us compliant with SOC 2 or PCI DSS?

No. Hardening prepares systems and controls and produces evidence, such as configuration baselines, audit device logs, access reviews and change records. Your assessor can then examine that evidence against the control IDs in scope. Whether you are compliant is decided by an independent auditor or certification body. DeployOpen does not issue audit reports, attestations or certifications. Agree the control mapping and evidence list with your auditor before work starts, so the hardening output matches what they will test.

How does an OpenBao hardening engagement differ from a vendor-specific hardening guide?

A vendor guide for a commercial product usually assumes that product's packaging, support channel and licensed features. OpenBao is an open source project under MPL-2.0 with no paid edition, so its hardening starts from its own documentation and from your environment. The work covers your configuration, your storage choice, your identity provider and your network. DeployOpen is not an official partner, reseller or certified provider of any vendor, and the engagement is scoped in writing. Ask any provider to show which OpenBao version and documentation their steps follow.

How do we keep OpenBao hardening current after upgrades?

Treat hardening as tied to a specific version. Each release can change behavior, so review the release notes for the line you run before upgrading. For example, OpenBao 2.7.0 extended read-only standby operations to PostgreSQL, which can change how load balancers route reads. After each upgrade, rerun your baseline checks, then retest TLS, unseal, failover and audit logging. Record the results as evidence. Ongoing upgrades, support and continuous testing can be covered by a retainer, or your own team can run the same checks on a schedule.

Should we hire help or harden OpenBao ourselves, and what will it cost?

The answer depends on in-house skills, available engineer time and your tolerance for setup mistakes. The cost has three parts: internal engineer time, any external fee (which follows from a written, fixed scope), and recurring costs such as infrastructure, key management for unsealing and the people on call. Most hardening effort is one-time, while monitoring, upgrades and retesting recur. There is no license fee for OpenBao itself under MPL-2.0. When you ask for a quote, request a breakdown by workstream, the deliverables for each, the responsibilities on your side and the items that are excluded.

How DeployOpen scopes, builds and hands over OpenBao hardening

DeployOpen approaches OpenBao security hardening as a fixed-scope engagement, starting from a written list of controls and the workloads that depend on them. The work runs inside your own cloud accounts, data centers or air-gapped networks, and covers TLS, unseal and key custody, root token handling, policies, audit devices and network isolation.

How we scope

Confirm the OpenBao version, storage backend and node layout before any hardening changes are planned.
Record which auth methods, secrets engines and client workloads must keep working after hardening.
Agree the written scope, deliverables and timeline before work starts, since engagements are fixed-scope.

How we build

Configure TLS for listeners and cluster traffic, with certificate sources and rotation agreed up front.
Set up auto-unseal or key custody against the key management system your team already operates.
Replace broad tokens with least-privilege policies, then test each policy against the workloads that use it.

How we hand over

Document root token handling, including how initial root material is stored, used and revoked after setup.
Deliver audit device configuration, network isolation rules and a record of each control tested.
Provide an operations runbook covering unseal procedures, key custody roles and change control steps.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Re-check hardening settings when you move to a new OpenBao minor release line or apply security patches.
Ask whether a retainer covers configuration review, upgrades and periodic testing before signing.