Which Vault Enterprise features OpenBao covers today
A team running Vault Enterprise, or weighing a move to OpenBao to avoid the Business Source License 1.1, needs to know which Enterprise-only features its cluster actually depends on. The answer is not yet a single yes or no. The OpenBao documentation describes namespaces for multi-tenancy within one instance and read-only operations on standby nodes, with Raft standbys supporting this since OpenBao 2.5.0 and PostgreSQL standbys added in 2.7.0. The supplied sources do not confirm parity for performance and disaster recovery replication, HSM seals and the PKCS#11 provider, Sentinel policy as code, control groups, or FIPS-validated builds. Treat those as open questions until the vendor confirms them in writing.
Start with an inventory of the Vault Enterprise license features your cluster enables today. Check the Vault configuration for seal stanzas that point at an HSM or a PKCS#11 library, for replication settings, for Sentinel policies in use, for control group rules on sensitive paths, and for any FIPS-related deployment requirements your auditors expect. Each item on that list either maps to a documented OpenBao capability, needs a vendor confirmation, or needs a redesign. The Vault Enterprise documentation lists the feature set to compare against, and it is the reference you will use to build that inventory.
Also note the tested baseline. OpenBao's migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise. A cluster that relies on Enterprise features should not assume the migration path has been validated for its configuration. Ask OpenBao maintainers or a qualified implementation partner to demonstrate the specific features in a staging environment built from your own configuration, and record the result before any production change. For the full feature-by-feature view and the switching decision, see the overall OpenBao and Vault comparison.
Feature-by-feature status for OpenBao and Vault Enterprise
This table lists Vault Enterprise features the topic covers, what Vault documents for each, and what the OpenBao docs supplied for this page state. Where the OpenBao side has no documented evidence, the cell is a confirmation item, not a yes or no, so treat each one as a question for the project or your own test cluster.
| Feature | Vault Enterprise (documented as licensed feature) | OpenBao (supplied evidence) and what to verify |
|---|---|---|
| Namespaces | Listed as a licensed Enterprise feature for multi-tenancy within one cluster | Documented for secure multi-tenancy within a single instance. Verify the isolation, quota and audit behavior you need in a test cluster. |
| Standby read scaling | Performance standby nodes are a licensed Enterprise feature | Raft standbys serve read-only operations since 2.5.0, extended to PostgreSQL in 2.7.0. Confirm the read consistency model for your workload. |
| Performance and DR replication | Listed as licensed Enterprise replication features | No supplied evidence of an equivalent. Confirm with the project whether any replication mode exists before planning multi-site designs. |
| HSM and PKCS#11 support | HSM support and a PKCS#11 provider are licensed Enterprise features | No supplied evidence in the OpenBao docs for this set. Confirm HSM seal and PKCS#11 support against your HSM vendor and OpenBao release. |
| Seal wrapping | Listed as a licensed Enterprise feature | Not covered by supplied evidence. Confirm whether OpenBao wraps sensitive values for HSM or auto-unseal setups. |
| FIPS compliance | Listed as a licensed Enterprise feature, tied to Vault Enterprise builds | No FIPS build is supplied for OpenBao. Ask the project whether a FIPS-validated build exists and which module versions it uses. |
| Control groups | Listed as a licensed Enterprise feature for multi-approver access | No supplied evidence. Confirm whether approval workflows exist or whether you need an external approval process. |
| Sentinel policy as code | Listed as a licensed Enterprise feature | No supplied evidence. Confirm whether OpenBao policies must be rewritten in HCL alone and what policy-as-code tooling you will use. |
| Redundancy zones | Listed as a licensed Enterprise feature for non-voting cluster members | No supplied evidence. Confirm the cluster topology options for multi-zone deployments. |
| Automated upgrades | Listed as a licensed Enterprise feature | No supplied evidence. Plan upgrades with the OpenBao releases page and your own runbook. |
| Lease count quotas | Listed as a licensed Enterprise feature | No supplied evidence. Confirm whether lease limits exist and how you would enforce them. |
| MFA | Listed as a licensed Enterprise feature | OpenBao documents login MFA among its auth methods. Confirm which MFA methods and policy hooks match your identity provider. |
Factors that decide whether the gap matters
The features OpenBao does not match in Vault Enterprise only matter if your cluster depends on them. Work through these six factors with your Vault configuration, your sites and your auditors before deciding whether the gap is a blocker or a planning item.
Enterprise features in use
Start with an audit of what your cluster actually runs: Sentinel policies, seal configuration, control groups, performance standbys and replication. A feature that is configured but unused is a migration task, not a blocker. A feature that gates a production workflow needs a named replacement or a documented decision to accept the gap. Ask the vendor and your own team to confirm the license state of each feature on your current Vault version.
Multi-tenant namespace needs
OpenBao supports namespaces for secure multi-tenancy within a single instance, a capability HashiCorp documents as part of Vault Enterprise. If you run one cluster for one organization, this gap may never surface. If you isolate business units, customers or regulated workloads inside one cluster, confirm that the OpenBao namespace model covers the isolation, delegation and audit boundaries your design requires.
Cross-site DR replication
Performance and disaster recovery replication are Vault Enterprise features listed as requiring a license on the cluster. If a second site must take over writes or serve local reads under a defined recovery objective, treat this as a hard requirement and design the alternative early. Standby read scaling and PostgreSQL-backed HA are different capabilities and do not replace cross-site replication. Ask how your recovery plan works without it.
FIPS-validated cryptography
If an audit or contract requires FIPS-validated cryptographic modules, the Vault Enterprise FIPS build is a feature to verify, not assume. Confirm with the assessor which validation certificate they accept and whether your deployment needs a validated binary or a validated underlying library. Do not infer validation status from the open-source license or from the OpenBao codebase alone.
Storage backend choice
The storage backend changes which features you can rely on. Integrated storage (Raft) and PostgreSQL are the officially supported OpenBao HA backends, and the OpenBao docs describe PostgreSQL as easier to operate safely than Raft. Raft standbys and PostgreSQL standbys both gained read-only serving in OpenBao 2.7.0 for PostgreSQL. Decide the backend first, then map which Enterprise gaps remain under that choice.
BSL 1.1 licensing exposure
HashiCorp moved future releases to the Business Source License 1.1, and the Vault LICENSE bars competitive hosted or embedded offerings. Most internal operators will not be affected, but a company that embeds Vault in a product or offers managed secrets to customers should have counsel read the license against its use case. Each Vault version converts to MPL-2.0 four years after publication, so the terms apply by release, not uniformly.
How namespaces and standby read scaling compare with Vault Enterprise
OpenBao supports namespaces for secure multi-tenancy within a single instance, and the OpenBao namespaces documentation describes that capability. HashiCorp documents namespaces as part of Vault Enterprise, so teams that rely on them today should confirm which namespace behavior, administrative workflows and policy features they use, then test those exact paths against OpenBao before planning a move. Namespaces separate secrets engines, auth methods and policies for different internal tenants, such as business units or customer environments, inside one cluster. Confirm whether a namespace-per-team model is the right boundary for your audit and blast-radius requirements, or whether separate clusters are simpler to govern.
On the read side, OpenBao has allowed Raft standbys to serve read-only operations since 2.5.0, and v2.7.0 extended that capability to PostgreSQL storage. That gives horizontal read scaling for requests that do not write, using the HA model in which standbys forward or redirect writes to the active node. Vault Enterprise lists performance standby nodes and performance and disaster recovery replication as separate Enterprise features. Those address different needs: standby read scaling spreads load within one cluster, while replication is aimed at multi-site data distribution and recovery. Read scaling does not provide a second site with its own copy of the data, and replication does not replace a sizing review of your read load.
Before relying on either model, check three things in your environment. First, identify which clients generate read traffic and whether they can tolerate reads served by a standby, since replication lag and read-after-write expectations differ by workload. Second, decide whether you need cross-site failover or only in-site throughput, because that decision determines whether Vault Enterprise replication or OpenBao standby reads (or neither, with a separate DR design) is the relevant comparison. Third, record the storage backend you plan to run, because read-scaling support depends on the backend version. Ask any implementation partner to show the failover and read-path tests in writing as part of the scope.
How to confirm feature coverage in your own cluster
This sequence turns a general claim that OpenBao covers Vault features into a documented, tested decision for your own cluster. Each step ends with a written record that a team can review before any migration work starts.
Inventory every Vault Enterprise feature in use
Your platform or security team lists each Vault Enterprise capability your cluster depends on today: the license applied to the cluster, seal configuration, namespaces, performance and disaster recovery replication, policies, Sentinel rules, control groups, FIPS settings and HSM connections. Pull the list from live configuration, server logs and the policies themselves, not from memory. The step is done when every item has an owner and a note on how it is used, and when nothing is left as an unknown.
Map each feature to OpenBao documentation
For each inventoried item, the team checks the OpenBao documentation and the release notes for the exact release line it plans to run, currently 2.7.1 or 2.6.4 as listed on the OpenBao releases page. Mark each feature as documented, partially documented, or not documented, and quote the page or release note that supports the mark. Confirm the migration guide's test scope as well, since it was tested against Vault 1.14.1 community edition and not Enterprise. The step produces a coverage matrix in which every row cites a source.
Build a test cluster on the chosen release
Stand up a non-production OpenBao cluster on the release line your team has chosen, using the same storage backend, seal type and network layout as production where possible. Restore a copy of production data or a representative subset, and replay the policies and auth methods you inventoried. The step is complete when the cluster starts cleanly, unseals as expected, and every auth method and secrets engine in use responds to a test request.
Validate namespaces and read scaling under load
Using the test cluster, your team reproduces the tenant isolation you rely on in namespaces and the read pattern you rely on from standby nodes. Run a load profile drawn from production traffic, including concurrent reads against standbys and writes against the active node. Confirm that namespace policies block cross-tenant access and that standby reads return the results you expect. Record latency, error rates and any redirected requests. The step closes with a load report that compares results to your production baseline, and a note on which storage backend your read scaling depends on.
Confirm HSM and PKCS#11 behavior on real hardware
Virtual or emulated HSMs do not prove that a module behaves the way your hardware does. Connect the actual HSM or cloud KMS device your environment uses, configure the PKCS#11 provider in the test cluster, and run seal, unseal, key rotation and failover scenarios. Ask the HSM vendor which PKCS#11 library version it supports and confirm it against the OpenBao documentation for your release. The step is done when a documented unseal and a forced failover both succeed on the hardware, and any gap is logged with the vendor's response.
Check FIPS requirements with the assessor
Ask your auditor, assessor or internal compliance lead which FIPS 140 requirements apply to your Vault deployment and whether they accept the OpenBao build you plan to run as meeting them. Do not assume that a Vault Enterprise FIPS build has an OpenBao equivalent unless the documentation says so. Record the assessor's written answer, the exact build or artifact in question, and any compensating controls they request. The step is complete when the assessor's position is in writing and attached to the coverage matrix.
Document unconfirmed features as blockers
Any feature that has no confirmed OpenBao replacement, no tested equivalent, or no written assessor acceptance goes onto a blocker register with an owner, a description of the business impact, and the decision needed to resolve it. Options usually include keeping Vault Enterprise for that workload, redesigning the control, or accepting a documented risk. The step is complete when the register is reviewed by the security, platform and compliance owners, and each blocker has a recorded decision or an open action with a named owner.
Where HSM seals, Sentinel, control groups and FIPS builds stand
Four Vault Enterprise features need a separate check before you assume OpenBao can stand in for them: HSM support with the PKCS#11 provider, seal wrapping, Sentinel policy as code, and control groups. The Vault Enterprise documentation lists each of them, along with FIPS compliance, as a feature that requires a license applied to the cluster. The supplied OpenBao material does not show equivalents for any of them. Do not treat their absence from the sources as proof of absence, and do not treat OpenBao as having parity. Ask the OpenBao project, in writing, whether an HSM seal or PKCS#11 integration exists in the release line you plan to run, whether seal wrapping is available for values that must stay protected under a seal, and whether any policy-as-code engine or request approval workflow similar to control groups is planned or shipped.
Sentinel and control groups are policy features, so their replacement is a design decision as well as a product question. Sentinel evaluates rules in Vault Enterprise on top of ACL policies, and control groups hold a request until the required approvers authorize it. If your change approval or four-eyes controls depend on either feature, map each control to what OpenBao can enforce: ACL policy paths, an external policy engine, or a ticketing and approval step outside the secrets manager. Write down the control objective, the evidence an auditor will ask for, and the owner of that evidence before you choose the replacement. This mapping is also the part of a migration most likely to be underestimated.
FIPS is a validation question, not a configuration setting you can verify by reading documentation. Vault Enterprise lists FIPS compliance among its licensed features, and HashiCorp's own validation status for each build is something you must confirm directly with HashiCorp. For OpenBao, ask the project which builds, if any, have been validated under FIPS 140 and which cryptographic module versions they use. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue certifications or attestations. Your assessor or the relevant validation authority decides whether a given build satisfies your requirement, so get that answer in writing before you plan a regulated deployment around it.
Who needs to check which feature
Platform teams own cluster topology, availability targets and upgrade cadence, so replication and high availability are their first checks. Vault Enterprise offers performance and disaster recovery replication and performance standby nodes, which need a license on the cluster. OpenBao's HA model uses an active node holding a lock in the data store, with standbys that forward or redirect requests. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL.
- Replication topology: Confirm whether your current design depends on performance or disaster recovery replication, and whether OpenBao provides an equivalent for your sites.
- Read scaling: Confirm that read-only standby behavior on your chosen backend (Raft or PostgreSQL) meets your query volume, since OpenBao's read scaling differs from Enterprise performance standbys.
- Redundancy zones: Check how your failure domains map to node placement, because Enterprise redundancy zones have no confirmed OpenBao counterpart in the supplied sources.
- Upgrade automation: Confirm how you will upgrade nodes, since Vault Enterprise lists automated upgrades as a licensed feature.
If a replication or redundancy check fails, the migration plan needs a different topology, a separate DR design or a decision to keep Vault Enterprise for that cluster. Confirm details against the OpenBao high availability docs.
Security teams own key custody, seal design, cryptographic module requirements and evidence for assessors. Vault Enterprise lists HSM support, a PKCS#11 provider, seal wrapping and FIPS compliance as licensed features. Before any migration, these teams need to know which of those controls OpenBao provides in the build they will run, and which they must replace or accept as a gap.
- HSM and PKCS#11: Confirm whether OpenBao supports the HSM or PKCS#11 path your key custody policy requires, and whether your HSM vendor supports it.
- Seal design: Confirm how the unseal method, recovery keys and seal wrapping will work after a move, since losing the seal can make a cluster unrecoverable.
- FIPS builds: Ask whether a FIPS-validated OpenBao build exists, and which module boundary and validation certificate apply. The supplied sources do not establish this, so treat it as open until the vendor confirms it in writing.
- Audit and evidence: Confirm which logs, configuration baselines and key rotation records you can produce for an assessor.
If an HSM or FIPS check fails, the plan must either keep Vault Enterprise for regulated workloads or document a compensating control approved by your assessor. Do not present an unverified FIPS claim to an auditor.
Governance teams own policy intent: who may request which secret, which changes need a second approver and how policy is reviewed. Vault Enterprise provides Sentinel policy as code and control groups, which can gate access behind additional approvers. These controls express governance as enforceable rules, so the question for this team is whether OpenBao can reproduce the same rules, or whether the rules must move into a process or another tool.
- Policy as code: Identify which Sentinel policies are in production and what each one enforces, since the supplied sources do not name an OpenBao equivalent.
- Approval workflows: Confirm how multi-person approval for sensitive secret access will be enforced if control groups are not available.
- Policy review: Check how policy changes are versioned, reviewed and recorded, so the governance trail survives the move.
- Exception handling: Confirm who can override a policy in an emergency and how that override is logged.
If a control group or Sentinel check fails, the migration plan needs a replacement control, such as an external approval step with logged evidence, before cutover. Illustrative: a team that relied on a two-person approval rule would need that rule written into a runbook and tested before any production secret moves.
Operators running one platform for many customers need strong tenant isolation inside a shared secrets service. OpenBao documents namespaces for secure multi-tenancy within a single instance, a capability HashiCorp documents as part of Vault Enterprise. This is the feature where OpenBao is closest to Vault Enterprise, but the operator still has to confirm that the behavior matches what their tenancy model and audit requirements depend on.
- Namespace behavior: Confirm that namespace isolation covers policies, auth methods, secret engines and audit scope the way your tenant model assumes.
- Tenant count and quotas: Ask how many namespaces your design needs, and whether lease count quotas, a licensed Vault Enterprise feature, have an OpenBao equivalent.
- Per-tenant auth: Check which auth methods each tenant will use, using the OpenBao auth methods documentation as the starting list.
- Upgrade impact: Test namespace configuration against the OpenBao release you plan to run, since migration testing is documented only against Vault 1.14.1 community edition.
If namespace isolation or quota checks fail, the plan should separate tenants into distinct clusters or keep Vault Enterprise for the multi-tenant service. Confirm details with the OpenBao namespaces documentation before design sign-off.
Questions buyers ask before switching features to OpenBao
Does OpenBao include Vault Enterprise replication?
The supplied documentation does not confirm that OpenBao offers performance or disaster recovery replication under the names HashiCorp uses, so treat replication as unconfirmed until the project states its position. HashiCorp lists performance and disaster recovery replication among the Enterprise features that need a license applied to the cluster, per its Vault Enterprise documentation. What OpenBao does document is high availability with an active node and standbys. Raft standbys can serve read-only operations since OpenBao 2.5.0, and version 2.7.0 extended this to PostgreSQL. Those facts describe read scaling inside one cluster and do not establish cross-site replication. If your design needs secrets available in a second region, ask the OpenBao project for its current position and run a failover test in a lab before committing.
What does moving off Vault Enterprise features cost, and who pays?
The cost has three parts: the engineering to replace or redesign each feature, the run cost of whatever replaces it, and the Vault Enterprise spend you stop or keep. HashiCorp does not publish Vault Enterprise prices and directs self-managed Enterprise buyers to sales, so the license figure must come from your own vendor quote. Your organization or a service provider pays for design, testing and cutover work, while the vendor is paid for licenses and support. DeployOpen works on fixed scope agreed in writing before work starts, and any quote follows from that scope, so the cost depends on how many Enterprise features you use and how each one is replaced. One-time costs include validation, configuration changes and rollback planning. Recurring costs include upgrades, any HSM or KMS you keep, and any retained vendor subscription. Ask for each feature to be priced on its own line.
How long does feature validation take, and what drives that time?
Feature validation has no fixed duration, because it depends on scope, so get the schedule in writing before work starts. The main drivers are the number of Enterprise features in use, whether each one has a documented OpenBao equivalent, and how many storage backends, auth methods and seal types your clusters run. The OpenBao migration guide was tested only against Vault 1.14.1 community edition, so Enterprise-specific behavior needs its own test pass. Time also grows with the number of environments, such as development, staging and production, and with the access your team has to test clusters, including air-gapped networks. Ask the provider for the test matrix, the environments covered and the acceptance criteria for each feature before agreeing a timeline.
Can our team validate OpenBao features without outside help?
Yes, a team with Vault operations experience can run much of the validation in-house, but it needs a lab that mirrors production and one person who owns the acceptance criteria. Start with the OpenBao migration guide and the feature documentation, then build a test cluster that matches your storage backend, auth methods and seal. Gaps tend to appear where documentation is thinner or where behavior has not been checked against Vault Enterprise, so plan extra hands-on time there. Outside help is most useful for independent review of results, hardening and evidence packaging for an assessor. Your team should also confirm open questions directly with the OpenBao project through its public channels. Keep a written record of each test so the decision can be reviewed later by security, audit or procurement.
What should a quote for feature validation include?
A useful quote lists the scope in writing, tying each deliverable to a specific Vault Enterprise feature and its replacement. Ask that it covers:
- An inventory of the features in use, with your current Vault version and edition
- A test plan for each feature, with pass criteria and the person who signs off
- The environments, storage backend, auth methods and seal types included
- Deliverables such as test records, configuration changes and a rollback plan
- Assumptions about cluster access, licenses and staff availability
- Exclusions, including what happens if a feature has no equivalent
DeployOpen works on fixed scope agreed in writing before work starts, so ask for each deliverable to map to a scope line. Confirm any Vault or OpenBao behavior with the vendor or project before relying on it in the plan.
Does OpenBao support HSM seals and FIPS builds?
The supplied facts do not confirm HSM seal support or a FIPS build for OpenBao, so verify both before you plan around them. HashiCorp lists HSM support with a PKCS#11 provider, seal wrapping and FIPS compliance among Vault Enterprise features that need a license applied to the cluster, per its Vault Enterprise documentation. Whether OpenBao offers equivalents, which HSM vendors and PKCS#11 modules it has been tested with, and whether any build is validated under FIPS 140 must come from the project's current documentation and release notes. Whether a FIPS requirement is met is decided by your assessor, who will ask for the validation evidence for the exact module and version you deploy. DeployOpen does not issue certifications, so request that evidence from the vendor and the project in writing.
Does OpenBao cover Sentinel policies and control groups?
The supplied facts do not show OpenBao providing Sentinel policy as code or control groups, so confirm both before assuming a match. HashiCorp lists Sentinel and control groups among its Vault Enterprise features. Sentinel is a policy-as-code layer, so an open-source route usually means rewriting those rules as ACL policies, adding external policy tooling, or moving the logic into applications, and each choice changes where the policy is enforced and audited. Control groups add approval steps before a request completes, so a replacement needs an approval workflow with named approvers and an audit trail. Check the current OpenBao policy documentation, then test an approval flow end to end with the people who will use it. Record the design so an assessor can see how access decisions are made.
When Enterprise feature gaps should decide the platform
A feature gap should decide the platform only when the requirement is written down as a hard control and the team has no workable substitute. Cross-site replication is the clearest case. If a regulator, contract or recovery objective requires a secondary site to hold a live copy of secrets and to take over under a defined procedure, OpenBao's documented high availability model, built on integrated storage (Raft) or PostgreSQL, covers availability inside a cluster but does not give you the performance and disaster recovery replication that the Vault Enterprise documentation lists as a licensed feature. Ask the vendor or your own architecture review to confirm how far a second site can be kept current with OpenBao, and write down the recovery time you need before comparing the two options further.
HSM-backed sealing and FIPS validated cryptography deserve the same test. If your policy names a specific HSM, or requires a FIPS 140 validated module for the Vault binary itself, check what you can actually run. The Vault Enterprise documentation lists HSM support, a PKCS#11 provider, seal wrapping and FIPS compliance as licensed features. Confirm with OpenBao whether its builds and its seal options meet your validation requirement, and whether a cloud KMS auto-unseal path satisfies your key custody rules. If the answer is no and the HSM cannot be replaced, the gap is decisive and the Enterprise license becomes part of the cost model from the start.
The gap is not decisive for a small, single-site cluster that uses only key/value secrets, dynamic secrets for databases and Kubernetes, leasing and encryption as a service, because OpenBao documents all of those. Namespaces, Sentinel policy as code and control groups matter when several business units share one instance or when approvals must gate sensitive reads. In that case, test whether your approval workflow can move to an external ticketing or policy layer. OpenBao is a strong fit for teams that can run it on their own infrastructure and accept the gaps, and an Enterprise subscription is worth buying only when a named control in your register depends on the feature.
How DeployOpen evaluates and implements OpenBao
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so an OpenBao decision is tested against your real Vault Enterprise dependencies before any work begins. Engagements are fixed-scope, with scope and deliverables agreed in writing first.
How we scope
- We inventory which Vault Enterprise features your clusters use today, such as namespaces, replication, HSM seals or Sentinel policies.
- We map each feature to its OpenBao counterpart, a documented alternative, or a gap that needs a decision.
- The written scope names deliverables, timelines and out-of-scope items before any configuration or migration work starts.
- Scope also states which OpenBao release line and storage backend are targeted, and which Vault version is the migration baseline.
How we build
- We build a test cluster in your environment that mirrors the storage backend, auth methods and seal configuration you run.
- We test each identified Enterprise-dependent workflow and record where OpenBao behaves differently or lacks the feature.
- Where a gap is confirmed, we design and document a compensating control, such as separate clusters or external policy tooling.
- Testing covers HA failover and read scaling on standbys, since those behaviors depend on the chosen storage backend.
How we hand over
- Handover includes configuration documentation, runbooks for unseal, backup and upgrades, and a written gap register.
- The gap register records each Enterprise feature, its OpenBao status, the tested version and the owner of any residual risk.
- We walk your operations and security staff through the rollback plan and the evidence needed for internal or external reviews.
- DeployOpen prepares systems, controls and evidence for compliance assessments, but auditors and certification bodies issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover tracking OpenBao release lines, such as the 2.7 and 2.6 series, and testing each upgrade before rollout.
- Ask any provider to confirm feature parity against your exact Vault version and license, since OpenBao's migration guide was tested only against Vault 1.14.1 community edition.
- A quote follows from the written scope, so ask for the scope items that drive effort, including feature count and seal design.
