Can OpenBao replace Vault Enterprise HSM auto-unseal?
OpenBao provides a PKCS#11 seal that can unseal the server with a hardware security module, so teams paying for Vault Enterprise mainly to auto-unseal with an HSM have a self-hosted path to evaluate. The catch is that the seal is not expected to carry over from Vault. OpenBao's documentation notes that PKCS#11 auto-unseal was not part of Vault 1.14 open source, so an existing HSM-sealed Vault cluster will likely need a manual data migration rather than an in-place switch of seal type. Many teams in regulated sectors reached this question after the 2023 change to the Business Source License and IBM's 2025 acquisition of HashiCorp, but the technical question is simpler: can your HSM and your Vault data move together?
This page covers how the seal works, which HSMs OpenBao lists as tested, the order in which key material must be created, and what a migration involves. Vault Enterprise HSM support and its PKCS#11 provider are licensed features that need a Vault Enterprise license applied to the cluster, so the cost you are weighing is the license itself. The PKCS#11 seal is distributed as an external KMS provider plugin in the openbao-plugins collection, and built-in use requires an OpenBao build compiled with PKCS#11 support. Read the OpenBao PKCS#11 seal documentation before you plan hardware, since it defines the supported mechanisms and setup steps.
Before committing, confirm three things with your HSM vendor and your OpenBao contacts: that your HSM model appears in OpenBao's tested list and that your firmware and client library match the tested configuration, that the seal's supported mechanisms (AES_GCM and RSA_PKCS_OAEP) are available on your device, and that your key objects can be created in the HSM before OpenBao initializes. Plan the migration as a rehearsal on a copy of the cluster, with the HSM key creation order documented and a tested recovery path, because a failed seal change on production data is the costliest outcome. Ask for a written scope that names the HSM model, the migration steps and the test evidence you will receive.
Mapping Vault Enterprise HSM capabilities to OpenBao
This table compares the HSM and seal-related capabilities of Vault Enterprise with what OpenBao documents, row by row. Read the coverage column as the verified position and the gap column as the item to confirm before planning a migration. The main takeaway is that the HSM seal path is documented for OpenBao but is not expected to carry over from Vault without data migration.
| Capability | OpenBao option | Coverage notes |
|---|---|---|
| HSM auto-unseal | PKCS#11 seal in OpenBao | Documented. Key material must exist in the HSM before initialization, and a Vault HSM seal is not expected to be seal-compatible, so plan a data migration. |
| PKCS#11 provider | PKCS#11 seal distributed as an external KMS plugin, or built into an HSM-enabled build | Built-in use needs an HSM-enabled OpenBao build with PKCS#11 support. Confirm which packaging your deployment will use. |
| Supported HSM vendors | Tested for unsealing: Securosys Primus, Utimaco u.trust GP, Utimaco CryptoServer CP5, DuoKey SD-HSM, Nitrokey NetHSM | Tested list only. Confirm your exact HSM model, firmware and PKCS#11 library version with the vendor and OpenBao before purchase. |
| Key mechanisms | AES_GCM and RSA_PKCS_OAEP | Only these two mechanisms are supported. Check that your HSM policy and existing Vault key setup can use them. |
| Seal wrapping and FIPS compliance | Not confirmed in the supplied documentation | Both are Vault Enterprise features. Verify with OpenBao whether equivalents exist, and do not assume FIPS validation carries over from your HSM or Vault configuration. |
| Integrated storage with HA | Raft integrated storage and PostgreSQL as supported HA backends | Documented. Raft standbys serve read-only operations since 2.5.0, and PostgreSQL gained this in 2.7.0. Confirm the design fits your availability targets. |
Which OpenBao HSM path fits your environment
This path fits teams that want the HSM seal inside the OpenBao binary they already test and deploy, and that can own a custom build pipeline. OpenBao's PKCS#11 seal is distributed as an external KMS provider plugin in the openbao-plugins collection, so built-in use requires an HSM-enabled OpenBao build with PKCS#11 support compiled in. That build becomes your artifact, and your team carries the work of rebuilding it for each security release.
- Build requirement: you must produce and sign an OpenBao binary with PKCS#11 support, then keep that build current with upstream fixes.
- Tested hardware: OpenBao lists Securosys Primus HSM, Utimaco u.trust GP HSM, Utimaco CryptoServer CP5, DuoKey SD-HSM and Nitrokey NetHSM as tested for this seal.
- Key ceremony first: AES_GCM or RSA_PKCS_OAEP key material must exist in the HSM before initialization.
- Recurring work: every OpenBao upgrade means a new build, a repeated verification and a change record.
- Trade-off: tighter integration and one binary, in exchange for ownership of the build chain.
Confirm with your HSM vendor which PKCS#11 library version and firmware they certify for your chosen OpenBao release.
This path fits teams that want to keep the standard OpenBao release and load the PKCS#11 seal as a separate plugin from the openbao-plugins collection. It separates the HSM integration from the core server, so the core binary does not need a custom PKCS#11 build. The plugin still needs to be installed, versioned and tested together with the OpenBao release you run.
- Plugin lifecycle: you track plugin versions alongside OpenBao versions and test the pair before each upgrade.
- Same HSM requirements: key material must be created in the HSM before initialization, and only the AES_GCM and RSA_PKCS_OAEP mechanisms are supported.
- Operational split: platform engineers manage the server, while security engineers manage the HSM partitions and PKCS#11 library on the nodes.
- Packaging: deployment tooling, such as the OpenBao Helm chart on Kubernetes, must place the plugin and library where the server can load them.
- Trade-off: a smaller change to the core binary, with more moving parts to verify together.
Confirm that the plugin version you select is listed as tested for your HSM model before you commit to a design.
This path fits sites that have no HSM, or where an HSM is not yet budgeted, and where the organization accepts Shamir key shares as the unseal method. The migration guide describes an in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and that is the documented route for this case. Unseal keys are held by people, so custody procedures matter more than hardware.
- Key share custody: define who holds each share, how shares are stored, and how many people must combine them to unseal.
- Restart impact: after a restart, an operator must provide enough shares before the cluster serves requests unless you add automated unsealing by other means.
- Lower hardware cost: no HSM purchase, support contract or HSM-specific engineering is needed for the seal itself.
- Audit evidence: you will need records of key ceremonies, share holders and every unseal event.
- Trade-off: simpler to stand up, but the unseal process depends on people being available.
If you later add an HSM, confirm with OpenBao's migration guidance how the seal change affects existing data, because a Vault HSM seal is not expected to carry over without a data migration.
Which HSMs OpenBao lists as tested for unsealing
OpenBao's documentation for its PKCS#11 seal lists five hardware security modules as tested for unsealing. The cards below describe each one in general terms, so you can shortlist devices that fit your deployment before you contact a vendor.
Securosys Primus HSM
The Securosys Primus HSM is one of the five devices OpenBao lists as tested with its PKCS#11 seal. It is a network-attached appliance, so it suits teams that want the unseal key outside the Vault or OpenBao hosts and shared across several clusters. Before procurement, confirm the firmware version, that AES_GCM and RSA_PKCS_OAEP are supported as the seal requires, and which vendor PKCS#11 library your OpenBao build needs.
Utimaco u.trust GP HSM
The Utimaco u.trust GP HSM is listed as tested for OpenBao unsealing. It is aimed at general-purpose key protection in enterprise and public sector settings where a certified appliance is expected. Confirm with Utimaco and the OpenBao test list which firmware and PKCS#11 driver versions were exercised, and whether the device meets the assurance level your assessor will ask about.
Utimaco CryptoServer CP5
The Utimaco CryptoServer CP5 is the second Utimaco device on OpenBao's tested list. It is typically considered for higher-throughput or multi-tenant key custody, which matters if the same HSM also serves other applications. Ask for the exact mechanism list, partitioning model and license terms, because the cost and the shared-use rules affect how many OpenBao clusters one device can serve.
DuoKey SD-HSM
The DuoKey SD-HSM is a smaller device on OpenBao's tested list, and its form factor suits lower-volume or edge deployments with limited rack space. Because its profile differs from enterprise appliances, check that its operational model, backup and key replication options match your recovery plan. Confirm firmware, mechanism support and driver compatibility against OpenBao's current test list before you buy.
Nitrokey NetHSM
The Nitrokey NetHSM is a network HSM on OpenBao's tested list, and it is often evaluated by teams that want open tooling and a compact footprint. It can fit small self-hosted environments, but confirm that its PKCS#11 interface covers the AES_GCM mechanism used for seal key wrapping. Also check how key backup is handled, since losing the only unseal key material means losing access to the data.
Why key material must exist in the HSM before initialization
The PKCS#11 seal requires the key object to exist in the HSM before OpenBao is initialized. The operator creates the key first, confirms it is visible to the OpenBao host through the PKCS#11 module, and only then runs initialization. OpenBao does not generate the wrapping key for you inside the HSM, so the order is a hard prerequisite rather than a recommendation. Confirm the exact key label, slot and token settings in the OpenBao PKCS#11 seal documentation before the HSM team begins, and record them in the change ticket so the configuration can be reproduced later.
The seal supports only two mechanisms, AES_GCM and RSA_PKCS_OAEP, so the key type chosen in the HSM must match one of them. If the wrong order is followed, or the key is created with an unsupported type or policy, initialization fails or the cluster ends up holding encrypted material that cannot be unwrapped with the key that exists. Recovering from that state can mean reinitializing the cluster and losing data, which is why the key check belongs in a dry run on a non-production cluster. Ask the HSM vendor which mechanisms the firmware exposes for the chosen key type, and whether the key can be marked non-extractable.
Key custody is a decision for the HSM team and the security owner, not the platform team alone. Plan who holds the HSM administrator and crypto officer roles, how the key is backed up or replicated across HSM units, and what happens to the key during an HSM replacement or firmware upgrade. Agree on who can disable or delete the key object, since losing it means losing access to the unsealed data. Document the procedure as a runbook and test a restore of the HSM key material before go-live, because the seal cannot recover the cluster without it.
Why a Vault HSM seal does not carry over
The key point is that a Vault HSM seal configuration should not be assumed to carry over to OpenBao. OpenBao's PKCS#11 seal documentation notes that PKCS#11 auto-unseal was not part of Vault 1.14 OSS, so the seal is not expected to be seal-compatible with the Vault Enterprise HSM setup you run today. In practice, that means the encrypted root key and recovery material written under a Vault HSM seal may need to be exported and re-established under the OpenBao seal, and the data itself may need manual migration rather than an in-place switch. Treat the seal change as a planned data migration with its own rollback path, not as a configuration edit.
The migration guide's tested scope is narrow. OpenBao documents a node-by-node in-place upgrade from Vault Community 1.14.1 running on Raft integrated storage with Shamir unseal, and states that this path was tested only against that version. Enterprise clusters are not covered by that testing, so an Enterprise cluster that uses HSM auto-unseal, replication, namespaces or other licensed features falls outside the documented upgrade path. Ask DeployOpen or your own test team to confirm the exact Vault version, storage backend, seal type and enabled features on your cluster, and check each one against that tested scope before you commit to a date.
Before any cutover, run a rehearsal on a copy of production data. Confirm which seal you will use with OpenBao, that the key objects exist in the HSM before initialization, and that the HSM vendor is on OpenBao's tested list for the PKCS#11 seal. Record how mounts using plugins OpenBao does not ship will be handled, since the migration guide says those are skipped. Keep a current Vault snapshot and the existing unseal or recovery keys available until the new cluster has been verified end to end, so a failed seal transition does not leave the secrets unreadable.
Moving from a Vault HSM seal to OpenBao
This sequence takes a team from an HSM-backed Vault seal to an OpenBao cluster that unseals from HSM-held keys, with a documented route, a tested recovery path and a clean client cutover.
Inventory the Vault version, edition and seal
Record the exact Vault version, whether the cluster runs Community or Enterprise, the seal type (Shamir, auto-unseal through the PKCS#11 provider or a cloud KMS), the storage backend and every mounted plugin and auth method. Confirm which HSM model, firmware and PKCS#11 library the cluster uses today. The output is a written inventory that your auditors and the migration team both accept. Ask your Vault administrators to confirm which of these details they cannot read from the cluster itself, such as the license type applied to the cluster.
Confirm which upgrade path applies
OpenBao's migration guide documents a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it was tested only against that version. If your cluster is a later Vault version, runs Vault Enterprise, or uses an HSM seal, the in-place path is not a validated route for you. Treat that as a finding and plan a data migration instead. The output is a documented decision, signed by the platform owner, that names the path and the reason for it.
Provision and test HSM keys in staging
Create the key material in the HSM before OpenBao initializes, because the PKCS#11 seal expects keys to exist first. Use only the AES_GCM or RSA_PKCS_OAEP mechanisms that OpenBao supports, and check that your HSM model appears among those OpenBao lists as tested. Build a staging OpenBao cluster that uses the same HSM model, the PKCS#11 seal plugin or HSM-enabled build, and a copy of the storage configuration. The output is a staging cluster that initializes, seals and unseals against the HSM without manual workarounds.
Choose the in-place upgrade or a data migration
If the source is a supported Community cluster on Raft with Shamir unseal, the in-place upgrade may fit. If it uses an HSM seal, OpenBao notes that PKCS#11 auto-unseal was not in Vault 1.14 OSS and is not expected to be seal-compatible, so a planned data move is usually required. In that case, export secrets through the Vault API, import them into a new OpenBao cluster with HSM-backed keys, and rebuild policies and auth mounts. The output is a written choice of path, with the rollback point defined for each option.
Rehearse the data migration on a copy
Run the chosen migration against a copy of production data in staging. Compare secret counts, policy sets, auth mounts and dynamic secret configurations between source and target, and record any items that did not carry over, including mounts that use plugins OpenBao does not ship. The output is a reconciliation report listing every gap and its owner, which becomes the input for the production runbook.
Validate unseal, recovery and audit
Test a full HSM outage, a node restart and a rotation of the HSM-side key in staging. Confirm that the cluster unseals automatically after restart, that recovery key holders can perform the documented recovery steps, and that audit devices record the expected entries for reads, writes and token creation. Test with a backup of the HSM key material, not only the live key. The output is a signed test record showing each scenario passed or failing, with fixes applied and retested.
Cut over clients and agents
Schedule the production change with a freeze on secret writes, run the migration, and then update clients, Vault Agent configurations, Kubernetes injectors and CI jobs to the new address and the OpenBao token format. Keep the old cluster readable until the new one has served traffic through its full set of workloads. The output is a cutover log in which every consumer is confirmed to read from OpenBao, and the old cluster is retired only after that check passes.
Keeping the HSM, storage and clients working alongside the rest of your stack
Once OpenBao unseals with an HSM, the rest of the cluster still has to run: the HSM partition, the storage backend, the auth methods your workloads use and the telemetry that tells you the cluster is healthy. Each card below is a decision or check that sits between the seal and your existing platform.
Sharing HSM partitions with OpenBao
Your HSM team decides whether OpenBao gets its own partition or shares one with other applications. Confirm that the partition holds the AES or RSA key OpenBao needs, that the PKCS#11 library version on your nodes matches what your HSM vendor supports, and that slot and PIN handling is documented in your runbook. Ask the vendor how the partition is backed up, because losing the key means losing the ability to unseal.
Choosing integrated Raft or PostgreSQL
OpenBao supports integrated storage (Raft) and PostgreSQL as its officially supported HA backends. The OpenBao docs describe PostgreSQL as easier to operate safely than Raft, which matters if your database team already runs HA PostgreSQL. Confirm which backend your team can back up, restore and upgrade on a schedule, and test a restore before you commit.
Standby reads and HA behavior
OpenBao uses an active node that holds a lock in the data store, with standby nodes 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. Confirm which read paths your load balancer sends to standbys and whether your clients tolerate read-only responses during failover.
Auth methods for servers and clusters
OpenBao documents AppRole, Kubernetes, JWT/OIDC, TLS certificates and LDAP among other methods, and recommends AppRole for servers. Map each Vault auth mount your applications use to an OpenBao method, and check that Kubernetes service account roles and AppRole secret ID rotation still work after the cutover. Test each client path in staging before you repoint production workloads.
Monitoring seal, storage and lease health
A seal failure after a reboot can stop the whole cluster, so the HSM connection, unseal status and storage latency need their own alerts. Track lease counts, token creation rates and failed authentications, and send the logs to the SIEM your security team already runs. Confirm which metrics your monitoring stack can scrape and set alerts on the HSM session, not only on the OpenBao process.
What do buyers ask before moving off Vault Enterprise HSM support?
Is OpenBao free to run, and what costs remain?
OpenBao is open source under MPL 2.0, so there is no license fee to pay to the project itself. The costs that remain are the components you run and the people who run them: the HSM hardware and its support contract if you keep HSM-backed unsealing, the servers or cloud instances and storage for the cluster, backups and monitoring, the staff time to operate it, and any third-party support subscription you choose to buy. Vault Enterprise and HCP Vault Dedicated prices are quote-based, so ask HashiCorp for a written quote before comparing. Ask DeployOpen for a fixed-scope quote that lists each of these components separately so you can compare them line by line.
How long does a migration off Vault Enterprise HSM support take?
The duration depends on the cluster and the scope, not on a standard number of weeks. The main drivers are the storage backend and Vault version, whether the cluster uses Enterprise features that have no OpenBao equivalent, the number of secrets, mounts and auth methods, how many applications, agents and Kubernetes injectors must be re-pointed, and whether the HSM seal requires a data migration. OpenBao's migration guide was tested only against Vault 1.14.1 Community on Raft with Shamir unseal, so clusters that differ from that need more analysis up front. Ask for a scoping phase that produces a written plan and timeline before any cutover work is committed.
Does OpenBao's PKCS#11 seal work the same way as Vault Enterprise HSM support?
Not exactly, and you should not assume seal compatibility. OpenBao's PKCS#11 seal requires the key material to be created in the HSM before initialization, and it supports only the AES_GCM and RSA_PKCS_OAEP mechanisms. OpenBao notes that PKCS#11 auto-unseal was not part of Vault 1.14 OSS, so an existing Vault HSM seal is not expected to carry over, and manual data migration may be needed. Compare your current seal configuration, HSM model and mechanisms against the PKCS#11 seal documentation before you commit to a design.
Which HSMs does OpenBao list as tested for unsealing?
OpenBao's documentation lists the Securosys Primus HSM, Utimaco u.trust GP HSM, Utimaco CryptoServer CP5, DuoKey SD-HSM and Nitrokey NetHSM as tested with its PKCS#11 seal. A listed device is not a guarantee for your firmware, PKCS#11 library version or topology, so validate the exact combination in a non-production cluster. Check the vendor's current PKCS#11 provider and the OpenBao PKCS#11 seal documentation before you order hardware or plan a cutover.
Can our own team do this migration in-house?
Often yes for a small, well-documented cluster, but it depends on skills and risk tolerance. In-house teams need working knowledge of PKCS#11 provider configuration, HSM key ceremonies, Raft or PostgreSQL storage operations, Vault and OpenBao auth and policy models, and a tested rollback path. A realistic internal check is whether your team has run a Vault restore or an HSM key ceremony before, and whether someone can own the cutover window. Where those skills are missing, a fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, backup and documentation while your team keeps ownership.
What does the work need from our team?
The engagement needs named owners and time from several groups. Security and compliance staff must approve key custody, the HSM design and the evidence you will keep. Platform engineers must provide the infrastructure, network paths to the HSM and storage. Application owners must confirm which secrets, auth methods and agents change. Operations must agree on a change window, monitoring and an on-call plan. Ask DeployOpen to list these inputs in the written scope so each team knows its commitments before work starts.
Does OpenBao support every Vault Enterprise HSM and related feature exactly?
No. Vault Enterprise lists HSM support and a PKCS#11 provider, along with performance and disaster recovery replication, namespaces, seal wrapping, FIPS compliance, Sentinel policy as code, control groups and other features that need a license. OpenBao documents namespaces, auth methods, storage backends and high availability, but you must map each Enterprise feature you use against current OpenBao documentation and test it. DeployOpen does not issue FIPS validation or certifications. If FIPS or a compliance attestation is required, confirm with the relevant certification body and your assessor which configuration they accept.
What the cost of an OpenBao HSM setup is made of
The main line you avoid is the Vault Enterprise subscription that covers HSM support, but it is not published. HashiCorp's pricing pages direct self-managed Enterprise buyers to sales, so the only number you have is the one in your own renewal quote. Recurring costs on the OpenBao side are the HSM hardware or service, its support contract, the infrastructure for the OpenBao cluster, and staff time for upgrades, monitoring and key ceremonies. One-time costs are the HSM purchase or onboarding, the migration project and any initial hardening. Ask your HSM vendor whether the price is perpetual hardware plus annual maintenance or a service fee, and whether a second unit for disaster recovery is included. Cluster size, the number of HSMs per site and the storage backend drive the infrastructure line.
Staff time is the component most often left out. Someone must create the key material in the HSM before OpenBao initializes, because the PKCS#11 seal does not generate it for you. Someone must also own HSM partition credentials, test unseal after every OpenBao upgrade and rehearse recovery. Estimate those hours from your own team's on-call and change process rather than from a vendor figure. If you choose third-party support for OpenBao, the fee should be stated separately from the HSM contract and should cover the exact versions and HSM models you run. Confirm in writing whether the seal plugin and your HSM model are in the tested list before you accept a scope.
When you request quotes, ask each vendor for the following in writing: the license or service term, what renews and at what cap, support hours and response targets, HSM replacement terms, and any fee for firmware or client library updates. For the migration, ask for a fixed scope covering data export or re-initialization, client re-pointing and a rollback plan, and record which Vault features are out of scope. Compare these quotes against a three-year total of recurring items, not the first invoice. Use the OpenBao migration guide to list the upgrade steps that your scope must include, since it was tested only against Vault 1.14.1 Community.
How DeployOpen scopes and delivers an OpenBao HSM migration
The sequence turns an HSM auto-unseal requirement into a written scope, a tested OpenBao cluster that unseals through your HSM, and a documented recovery path your team can operate. Each step closes with a check you can verify before the next one starts.
Agree the written scope first
DeployOpen and the client agree scope, deliverables and timelines in writing before any work starts. The scope names the Vault version in use, the storage backend, the HSM model and firmware, the clusters in scope and the Enterprise features that must be replaced or retired. A quote follows from this written scope, so the client can see what each line item covers. The step closes when both parties sign off the scope document.
Inventory the current Vault configuration
DeployOpen reviews the existing Vault deployment, including the seal configuration, storage backend, auth methods, secrets engines, plugins, namespaces, replication and any Enterprise-only features in use. The review confirms whether the cluster is on Community 1.14.1 with Raft and Shamir unseal, which is the version the OpenBao migration guide was tested against, or on a later or Enterprise line that needs a different path. The output is an inventory and a gap list that the client reviews.
Create HSM key material before initialization
The HSM team creates the AES_GCM or RSA_PKCS_OAEP key material in the HSM before OpenBao is initialized, because the PKCS#11 seal requires the keys to exist first. DeployOpen confirms the HSM model against the list OpenBao publishes as tested and checks the PKCS#11 library version with the HSM vendor. The step closes when the key objects are listed on the HSM and access rights for the OpenBao service account are confirmed in a test session.
Build and harden the OpenBao cluster
DeployOpen installs OpenBao in the client's infrastructure, using the built-in PKCS#11 seal on an HSM-enabled build or the external KMS provider plugin from the openbao-plugins collection, as the scope specifies. Hardening covers TLS, network segmentation to the HSM, least-privilege service accounts, audit logging and restricted access to the seal configuration. If Kubernetes is the target, the OpenBao Helm chart is used, which requires Helm 3.6 or later. The step closes with a hardening checklist signed by the client's security team.
Migrate data and reconcile clients
Because the PKCS#11 seal is not expected to be seal-compatible with a Vault HSM seal, DeployOpen plans a data migration that reads secrets and policies out through the API and writes them into the new cluster. Auth mounts, policies and secrets engines are mapped one by one, and clients, agents and Kubernetes injectors are re-pointed. The step closes when a reconciliation report shows each secret path, policy and auth mount, with unmapped items listed for client decision.
Test unseal, failover and recovery
DeployOpen tests automatic unseal after a node restart, HSM unavailability and a leader failover on the OpenBao HA backend, then records the results against the scope. The tests also rehearse restoring from backup with the HSM in place and confirm that operators know which HSM credentials and backup material each recovery step needs. The step closes with a test log and a documented recovery runbook that the client's operations team has run at least once.
Hand over documentation and compliance evidence
DeployOpen delivers the architecture document, configuration baseline, runbooks, backup and recovery procedures, and the evidence the client needs for internal or external compliance assessments. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. The step closes when the client accepts the handover in writing.
Continue with a retainer after handover
After handover, the client can keep support in place through a retainer that covers upgrades, security fixes, backup verification and continuous testing of the unseal path. The retainer scope is agreed in writing, and the client decides how often the HSM and recovery tests run. The step closes when the retainer scope is signed or the client confirms it will operate the cluster internally.
