AWS Secrets Manager alternative for air-gapped networks

Why AWS Secrets Manager does not fit an air-gapped secrets platform

If your secrets must stay inside an isolated network, an OT segment or an on-premises data boundary that cannot reach AWS Region endpoints, AWS Secrets Manager is the wrong tool for that boundary. The answer for that constraint is a self-hosted secrets manager such as OpenBao, deployed and unsealed entirely inside the boundary, with its storage, unseal material and audit logs under your control. This choice follows from where the secrets must live and who must be able to reach them, not from any judgment about the quality of the AWS service.

The core problem is reachability. Secrets Manager is called over AWS API endpoints, and its audit trail is written to CloudTrail, so every read depends on a path to AWS that a sealed network does not have. Before you commit to a design, write down which systems must fetch secrets during an outage, which must work with no internet route at all, and which data classes cannot leave your facility. Confirm with your network and compliance teams whether any of those systems also depend on AWS KMS for encryption, because that dependency would also have to be removed or replaced.

The rest of this page covers the requirements that follow from an isolated boundary, the open-source options that can run there and how a deployment is built and kept current. Treat each requirement as a question you must answer in writing: how the server is unsealed after a restart, how packages and container images are verified before they cross the boundary, how upgrades are staged, and how audit records are retained and reviewed. Those answers, more than the product choice, determine whether the platform meets your environment.

What an isolated boundary requires from a secrets manager

A secrets manager in an isolated network has to work without the cloud services that AWS Secrets Manager depends on, and every change that crosses the boundary has to be verified. The cards below set out the requirements that connect those two needs. Confirm with your own assessor which controls apply to your scope before you rely on any of them.

No dependence on cloud endpoints

AWS Secrets Manager is reached through AWS Region endpoints, and its pricing is per secret per month plus per 10,000 API calls. A self-hosted OpenBao instance removes that dependency, but only if every path it needs is local: storage, unseal, the operator's clients and the identity sources it uses. Check that the design has no hidden callout to a public endpoint, and test the cluster with outbound access blocked before go-live.

Unseal without cloud KMS

OpenBao starts sealed and needs its key material supplied before it serves requests. In a cloud deployment, auto-unseal is often delegated to a cloud key service, which does not exist inside an isolated network. Plan how unseal keys are generated, split, stored and returned after a restart, who holds each share, and how that procedure is rehearsed. Ask your assessor how this process is evidenced.

Integrity checks for every carried package

NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches. In practice, every container image, binary, Helm chart and operating system package that enters the boundary needs a recorded checksum or signature check, an approval record and a known source. Build this as a documented transfer process, because the secrets manager's patch level depends on it.

Controlled vendor remote access

NERC CIP-005-7 requires interactive remote access to high and medium impact BES Cyber Systems to pass through an Intermediate System with encryption and multi-factor authentication, and to include methods to detect and disable active vendor sessions. Any support engineer or implementation partner who administers OpenBao from outside the boundary falls under the same questions. Decide where the jump point sits, how sessions are recorded, and how a live session is cut off.

Encryption before secrets reach storage

OpenBao encrypts secret values before writing them to its storage backend, which matters when storage lives on shared disks, database servers or backup media in the isolated zone. Confirm that TLS protects traffic between clients, standby nodes and storage, and that backups hold only encrypted data. Restoring a backup also needs the unseal material, so store that separately from the backup set.

Audit trails inside the boundary

AWS Secrets Manager writes CloudTrail entries for each GetSecretValue call, so access history lives in AWS. On an isolated network, you must set up and retain that record yourself, by enabling OpenBao's audit devices and forwarding logs to a store inside the boundary. Ask your assessor which retention period and which review cadence apply to your scope, and test that the logs survive a node failure.

Which open-source options fit an isolated network

OpenBao is the open-source fork of Vault and the option this page documents most fully for an isolated network. It is licensed under MPL 2.0 and is a Sandbox project of the Open Source Security Foundation (OpenSSF) under Linux Foundation stewardship. The latest release in the supplied facts is v2.7.1, released October 1, 2026. Secrets are encrypted before they are written to storage, so the server can run inside your own network without calling an AWS Region endpoint.

Offline install: Stage the binary or container images, and the Helm chart if you run Kubernetes, in an internal registry before the isolation boundary. The Helm chart requires Helm 3.6 or later. For the cluster beneath OpenBao, kubeadm can list and pull control plane images in advance, and --image-repository points kubeadm init at a private registry.
Storage and HA: Integrated storage (Raft) and PostgreSQL are the officially supported HA backends. The docs describe PostgreSQL as easier to operate safely than Raft, and since 2.5.0 Raft standbys can serve read-only operations.
Unsealing without cloud KMS: The migration guide describes Shamir unseal. Confirm which unseal methods your target version supports offline, then document where key shares are held and who can reach them during a restart.
Authentication on isolated hosts: AppRole is recommended for servers and Userpass for developer machines. TLS certificates, Kerberos, LDAP and JWT/OIDC cover identity providers inside the network.
Migration limits: The migration guide describes an in-place upgrade from Vault Community 1.14.1 on Raft with Shamir unseal, tested only against that version. Mounts that use plugins OpenBao does not ship are skipped.

Before any offline import, check the version you deploy against the release notes and the migration guide.

How OpenBao meets the secrets requirements without cloud KMS

OpenBao encrypts secrets before they are written to storage, so the storage backend never holds plaintext values. On an isolated network this matters more than usual, because there is no AWS KMS key to fall back on. Instead, the encryption key is protected by the unseal process. OpenBao supports Shamir unseal, which splits the master key into key shares that must be combined before the server can read its data. The documented Shamir path needs no cloud KMS service, which is why it fits networks with no route to a cloud provider. Your team should confirm the key share count and threshold, how many people hold shares, and whether any share is ever stored in the same place as the data or the backups. Those choices belong in your key custody policy, and a sealed server is only as recoverable as that policy allows.

The auth method you enable decides who can reach the secrets boundary at all. OpenBao documents AppRole for servers and Userpass for developer machines, and it also supports TLS certificate auth, Kubernetes, LDAP and login MFA. For an isolated network, AppRole with tightly scoped roles and short-lived secret IDs is the usual choice for workloads, while Userpass should be limited to a small group of administrators with MFA enabled. Where your directory is on the same isolated segment, LDAP or certificate-based access can replace local accounts, but each option adds a dependency that must also survive an outage. Confirm which identities will authenticate, where their credentials originate, and how access is revoked when staff or systems leave the enclave.

How to deploy OpenBao offline and unseal it without cloud KMS

This sequence takes a secrets manager from a verified offline artifact set to a tested, unsealed OpenBao cluster that holds its own unseal keys, with audit and recovery in place before any workload depends on it.

Build and verify the artifact inventory
Your platform team lists every item that must cross the isolation boundary: the OpenBao server image, the Helm chart version, any container base images, OS packages, and the Raft or PostgreSQL backend binaries your design needs. Pin each item to a specific release, such as the OpenBao v2.7.1 release published on the OpenBao GitHub releases page, and record the checksum or signature published with it. Your security team verifies those checksums on the source side before transfer, and the inventory is stored with the change record. This step is done when every artifact has a version, a hash and a named reviewer. Confirm with your own change process how NERC CIP-013-2 or your internal software integrity policy applies to this transfer.
Mirror images and the Helm chart privately
The platform team loads verified images into your private registry and places the OpenBao Helm chart in an internal chart repository or as a local archive. The chart requires Helm 3.6 or later, so confirm that version on the air-gapped admin workstation before installing. Chart values must point image references at your internal registry rather than public hosts. Check the chart's documented install method on the OpenBao Helm chart page, since offline chart delivery steps depend on your registry tooling. This step is done when a pull from a clean offline node succeeds for every image and the chart renders with helm template without errors.
Install OpenBao on Kubernetes or bare metal
On Kubernetes, the cluster itself must already run offline; the kubeadm documentation covers pre-pulling control plane images and pointing kubeadm at a private registry with the --image-repository flag. The platform team then installs OpenBao with the Helm chart using values that set the internal image path, storage configuration and TLS certificates issued by your internal CA. On bare metal, the same binary and configuration file are installed as a systemd service. Either way, the server should listen only on internal addresses and have a service account or OS user with no shell. This step is done when each server pod or process starts and reports itself as uninitialized and sealed.
Choose Raft or PostgreSQL storage for HA
The storage decision belongs to the platform team and the database administrators, and it depends on what your environment already operates well. OpenBao supports integrated storage (Raft) and PostgreSQL as its officially supported HA backends, and its storage documentation describes PostgreSQL as easier to operate safely than Raft. Raft keeps everything inside OpenBao nodes, which removes an external dependency but puts backup and peer recovery on your OpenBao team. PostgreSQL moves those duties to a database you may already run, but it adds a second system to patch in isolation. Confirm which option your database team can support offline, and document the choice. This step is done when the storage configuration is written, reviewed and deployed to every node.
Initialize and unseal with Shamir shares
Without cloud KMS, unsealing relies on Shamir key shares. An operator initializes the cluster once, which generates the unseal shares and the initial root token. Name custodians for each share, and split them so that no single person holds enough shares to unseal alone; the threshold and share count should be set by your own key management policy. Each custodian enters their share on the server or through the approved unseal procedure, and you record which custodians participated. Store the root token in a separate break-glass vault, then revoke it once administrative roles are in place. This step is done when the cluster reports unsealed and each custodian has signed an acknowledgment of their share.
Configure audit devices and auth methods
Enable at least one audit device that writes to a local file or syslog destination your SIEM collects, and confirm that OpenBao refuses requests when no audit device can write, which is the safe default you should keep. Then enable only the auth methods your workloads need. The OpenBao auth methods documentation lists AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates and others, and recommends AppRole for servers and Userpass for developer machines. Connect identity sources that exist on your isolated network, such as LDAP or Kerberos, and define policies per application. This step is done when a test login produces an audit entry and a policy-limited token can read only its assigned path.
Test failover and restore
Before any production workload depends on the cluster, the platform team stops the active node and confirms that a standby takes over and that clients reconnect. The team then takes a storage-level backup, restores it into a separate test cluster, and unseals that restored copy with the custodians. Record the observed failover behavior and restore steps in the runbook, and repeat both tests after each OpenBao upgrade. Upgrade paths matter here: the OpenBao migration guide covers a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft with Shamir unseal, but it was tested only against that version, so confirm your starting version before relying on it. This step is done when failover and restore both complete and the runbook reflects what you saw.

Keeping OpenBao patched when updates arrive on media

Every OpenBao update that reaches an isolated network must be treated as software crossing a trust boundary. Import, verify and test each patch before it touches the production cluster. Your change board and your software integrity controls should define who may approve a release, how the media is checked and where the test results are kept. Start from the OpenBao releases page, which is where security fixes are announced. Two releases, v2.6.4 and v2.7.1, were published on October 1, 2026, with v2.6.4 covering the previous minor line. Confirm which minor line your environment runs, because a security fix may ship only to the line you are on, and a cluster that stays on an older minor line can fall behind on fixes without anyone noticing.

Plan for the gap between releases and your import schedule. Each transfer adds handling time, so a cluster that moves to a new minor line only once a year can carry known vulnerabilities for months. Record the version you run, the version on the media, and the date each was imported. Ask your vendor or integrator to state how long each minor line receives security fixes, and confirm that the fixes you need are available in the line you choose before you commit to a path.

The OpenBao migration guide describes a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal. The guide states it was tested only against that version, so any other starting point needs your own rehearsal in a lab copy. Upgrade one standby at a time, confirm the cluster elects a leader and reports healthy, and verify that mounts load. Mounts that use plugins OpenBao does not ship are skipped, so inventory them before the window opens. Confirm the upgrade window and rollback plan with your change board, and agree in writing who is on call and what evidence is kept for each change.

Evidence assessors and regulators ask for

An air-gapped OpenBao deployment is only as defensible as the records behind it. The six items below are the evidence that assessors and regulators typically ask to see, and each one depends on the others: transfer records prove what entered the network, audit and access records prove what happened inside it, and backup and patch records prove it can recover and stay current.

Software bill and integrity checks

Every package, container image, Helm chart and OpenBao binary carried across the isolated boundary needs a recorded inventory, a version, a hash and a verification step, with the person who approved the transfer named. NERC CIP-013-2 is a useful reference for utilities because it asks procurement processes to address verification of software integrity and authenticity of vendor software and patches. Keep the signed release artifacts and checksums from the OpenBao releases page alongside each transfer ticket, so an assessor can trace a running version back to a verified source.

Audit device logs

Enable at least one audit device and ship its logs off the OpenBao nodes so that a record of every authenticated request survives a compromised or rebuilt server. Confirm with your own configuration that audit logs are written to a location the OpenBao service account cannot rewrite, and that log retention meets the period your assessor expects. Test that a sample of logged requests can be matched to a named identity and a time, because an audit log that cannot answer those questions will not satisfy a review.

Unseal custodian records

Without cloud KMS, unsealing depends on people holding key shares, so the custodian roster is evidence in its own right. Record who holds each share, how shares are stored, when they were last rotated and which custodians took part in each unseal event. Confirm with your own configuration how many shares and how many threshold shares your Shamir setup uses, and document the procedure for replacing a custodian who leaves the organization.

Auth role access reviews

Access reviews cover the AppRole, Kubernetes, LDAP, TLS certificate and Userpass roles that OpenBao accepts, because each role is a path to secrets. OpenBao recommends Userpass for developer machines and AppRole for servers, so review those two groups separately. Record which policies each role carries, who approved it, when it was last reviewed and which roles were removed after a system was retired.

Backup and restore test records

Backups of the Raft or PostgreSQL storage backend are only evidence once a restore has been performed. Keep dated records of each backup, the storage location, the restore test into an isolated environment, and the unseal procedure used during that test. Because the encrypted data is useless without the unseal shares, the restore record should show that custodians could reconstitute the service, not only that files were copied.

Patch records tied to release notes

Each OpenBao upgrade should be linked to the release notes that describe its security fixes, the test environment where it was applied and the approval for production. The OpenBao releases page lists security fixes by version, so a record that names the version applied and the fixes it contains lets an assessor confirm that vulnerable versions were replaced. Note any migration constraints first: the OpenBao migration guide documents an in-place upgrade path from Vault Community 1.14.1 on Raft storage that was tested only against that version.

Questions buyers ask before choosing an air-gapped secrets manager

How do the costs of self-hosting OpenBao compare with AWS Secrets Manager per-secret and per-call fees?

AWS Secrets Manager bills per secret per month plus per 10,000 API calls, with no upfront costs or long-term contracts, according to AWS's pricing page. Self-hosting replaces those recurring fees with components you pay for directly: server capacity in your data center or private cloud, storage, backup media, the hardware or hypervisor licensing behind them, and the staff time to operate the cluster. Some costs are one-time, such as initial deployment and hardening, and others recur, such as patching, backups, monitoring and staff hours. The balance depends on how many secrets you hold, how often workloads read them, and how many people must keep the cluster running. Ask any quote to separate infrastructure, labor and recurring support so you can compare it line by line with your current AWS bill.

Can our team run OpenBao in an air-gapped network without outside help?

Yes, many teams do, provided they have engineers who can administer Linux, TLS, storage and access control, and who can follow a documented offline process. OpenBao is open source under MPL 2.0, so the software and its documentation can be mirrored into an isolated network. The harder parts are operational: initializing and unsealing the cluster without cloud KMS, protecting unseal material, rotating certificates, testing restores and keeping packages current through a controlled transfer process. If your team lacks this experience, you can split the work: keep day-to-day operations in-house and buy design, hardening or an initial build as a fixed-scope engagement. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks, under a written scope.

How long does setting up an air-gapped OpenBao deployment take?

The duration depends on scope rather than on a fixed number. The main variables are the number of clusters (for example, one production cluster with a disaster recovery site versus several environments), the storage backend you choose, whether you must integrate with existing identity sources, how many applications need migrating, and how much offline transfer and approval work your change process requires. Storage and high availability choices affect design time: OpenBao documents integrated storage (Raft) and PostgreSQL as its supported high availability backends. Ask any provider for a written timeline tied to a defined scope, and ask what is excluded, such as application migration or rotation redesign. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

What do we need to provide for an OpenBao deployment on isolated networks?

Plan for four groups of input before work begins:

Staff: engineers for Linux and network administration, a security owner for access policy, and application owners who will change how their workloads fetch secrets.
Custodians: named people who hold unseal keys or recovery material, with a documented split so no single person can unseal alone.
Network changes: approved paths for internal TLS, load balancer or DNS names, and a transfer process for software packages and updates into the isolated zone.
Records: an inventory of secrets, consumers and existing access paths, plus the change window and approval flow for your environment.

Confirm internally whether your policies require dual control or specific key ceremonies, because these shape the design.

Can OpenBao replace the IAM-based access patterns our workloads use with AWS Secrets Manager?

OpenBao does not use IAM roles or policies as its access model, so it cannot be a drop-in replacement for IAM authorization. Instead it provides its own identity-based access control through auth methods that include AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, TLS certificates, tokens and username and password, along with login MFA. OpenBao recommends Userpass for developer machines and AppRole for servers. For workloads in AWS, you would confirm whether an AWS auth method suits your design, since the supported methods are what you should verify against the current OpenBao auth methods documentation. Workloads on premises usually map more cleanly to AppRole, Kubernetes or certificate-based login. Plan the policy model before migrating, not after.

How do we confirm the license terms before we deploy OpenBao?

Have counsel review the licenses that apply to each component you plan to deploy. OpenBao's repository is licensed under MPL-2.0. HashiCorp announced on August 10, 2023 that future Vault releases would move to the Business Source License 1.1, while its APIs, SDKs and most libraries stay under MPL 2.0, so the license of the exact Vault version you run matters for any migration analysis. Ask counsel to review your use case against the restriction that targets competitive services built on HashiCorp products, and to check any plugins, Helm charts or extensions separately. Confirm the terms with the project and the license text in the repository, not with a summary. DeployOpen does not provide legal advice on licensing.

What ongoing work keeps an air-gapped OpenBao cluster secure and supported?

The work recurs and should be budgeted as a running function. Track OpenBao releases and security fixes: for example, the project released v2.7.1 on October 1, 2026 with security fixes, and your process must bring such updates across the isolated boundary and verify their integrity before installation. Patch the operating system and dependencies, rotate certificates and unseal material under your procedures, test backup restores on a schedule, and review audit logs. Under NERC CIP-013-2, if you operate in that sector, supply chain processes must address verification of software integrity and authenticity for vendor software and patches. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers.

How DeployOpen deploys OpenBao inside your boundary

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including isolated networks and data centers. For an AWS Secrets Manager replacement, that means OpenBao deployed, unsealed and operated within your boundary, with the offline install, key custody and evidence built into the written scope.

How we scope

Written scope lists which systems will read secrets from OpenBao and which AWS Secrets Manager secrets move across.
Scope defines the offline boundary, how software packages and images enter it, and who holds unseal material.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We stage OpenBao binaries, container images and the Helm chart for transfer, verifying each artifact before it crosses the boundary.
We configure integrated storage or PostgreSQL for high availability, plus auth methods that fit each workload type.
We test unseal procedures, backup restores and access controls in your environment, then document the results.

How we hand over

Handover includes architecture notes, runbooks for unsealing, rotation of root and unseal material, and upgrade procedures.
Audit log configuration and retention settings are documented so your teams and assessors can review evidence.
Your staff receive walkthroughs of day-to-day operations, including how to add a secret engine or revoke a lease.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover reviewing OpenBao security releases and planning offline patch cycles for your boundary.
Confirm with your team how often new OpenBao releases must be validated before they enter production.

AWS Secrets Manager alternative for air-gapped and on-premises networks