OpenBao Shamir unseal vs auto-unseal: which fits your cluster
An OpenBao cluster must be unsealed after every restart, so the real decision is who or what holds the unseal capability. Shamir unseal fits sites where trained people are reliably available to enter key shares, restarts are infrequent, and there is no dependable cloud KMS or HSM to rely on. Auto-unseal fits environments with automated restarts, a need for unattended recovery, or a cloud KMS or HSM already in place. The OpenBao seal documentation states that auto unseal is usually easier because manual Shamir unsealing is hard to automate, which matters most when nodes restart during patching, scaling or host failures outside business hours.
The default Shamir seal splits the unseal key into shares, and a threshold of those shares rebuilds it. Each node must be unsealed separately after every restart, so the share holders become a standing operational dependency. Auto-unseal instead delegates protection of the unseal key to a trusted device or service, such as a cloud KMS or an HSM, which decrypts the root key at startup. Initializing with auto-unseal returns recovery keys rather than unseal keys, and those recovery keys authorize quorum operations such as generating a root token. Confirm with your team which system will hold the seal, who can administer its keys, and how that dependency behaves during a network partition in an air-gapped or segmented site.
The trade-off is recovery. The OpenBao docs warn that if the auto-unseal mechanism or its keys are permanently deleted, the cluster cannot be recovered, even from backups. With Shamir, losing enough shares carries a similar risk, so either way the seal material needs documented custody, tested recovery procedures and a clear owner. Before you choose, ask your vendor and your own platform team to walk through a full loss scenario for your chosen seal, and check how recovery keys and key shares will be stored, rotated and tested in your environment. The recovery trade-off is covered in more detail below.
How OpenBao Shamir unseal and auto-unseal differ by factor
This table compares the two ways an OpenBao cluster gets unsealed after a restart, factor by factor, from who holds key material to recovery after a lost seal. Read each row as a question to answer for your own environment, and treat the confirm items as the points to settle before choosing. The main takeaway is that Shamir shifts operational burden onto people, while auto-unseal shifts it onto the KMS or HSM and the keys protecting it.
| Factor | Shamir seal | Auto-unseal through cloud KMS or HSM |
|---|---|---|
| Who holds the key material | People hold unseal key shares; a threshold of them is needed to rebuild the unseal key | A cloud KMS or HSM holds the key protecting the root key; no person needs to enter shares at startup |
| What happens after a node restart | Each node stays sealed until enough key shares are supplied to unseal it separately | The node asks the configured KMS or HSM to decrypt the root key and unseals without a manual step |
| How automation works | Hard to automate, since unsealing depends on people supplying shares at the right time | Usually easier to automate, since startup depends on the device or service being reachable and authorized |
| What initialization returns | Unseal keys, which the operator distributes to key holders | Recovery keys, which authorize quorum operations such as generating a root token but cannot decrypt the root key |
| What the cluster depends on at startup | Available key holders and a correct threshold of shares | Network reachability to the KMS or HSM and valid credentials for that service |
| Recovery path if the seal is lost | Recovery depends on enough unseal key shares still existing and being held securely | If the auto-unseal mechanism or its keys are permanently deleted, the cluster cannot be recovered, even from backups |
| Fit for air-gapped sites | Generally the default fit, since it needs no external key service; confirm your ceremony and custody process | Depends on whether an on-premises HSM or other reachable key service is available inside the isolated network |
| What to confirm in your environment | Who holds each share, how many are needed, where shares are stored, and how rotation works | Which KMS or HSM, who controls its keys, deletion protection, and whether recovery keys are stored and tested |
What Shamir shares, auto-unseal keys and recovery keys each protect
An OpenBao cluster starts sealed, and the seal method decides who or what can open the root key after a restart. Each card below covers one piece of that arrangement, so you can see which keys people hold, which keys a cloud KMS or HSM holds, and what recovery keys can and cannot do.
Unseal key shares and threshold
With the default Shamir seal, the unseal key is split into shares and a set number of them must be combined to rebuild it. No single share opens the cluster, so the threshold is the control that matters. Confirm how many holders you will name, how many must be present to unseal, and where each share is stored outside the cluster.
Per-node unseal after every restart
Under Shamir sealing, each node must be unsealed separately after it restarts, so a restart or failover needs people to supply shares again. This is the operational cost that auto-unseal removes. Plan who is on call to perform unseals, and test the procedure during a planned maintenance window before you need it in an incident.
KMS or HSM holding the root key wrapper
With auto-unseal, a trusted cloud KMS or HSM decrypts the root key at startup, so the unseal step becomes automated. The protection now rests on that key service, its access policies and its availability. Confirm which key service you will use, who can administer it, and whether your site can reach it when the cluster restarts.
Recovery keys returned at initialization
When auto-unseal is initialized, OpenBao returns recovery keys in place of unseal keys. These authorize quorum operations such as generating a root token but cannot decrypt the root key. Store them with the same care as Shamir shares, and confirm which operations your runbooks will need them for.
Loss of the seal makes recovery impossible
If the auto-unseal mechanism or its keys are permanently deleted, the cluster cannot be recovered, even from backups. This is the largest risk in the auto-unseal design. Ask who can delete or disable the KMS key, enable deletion protection, and document the key's location in your disaster recovery plan.
Air-gapped sites and reachable key services
A site without outbound access may not be able to reach a cloud KMS, which pushes the design toward Shamir shares or an on-premises HSM. Confirm whether your environment offers an HSM option for auto-unseal, and whether your shareholders can reach the site during an outage. Validate both before choosing the seal.
Where OpenBao auto-unseal fits air-gapped, cloud and HSM sites
On a network with no route to a cloud KMS, auto unseal only works if the protecting device or service sits inside the same isolated boundary. Without one, the Shamir seal is the default path: the unseal key is split into shares, and a threshold of share holders must provide their shares after every restart of each node. The operators who hold those shares are the real dependency, so the seal design is also a staffing and custody design. Shares should be stored separately, with named custodians and a documented procedure for reaching the threshold at 2 a.m. without the person who usually does it.
- Custodian roster: Confirm how many shares exist, how many are needed, and who holds each one, including backups for people who leave or travel.
- Restart procedure: Write down exactly how each node is unsealed, in what order, and who must be physically or remotely present.
- Offline recovery material: Store recovery material in sealed, access-logged locations that do not depend on the cluster being up.
- Internal protector: If you run an HSM or an internal key service inside the enclave, confirm that its own backup and availability plan is documented before you rely on it.
- Version check: Confirm which seal types your OpenBao release supports and whether the offline device is on the list.
Before you commit, ask your security team whether the enclave can host a protector that has its own backup, and whether your custodians can meet the threshold without outside help.
A cluster in a cloud account that can reach a managed KMS can use auto unseal, so restarts no longer wait for people. The trade-off is a runtime dependency: if the KMS key is disabled, deleted, or unreachable from the nodes, the cluster cannot unseal, and the OpenBao docs warn that permanent deletion of the auto-unseal mechanism or its keys makes the cluster unrecoverable, even from backups. Initialization then returns recovery keys, which authorize quorum operations such as generating a root token but cannot decrypt the root key. Recovery keys therefore need the same custody discipline as Shamir shares.
- Key deletion protection: Confirm the cloud provider's controls for scheduled deletion, disabling, and key rotation, and who is allowed to change them.
- Recovery key custody: Decide who holds recovery keys, where they are stored, and how they are used for quorum operations.
- Account separation: Ask whether the KMS key lives in an account or project that a single administrator can destroy along with the cluster.
- Network path: Confirm that every node can reach the KMS endpoint during startup, including through egress rules and private connectivity.
- Backup scope: Check that backups do not depend on the same key alone, since the docs state backups cannot recover a lost seal.
Ask your cloud team which key policy, deletion waiting period, and break-glass access path apply to the seal key, and test a restart before go-live.
An on-premises hardware security module can act as the protector for the unseal key, so the device, not a person or a cloud account, decrypts the root key at startup. The device becomes a custody question as much as a technical one: it holds key material that must survive hardware failure, and the cluster depends on it being reachable every time a node restarts. Ask the vendor how keys are generated, exported or wrapped for backup, how a replacement device receives them, and what the failover path is when the HSM is offline or under maintenance.
- Key custody model: Ask whether keys can be exported in a wrapped form for backup, and who authorizes that export.
- Replacement path: Confirm how key material moves to a replacement device and how long that procedure is expected to take in your environment.
- Availability design: Ask about clustering or replication of the HSM, and whether nodes can unseal during a device outage.
- Administrative access: Identify who can administer the HSM, and whether that group overlaps with the people who run OpenBao.
- Vendor support terms: Confirm support hours, firmware update policy, and escalation contacts in the written agreement.
Before you purchase or configure hardware, ask the vendor for its key backup and replacement documentation, then confirm with the OpenBao seal documentation that your release supports the HSM seal you plan to use.
Operating each unseal model: restarts, key custody and skills
This table compares what each unseal model asks of the operations team after a restart, during key rotation, while monitoring and during upgrades. Read each row as the operating burden you would carry, then check it against your own change control and custody rules. The main takeaway is that Shamir shifts the burden to people and ceremonies, while auto-unseal shifts it to the cloud IAM or HSM administration that protects the unseal path.
| Operating area | Shamir unseal | Auto-unseal (cloud KMS or HSM) |
|---|---|---|
| Node restart runbook | Each node must be unsealed separately after every restart, so the runbook needs enough key holders reachable at that moment | Nodes unseal at startup through the configured KMS or HSM, so the runbook focuses on confirming the seal service is reachable |
| Key custody | Key shares are held by named people who must keep them safe and available, and custody gaps directly delay recovery | Recovery keys are returned at initialization and must be stored with the same care, while the protected key path sits in the KMS or HSM |
| Key rotation | Rotating the unseal key means a new key ceremony, redistributing shares and retiring old copies | Rotating the seal key depends on the KMS or HSM provider's key lifecycle, so confirm how OpenBao handles the transition in your version |
| Seal status monitoring | Monitor which nodes are sealed and track how many shares are still needed, since a missing share stalls the cluster | Monitor the seal service itself, including access errors and key state, because a failed call can leave nodes unable to start |
| Skills the team needs | Key ceremony discipline, secure share handling, and clear escalation for key holders who leave or change roles | Cloud IAM or HSM administration, least-privilege policies for the unseal identity, and knowledge of the provider's key deletion safeguards |
| Upgrades | Upgrades that restart nodes trigger manual unseal steps, so the change window must include key holders | Upgrades that restart nodes still depend on the seal service, so the change window must include a seal reachability check |
| Node replacement | A new node joins only after someone supplies enough shares, so replacement needs the same ceremony as a restart | A new node unseals through the same KMS or HSM path, so replacement depends on the IAM policy and key access being in place |
| Loss of the seal | If shares fall below the threshold, the cluster cannot be unsealed, so custody planning must prevent that loss | If the KMS or HSM key is permanently deleted, the cluster cannot be recovered even from backups, so key deletion controls are critical |
Planning the seal before the first OpenBao initialization
This sequence settles who holds unseal or recovery authority, where that material lives, and whether the team can recover the cluster before any production secret is written to it. It ends with a tested restart and recovery on a non-production cluster and a documented, approved plan for the production initialization.
Choose the seal model from the threat model
The security lead and the platform owner decide between Shamir key shares and auto-unseal, using the threat model and the network design. Shamir keeps the unseal authority with named people and needs no external key service. Auto-unseal hands protection of the unseal key to a cloud KMS or HSM, so the team must confirm that service is reachable from every node, including after an outage elsewhere in the network. The output is a short decision record that names the model and the reason for it.
Name the key custodians or the KMS owner
For Shamir, record each person who will hold a key share, the number of shares, and the threshold needed to rebuild the key. Confirm that no single custodian can meet the threshold alone and that replacements exist for absences. For auto-unseal, name the team that owns the KMS key or HSM, who can change its access policy, and who approves key deletion. The output is a named roster or ownership record that the security lead signs off.
Document the unseal and recovery procedure
Write the runbook for an unseal after a node restart and for recovery operations that need quorum, such as generating a new root token. For auto-unseal, state that initialization returns recovery keys rather than unseal keys and that recovery keys cannot decrypt the root key. Record where each piece of recovery material is stored, who can retrieve it, and how access is logged. The output is a reviewed runbook stored outside the cluster it protects.
Protect the seal against permanent loss
Set controls so the unseal key, the KMS key, or the HSM partition cannot be deleted or disabled by a single administrator. The OpenBao seal documentation warns that if the auto-unseal mechanism or its keys are permanently deleted, the cluster cannot be recovered, even from backups. Confirm the key deletion waiting and approval settings in the KMS or HSM product, and keep an independent copy of the recovery path. The output is a written control list with an owner for each item.
Rehearse a restart and a recovery
Build a non-production cluster with the same seal model, storage backend, and network paths as production. Restart one node, unseal or confirm auto-unseal, then simulate a recovery operation using the documented procedure with the actual custodians or KMS roles. Time each step only to find bottlenecks, and record every point where a person had to guess. The output is a test log with any runbook corrections made before production use.
Confirm the seal choice with your vendor or platform team
Before the production initialization, ask the OpenBao project or your support provider to confirm how the chosen seal can be changed later, what migration steps apply to your OpenBao version, and whether any step requires downtime. Because the seal choice is made at initialization, treat any later change as a planned migration that needs its own test. The output is written confirmation filed with the decision record.
Initialize production only after sign-off
Run the production initialization once the decision record, custodian or KMS roster, runbook, and rehearsal log are approved. Store the returned recovery or unseal material according to the runbook and record who witnessed the step. Confirm that every node reports the expected seal state and that the restart test passes against the production cluster in a controlled window. The output is an initialized cluster with a signed record of the seal configuration.
The unrecoverable-cluster risk if the seal is lost
The most serious failure mode in this comparison is losing the seal itself. The OpenBao seal documentation warns that if the auto-unseal mechanism or its keys are permanently deleted, the cluster cannot be recovered, even from backups. Backups of the data do not help, because the root key that protects that data can only be decrypted through the cloud KMS key or HSM key that was lost. For an auto-unseal design, the first decisions are therefore about the KMS key or HSM object itself: who may schedule its deletion, whether deletion is blocked by a waiting period or a restricted policy, and whether the key is protected against accidental removal by automation or by a team member with broad administrative rights. Confirm the exact deletion and waiting-period behavior with your KMS or HSM vendor, since the answer differs between providers.
Cross-account and cross-region copies of the key are a common mitigation, but they add their own questions and should be treated as open decisions rather than defaults. Ask whether the platform supports a replica or multi-region key, who controls each copy, whether a copy in another account can be used by the cluster without giving that account rights over production data, and how a failover would be tested. Also confirm whether recovery keys generated at initialization are stored with the same care as the seal, because they authorize quorum operations such as generating a root token. Record where every copy lives in your runbook and in your evidence pack, so an auditor can trace who could restore the cluster.
Access reviews on the KMS or HSM belong in the same governance cycle as the OpenBao policies. Review which identities can use the seal key for decryption, which can administer or delete it, and which automation accounts run under those roles. Keep the review results as evidence, with the reviewer, the date and any changes made. Shamir custody carries its own version of this risk. If shares are lost, or if fewer holders than the threshold remain available, the cluster cannot be unsealed by people, and the same unrecoverable outcome follows. Auto-unseal removes the people dependency but moves the risk into cloud or HSM administration. Whichever method you choose, test a full restart in a non-production copy and document the result before go-live.
Questions buyers ask before choosing an unseal model
What does auto-unseal actually cost to run in practice?
Auto-unseal costs are mostly recurring and mostly people. You pay the cloud KMS or HSM service that holds the key that protects the root key, and you pay the staff who manage key policies, access, rotation and monitoring of that service. The KMS or HSM line depends on your provider, your key count and request volume, and whether you need a dedicated hardware module, so get that line itemized in your own cloud or hardware contract. Shamir unsealing shifts cost toward the people who hold key shares and the procedures that bring nodes back after restarts, which is mostly staff time rather than a service bill. Ask any quote to separate one-time work (design, key ceremony, runbooks) from recurring work (key administration, drills, upgrades) so you can compare the two models on the same basis.
How long does it take to implement a seal decision?
The timeline depends on the drivers, not on a fixed duration. The main ones are whether a KMS or HSM already exists in your environment and how quickly your team can get access approvals for it, how many key holders you must identify and onboard for Shamir shares, how many clusters and environments need the same model, and how much of the restart and recovery process you need to automate. Air-gapped sites add time because the KMS or HSM must sit inside the same isolated boundary. Ask for the sequence in writing: design, key ceremony, recovery test, documentation and handover, with each step tied to an owner and a dependency.
Can our team set up and run the unseal model without outside help?
Yes, if you have the skills for the model you choose. Auto-unseal needs people who can administer your cloud KMS or HSM, write and review key policies, manage IAM roles for the OpenBao service identity, and monitor the key for access errors. Shamir unsealing needs people who can run a documented key ceremony, store shares under separate custody, coordinate multiple key holders during an outage and rehearse the unseal procedure. Both models need someone who understands OpenBao recovery keys, the root token process and backup handling. Assess your current staff against that list before deciding. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so a team with gaps can scope that help explicitly.
Do we need a consultant for the key ceremony and recovery test?
A consultant is not required, but a second pair of experienced hands is useful for a first ceremony. The key ceremony and recovery test are where mistakes are costly: a lost seal or an untested recovery path can leave a cluster that cannot be recovered, even from backups, according to the OpenBao seal documentation. Whether you need outside help depends on whether your staff has run this procedure before, whether your key holders can attend a supervised session, and whether auditors or internal risk teams expect independent observation of the ceremony. If you bring in help, define in writing who performs each step, what evidence is retained and who signs off on the recovery test.
What should we ask for in a written scope for this work?
A written scope should name the unseal model, the seal provider or key holders, and the environments covered. Ask for the design decision record, the configuration changes to be made, the key ceremony plan with roles and custody rules, and the recovery test with pass criteria. Also ask for the runbooks for routine restarts and for loss of the seal, the backup and restore steps that do not depend on the seal being intact, the monitoring and alerting for seal status, the handover and training sessions, and any exclusions. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask for each deliverable to be listed with an acceptance step.
Can we switch from Shamir to auto-unseal, or the other way, later?
Switching is possible in some cases, but you should confirm the exact procedure with the vendor before committing. Moving between seal types generally involves migrating the seal, which changes how the root key is protected and how recovery keys or unseal keys are issued. The OpenBao seal documentation describes both models and the recovery key behavior, but the migration steps, downtime, and any constraints for your version and storage backend belong to the OpenBao project documentation and release notes. Ask the vendor and your implementation partner to document the migration path, the rollback plan, and the test you would run in a non-production cluster first.
Does the seal choice affect compliance evidence and audits?
Yes. Auditors and internal risk teams usually want evidence of how the root key is protected, who can unseal the cluster, and how recovery is tested. With Shamir, that evidence centers on key custody records, ceremony logs and the list of key holders. With auto-unseal, it centers on the KMS or HSM access policies, key rotation records and the IAM roles bound to the cluster. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that. Confirm with your auditor which evidence they will accept before the ceremony.
How DeployOpen scopes and delivers OpenBao unseal design
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For OpenBao unseal, that means choosing between Shamir key shares and auto-unseal against your key-custody model, recovery procedures and restart behavior, then building and handing over the result as a written, tested design.
How we scope
- Written scope names the sites, clusters and restart scenarios the unseal design must cover.
- Key-holder roles, quorum rules and recovery key custody are agreed before any build work starts.
- Cloud KMS or HSM dependencies, and whether the site has network access to them, are identified during scoping.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Shamir or auto-unseal configuration is implemented in your environment with the seal type chosen from your scoping decisions.
- Restart, node-loss and seal-unavailability scenarios are tested so operators know the actual recovery steps.
- Automation for unsealing is built only where the agreed key custody model allows it, with access controls documented.
- Backup and seal-key deletion safeguards are reviewed so an unrecoverable-cluster outcome is designed out where possible.
How we hand over
- Runbooks cover routine restarts, unseal ceremonies, recovery key use and root token generation.
- Documentation records which key holders, devices or services are required for each recovery path.
- Operators are walked through the procedures in your environment so the team can run them without us.
- Evidence for compliance assessments is prepared, while independent auditors and certification bodies issue any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Seal configuration is reviewed again when OpenBao versions, KMS or HSM providers, or key holders change.
- Periodic recovery exercises can be scheduled under a retainer to confirm the procedures still work.
- A quote follows from the written scope, so ask for the scope items that drive cost before signing.
