Why secrets management for air-gapped networks needs a different design
On an isolated network, the core question is whether the secrets manager can start, unseal, renew certificates, upgrade and recover without reaching any outside service. If it depends on a cloud KMS for auto-unseal, a public package mirror for updates, or a SaaS control plane for licensing or audit export, it will fail the first time the enclave is tested under real conditions. The design has to keep every one of those functions inside the boundary, with the unseal material, the certificate authority and the backup target all held locally. For a self-hosted candidate, the supplied facts point to OpenBao, which is licensed under MPL-2.0, is hosted under the OpenSSF, and manages secrets, certificates and keys in a form that can run entirely on your own hosts. Its documented storage options are integrated storage (Raft) and PostgreSQL, both of which can sit inside the enclave. Infisical is also self-hostable, but its core is MIT while content in its ee directories carries a separate enterprise license, so you need to confirm which features your enclave requires fall under that enterprise license. HashiCorp Vault is licensed under the Business Source License 1.1 from version 1.15.0 onward, with IBM named as licensor, so its terms and edition boundaries need legal review before you commit to it. The practical first step is to write down, for each function (unseal, upgrade, PKI, backup and restore), which component supplies it and whether that component works with no network route out. Confirm with each vendor which features are reserved for paid editions, because air-gapped support is often gated behind enterprise tiers in other open-source products. Then test a full restore from local backup media in a lab that has no route to the internet before treating the design as ready.
Which regulations and constraints shape the air-gapped secrets design
This table maps the regulatory requirements most often cited for isolated networks to what each one means for an OpenBao build. Each sector row applies only where the organization is a covered entity or falls within the scope of the rule, so confirm applicability with counsel or the compliance lead before designing around it. The main takeaway is that OpenBao's audit log and key custody must be traced to every row, because assessors ask for evidence, not for a feature list.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| HIPAA Security Rule, 45 CFR 164.312 (covered entities and business associates) | Unique user identification, audit controls that record and examine activity on systems holding ePHI, person or entity authentication, and transmission security | Give each human and workload a distinct OpenBao identity, route OpenBao audit devices to an isolated log store, and encrypt all client traffic inside the enclave |
| FTC Safeguards Rule, 16 CFR 314.4 (covered financial institutions) | Multi-factor authentication for individuals accessing information systems, encryption of customer information in transit and at rest, and logging of authorized user activity | Enable login MFA for operator access to OpenBao, confirm TLS between nodes and clients, and retain audit records of secret and key reads |
| NERC CIP-005-7 (high and medium impact BES Cyber Systems) | Interactive remote access passes through an Intermediate System with encryption and MFA, plus methods to detect and disable active vendor sessions | Place any vendor or remote administrative path to OpenBao behind a controlled intermediate host, and make session termination of vendor access part of the runbook |
| NERC CIP-013-2 (supply chain risk management) | Procurement processes address verification of software integrity and authenticity of vendor software and patches | Verify OpenBao release checksums and signatures before crossing the boundary, record each import, and keep the approved package list with the change record |
| Audit log coverage (applies across sectors) | Evidence that secret and key access is recorded and can be reviewed | Confirm which OpenBao audit devices you enable, where logs are written inside the enclave, and how they reach the local SIEM without an external path |
| Key custody and unseal material (applies across sectors) | Documented control over who holds root and recovery material and how it is protected | Map unseal and recovery key holders to named roles, store shares offline under dual control, and document the procedure for each assessor request |
Which secrets platforms fit an isolated network and why
Four candidates and one selection approach, each judged by what it needs to run without internet access. The licensing, edition and operating model questions below matter as much as the feature list, because an isolated network multiplies the cost of every update, support call and feature gap.
OpenBao as the self-hosted core
OpenBao is MPL-2.0 licensed and hosted under the OpenSSF, and v2.7.1 was published on October 1, 2026. It encrypts secrets before they reach storage, issues dynamic secrets, offers encryption as a service and runs PKI through its engines. For high availability, check whether Raft or PostgreSQL fits your storage and operations skills, since both are the officially supported HA backends. Confirm that every engine and auth method you need is in the release you will mirror offline.
Infisical with edition checks
Infisical's core is MIT licensed, but content in its ee directories carries a separate enterprise license, and v0.166.8 was published on October 15, 2026. Before committing, confirm which air-gapped deployment, certificate and access control features sit in the MIT core and which require the enterprise edition. Ask for the offline install and upgrade procedure in writing, and check how its certificate features handle a private CA with no external connectivity.
HashiCorp Vault 1.15.0 and later
Vault 1.15.0 and later are under the Business Source License 1.1, with IBM named as licensor. This is not an OSI-approved open source license, so treat it as a licensing review item rather than a drop-in open option. Legal and procurement teams should read the license terms against their internal open source policy and any sector rules on approved software before scoping an isolated deployment on it.
Selecting by license, auth and capacity
DeployOpen's approach is to decide in three steps: license review first, then the auth methods your isolated workloads need (AppRole, TLS certificates, Kubernetes, LDAP or OIDC), then whether your team can operate an HA cluster, offline upgrades and restore drills without a vendor on call. Illustratively, a network that only needs static secrets and internal certificates has a different answer than one that needs dynamic database credentials. Confirm each feature in the target edition before committing.
How to design unseal and recovery keys without a cloud KMS
Shamir key shares split the root material into several pieces, and a threshold of those pieces must be presented before OpenBao can unseal. With no cloud KMS, this is the baseline most isolated deployments start from. The design question is less about the mathematics and more about custody: each share should sit with a named custodian who is accountable for it, and no single person should be able to reconstitute the threshold alone.
- Who holds material: Named custodians, usually from security, the platform team and a business or compliance role, each hold one share in a sealed, logged container.
- Dual control and split knowledge: No custodian should hold enough shares to unseal alone. Store shares in separate physical locations and separate access paths so that the threshold cannot be met by one team.
- Node restart or site outage: Every restart of a sealed node needs a quorum of custodians to be reachable. Plan for weekends, holidays and a site that is unreachable, because an outage is when the threshold is most likely to be missing.
- Recovery keys: Recovery material used for certain administrative operations is separate from unseal material. Keep the two sets distinct in custody records.
- What must be tested: Run a scheduled unseal drill with the actual custodians, confirm the threshold works from each site, and record the time it takes and any gaps.
Confirm with the OpenBao documentation which unseal methods and share settings your chosen release supports in your environment before you fix the custodian model.
Where the organization already operates a hardware security module or a comparable hardware device, key material can be protected in hardware rather than only in paper or USB custody. This option changes the trust boundary: the question becomes which devices hold keys, who administers them, and how the device itself is protected and backed up. Whether a given OpenBao release can use a particular hardware device for unseal or key protection must be confirmed against the current documentation and the device vendor's guidance.
- Who holds material: The HSM administrators hold device credentials and partition roles, while OpenBao operators hold the configuration that references the device.
- Dual control and split knowledge: Most HSMs offer their own quorum or role separation. Use it so that no single administrator can change the device configuration or export key material.
- Node restart or site outage: Confirm whether an isolated node can reach the device after a restart and whether a replacement device at a second site can take over. Device availability becomes a dependency for every unseal.
- Device backup and replacement: Document how device backup is protected, where it is stored, and how a replacement device is initialized. Losing the device without a tested path can make the secrets unrecoverable.
- What must be tested: Test a full restart that depends on the device, a failover to the second device, and the restore of device backup into a clean environment.
Confirm with the OpenBao documentation and the HSM vendor which combinations are supported in your environment, because hardware integration is release-dependent.
When no automatic unseal source exists, the unseal process is entirely manual. A documented procedure becomes the control: it defines the steps, the roles, the evidence and the escalation path that an operator follows at three in the morning during an outage. Many isolated deployments combine this procedure with Shamir shares, but the procedure deserves its own attention because it is what an auditor and an on-call engineer will both read.
- Who holds material: The procedure names the roles that may start an unseal, the roles that supply shares, and the witness who confirms each step.
- Dual control and split knowledge: Require a second person to witness each unseal action and record it. Keep the procedure in a location that remains reachable when the network is down, such as a printed copy in a secure room.
- Node restart or site outage: Define the order of operations for a cluster: which node is unsealed first, how standbys rejoin, and what to do if the active node cannot be reached. Include a decision point for when to declare an incident.
- Change control: Version the procedure, approve changes through the same process as other security controls, and keep prior versions for audit.
- What must be tested: Run tabletop exercises and live drills that follow the written procedure exactly. Time the drill, note every deviation and update the document before the next exercise.
For this option, check that the procedure matches the unseal behavior of your chosen OpenBao release, since steps that worked on an earlier version may no longer apply.
Which integration points an air-gapped OpenBao deployment must cover
An OpenBao cluster on an isolated network depends on neighbors that also have to work without the internet: certificate issuance, identity, audit, the container platform, the CI system and storage. Each card below names one integration point, what it needs from the enclave, and what to confirm before the design is fixed.
Local PKI for internal TLS
OpenBao can act as the certificate authority for TLS between its own nodes, clients and internal services, so the enclave does not depend on a public CA. Decide the root and intermediate hierarchy, where the root key is held, and how it is kept offline. Confirm in the OpenBao PKI documentation which certificate lifetimes, key types and revocation (CRL) behaviors the version you deploy supports, and how clients reach the CRL without internet access.
Operator and workload identity
Human operators and workloads need to log in to OpenBao without a cloud identity service. Typical choices are LDAP or Kerberos against the enclave directory, OIDC from a locally hosted identity provider such as Keycloak, or TLS certificate authentication for machines. OpenBao recommends Userpass for developer machines and AppRole for servers, so confirm which method fits each population and that the identity provider runs inside the enclave.
Audit logs to Wazuh or Security Onion
Audit devices in OpenBao record every request, so the log path must reach a SIEM inside the enclave. Wazuh publishes an offline installation guide, and Security Onion supports full installs without internet access with airgap updates through its soup tool. Confirm the log shipping method, how log integrity is protected, and how the SIEM receives events when the sensor network is segmented from the secrets cluster.
Private registry for Kubernetes hosts
If OpenBao runs on Kubernetes, every control plane and workload image must come from a registry inside the enclave. kubeadm config images list and kubeadm config images pull fetch the control plane images in advance, and the --image-repository flag points kubeadm init at the private registry. Confirm the OpenBao image, its digest and the injector or CSI components are mirrored, and that signatures are verified before import.
Offline CI jobs that read secrets
Pipelines that fetch secrets from OpenBao need a runner, a container image source and a package mirror that all sit inside the enclave. GitLab documents self-managed instances in offline environments, and separate guidance covers its security scanners. Confirm how runners authenticate to OpenBao, typically through JWT or OIDC from the local GitLab instance, and how dependencies for each job are mirrored and scanned before they cross into the enclave.
Storage backend and HA design
OpenBao supports integrated storage (Raft) and PostgreSQL as its officially supported HA backends. The docs describe PostgreSQL as easier to operate safely than Raft, while Raft needs no separate database service. Decide where the backend runs, how nodes are placed across failure domains, and how snapshots are copied to offline media. Confirm the backup and restore procedure for the chosen backend, since no external service can be reached during recovery.
How an air-gapped OpenBao rollout moves from design to handover
This sequence takes an isolated network from trust boundary design to a running, tested OpenBao cluster that the client's own operators can upgrade, restore and audit without reaching an external service. Each phase ends with a record that an auditor or incident responder can inspect.
Design the enclave and custodian model
DeployOpen works with the client's security, infrastructure and compliance leads to define the enclave boundary, which systems may reach OpenBao, how traffic crosses the boundary, and who holds each unseal share and recovery material. The custodian roster, split of duties and the rules for quorum are written down before any hardware is touched. The step closes with an approved architecture decision record and a custodian assignment register that names each person, their role and their backup. Ask the partner to show how the register will be kept current when staff change.
Build and verify the offline artifact set
On a connected build network, DeployOpen assembles every binary, operating system package, container image and rule set the cluster needs, then pulls them into one controlled bundle. Each artifact is checked against its published checksum and signature, and the bundle is recorded in a signed artifact manifest that lists name, version, hash and source. The manifest is reviewed by the client before transfer, because the same discipline is expected under supply chain requirements such as NERC CIP-013-2 for software carried across an isolated boundary. The step is complete when the manifest is signed and a second person has verified a sample of hashes on the transfer media.
Install the cluster and run the unseal ceremony
Operators install OpenBao on the isolated nodes from the verified bundle, configure integrated storage (Raft) or PostgreSQL for high availability, and initialize the cluster. The unseal ceremony is run in a witnessed session where each custodian enters their share in turn, with no share stored in the same location as another. The ceremony is recorded as an unseal ceremony record that captures the date, attendees, the quorum used, the storage backend and the node configuration, with custodian signatures. Confirm with the partner which storage backend they recommend for the client's operating model, since the OpenBao storage documentation treats PostgreSQL as the easier backend to operate safely.
Configure local PKI and authentication
DeployOpen sets up the internal certificate authority inside the enclave, including root and intermediate hierarchy, issuance roles and certificate lifetimes that match the client's policy. Authentication is then configured for each consumer, typically AppRole for servers and the Kubernetes or TLS certificate methods for workloads, with policies scoped to the minimum each application needs. Administrative access uses named accounts and login MFA rather than shared credentials. The step closes with a policy inventory and a test report showing that each application can read only its own paths and that the root certificate chain validates on every enclave host.
Forward logs and prove restore
Audit devices are enabled so every secret read, policy change and seal operation is written to a log store inside the enclave, and forwarding is tested to the client's SIEM or local log platform. DeployOpen then takes a backup, restores it to a separate test cluster built from the same offline bundle, and checks that secrets, policies and the PKI chain come back intact. The output is a restore test report that records the backup method, the restore steps, the time observed and any gaps found. The client should confirm that the restore includes the unseal and recovery material procedure, not only the data.
Hand over runbooks for offline upgrades
DeployOpen delivers a runbook set covering routine operations, seal and unseal procedures, custodian rotation, certificate renewal, backup and restore, and offline upgrades. The upgrade runbook follows the same path as the original build: a new artifact manifest is produced on the connected side, verified, carried across, and applied to a staging enclave before production. Operators run one supervised upgrade with DeployOpen before the handover is signed off. The step is complete when the client's operators have performed the restore test and a tabletop upgrade without assistance, and the signed handover record is filed with the compliance evidence.
How offline upgrades and backups get tested before an incident
Every OpenBao upgrade should be rehearsed in a test enclave before it touches production. On an isolated network, the release arrives on verified media that you carried across the boundary, so the same package, checksum and signature check you run on the artifact should be repeated for each release in the 2.7.x line, including the September 23, 2026 release of v2.7.0 and the October 1, 2026 release of v2.7.1. Read the OpenBao migration guide before any minor version change, confirm the storage format and seal configuration are supported on the path you are taking, and record the result of the rehearsal as change evidence. Ask your partner to show the staging run, including the unseal ceremony with the same custodians who will perform it in production.
A backup is only a control if you can restore it and unseal it under current custody. Back up the storage snapshot for your backend, the custodian records that show who holds unseal or recovery material and where it is kept, and the PKI root and intermediate keys that your certificate authority depends on. Restore the set into the test enclave on a schedule, start the cluster, and confirm that the restored data is readable and that the custodians who hold today's shares can unseal it. A backup that the current custodians cannot unseal is a failed control, even if the snapshot job reported success. Record the restore time and any gaps as findings.
Confirm backup and restore behavior with the vendor for your specific storage backend before you commit to a design. Integrated storage (Raft), PostgreSQL, PebbleDB and in-memory are documented options, and the snapshot, consistency and restore procedures differ between them. Ask how a snapshot is taken on a running cluster, whether the procedure is supported for your version, what happens to leases and tokens after restore, and how standby nodes rejoin. Your partner should show these steps working on your media, your hardware and your custodians, not only in a vendor document.
What auditors and assessors ask for from an air-gapped secrets platform
This table maps each evidence item an assessor typically requests from an isolated OpenBao deployment to the control it supports and the component that produces it. Use it as a checklist to design logging, ceremony records and backups before the assessment begins, not after. Auditors and certification bodies decide whether the evidence is sufficient; DeployOpen prepares the artifacts for that review.
| Evidence item | Control or regulation it supports | Component that produces it |
|---|---|---|
| Access control list and policy export | HIPAA 45 CFR 164.312 access control; FTC Safeguards Rule 16 CFR 314.4 access restrictions | OpenBao policies and ACL exports, captured under version control |
| Audit device logs for every secret and key read | HIPAA 45 CFR 164.312 audit controls; FTC Safeguards Rule 16 CFR 314.4 logging of authorized user activity | OpenBao audit devices (file or socket) forwarded to a local log store |
| Unseal ceremony records | Key custody and dual control expectations under NERC CIP-005-7 and general cryptographic key management reviews | Signed ceremony log, key-share custodian list and witness sign-off kept offline |
| Unique identity mapping for operators and workloads | HIPAA 45 CFR 164.312 unique user identification and entity authentication | Auth method configuration (Userpass, AppRole, TLS certificates, JWT/OIDC) and entity alias records |
| Offline package verification records (hashes and signatures) | NERC CIP-013-2 verification of software integrity and authenticity for patches carried across the boundary | Transfer manifest listing SHA-256 hashes and vendor signature checks for each OpenBao release package |
| Restore test results | Availability and recovery expectations in HIPAA and FTC Safeguards reviews; backup testing evidence | Dated restore runs against encrypted snapshots from the storage backend, with recorded outcomes |
| PKI issuance and revocation records | Certificate lifecycle and device identity controls, including the NERC CIP-005-7 encryption requirements for remote access | OpenBao PKI engine issuance logs, CRL history and root CA custody records |
| Multi-factor authentication configuration for operator logins | FTC Safeguards Rule 16 CFR 314.4 multi-factor authentication; NERC CIP-005-7 multi-factor authentication | OpenBao login MFA settings and the MFA provider's enrollment and failure logs |
What to ask an implementation partner before an air-gapped build
Start with the unseal and recovery material, because it decides whether the cluster can ever be opened again without the vendor. Ask the partner exactly where the initial unseal keys and recovery keys are generated, how many shares are created and what threshold is required to reconstruct them, and who holds each share under what custody procedure. Ask whether the keys are ever present in a single location or on a connected workstation during setup, and how the ceremony is witnessed and logged. Then ask how the partner tests a restore from backup and an unseal from the stored shares inside the enclave, not on a lab network, and what evidence of that test you will receive in writing. Also confirm where the root token is revoked after initial configuration, since a live root token left behind is a common gap in handovers.
Next, ask how the offline artifact chain is verified before anything crosses the boundary. Each OpenBao binary, container image, plugin, policy file and rule set should arrive with a checksum or signature that the partner verifies, records and gives you, along with the list of versions in use. Ask which OpenBao release line the build targets, what the upgrade path is from the current minor version, and whether the partner will hold a staging copy outside the enclave for each transfer. Ask who can perform upgrades inside the enclave, what change approval they need from your side, and whether an upgrade requires a documented rollback plan. Finally, ask for the local PKI design: where the root certificate authority key is generated, whether it stays offline, how intermediates are issued and rotated, and what the rotation runbook looks like if the root is compromised. Also ask how audit device output reaches your local SIEM, which log format and transport are used, and what happens to logs when the collector is down.
Close the conversation by asking what stays with your staff after handover. Request a written scope and a deliverables list before work starts, with named acceptance tests for HA failover, restore, unseal drills and audit log delivery. Ask which runbooks the partner will write, which of them your operators must rehearse, and how many people you need trained to unseal and recover without the partner present. Confirm the support model in writing, including who responds when the enclave is down, how a fault is reported across a one-way transfer, and what the partner does not own after acceptance. The answers should map directly onto your own recovery plan. If a partner cannot show how they test recovery in an isolated environment, treat that as a scope gap to resolve before the quote is signed.
What buyers ask about air-gapped secrets management cost, time and effort
What drives the cost of running OpenBao on an air-gapped network?
The main cost drivers are the number of OpenBao nodes, the high availability backend you choose, how many applications and auth methods must be integrated, the key custody ceremonies you run, and how offline artifacts are handled. OpenBao itself is licensed under MPL-2.0, so the software cost is the infrastructure, the integration work and the operations time. Costs fall into one-time items (design, build, integration, custody setup and initial hardening) and recurring items (upgrades, backup testing, rotation support and staff time). Ask any quote to show each of these separately, along with which party carries each cost and what changes if the node count or application count grows.
Can our own team run OpenBao on an isolated network alone?
Some teams can, provided they have the skills and time to run it safely. The hard parts are not the initial install but the unseal procedure, offline upgrades and restore testing, which must work when no external service can be reached. Before going alone, name an owner for each of these procedures, a second person who can perform them, and a rehearsal schedule. If those roles cannot be filled, a partner can plan, build and document the procedures, then hand them over or support them under a retainer. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own network, so the division of work can be agreed in writing.
What does our team need to provide for an air-gapped secrets project?
Expect to provide the following inputs before work starts:
- Network access for the build phase, including a staging path where approved software packages and images can be carried across the isolated boundary.
- Named key custodians who will hold unseal and recovery material, along with their availability for custody ceremonies.
- The existing identity source, such as Active Directory, LDAP or an OIDC provider, that applications and administrators will authenticate against.
- Change windows for cutover, upgrades and restore rehearsals, agreed with operations and the business owners of each dependent system.
Confirm these inputs during scoping, since missing custodians or unclear identity sources are common reasons a schedule slips.
How long does an air-gapped OpenBao implementation take?
The duration depends on scope: the number of nodes, the storage backend, the number of applications and auth methods to integrate, whether an existing secrets store must be migrated, and how many custody ceremonies and restore tests are required. No supplied fact gives a fixed duration for this work, so treat any single figure with caution. DeployOpen plans engagements as fixed-scope work, and scope, deliverables and timelines are agreed in writing before work starts. Ask for a phased plan that separates the build, integration, custody and recovery testing, and for the dependencies that could move each phase.
Do we need a paid air-gapped license for the secrets platform?
Confirm this for each platform, because some vendors reserve air-gapped support for paid editions. OpenBao is released under MPL-2.0 and does not depend on a vendor edition to run offline. Other platforms in adjacent categories differ: some vendors list air-gapped deployment only in enterprise tiers, and HashiCorp Vault from version 1.15.0 is licensed under the Business Source License 1.1, which is not an OSI-approved open source license. If you evaluate an alternative such as Infisical, check its license for each directory, since content in its ee directories carries a separate enterprise license. Ask the vendor in writing which features, updates and support channels are included for disconnected operation.
Does DeployOpen offer ongoing support after an air-gapped secrets deployment?
Yes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. For an isolated network, a retainer can cover offline upgrade preparation, restore rehearsals, custody procedure reviews and responses to incidents that affect secret availability. The retainer scope, response expectations and any service levels should be written into the agreement, since no service level is stated here. Ask for the list of activities included, how offline artifacts are delivered and verified, and who on the DeployOpen side would perform them.
How DeployOpen scopes and builds secrets management for isolated networks
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own air-gapped network. For secrets management, that means OpenBao deployed, unsealed, backed up and upgraded without any dependency on an external service, with the evidence assembled as the work progresses.
How we scope
- Inventory which secret types must be held: static credentials, dynamic database access, certificates and encryption keys.
- Document the unseal design, key custodians and recovery procedure agreed with your security owners before any build starts.
- Agree in writing which storage backend, auth methods and HA topology are in and out of scope, with engagements fixed-scope.
How we build
- Install OpenBao from artifacts verified and carried across the isolated boundary under your software integrity process.
- Configure auth methods for servers and pipelines, with policies scoped per application and per team.
- Test failover, restore from backup and an offline upgrade in your environment, and record the results.
How we hand over
- Deliver runbooks for unseal, key rotation, backup, restore, offline upgrades and access requests.
- Provide documentation mapping audit log output, policies and key lifecycle steps to the evidence your assessors request.
- Walk your operators through recovery drills so the team can perform them without DeployOpen present.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Review each OpenBao release and plan offline upgrade packages for your change windows.
- Re-test recovery procedures and access policies whenever the network, identity sources or applications change.
