Why a bastion inside an air-gapped enclave is a different build
An operator on an isolated network still has to reach servers, databases and OT or regulated systems, and that access has to be controlled and recorded. A self-hosted bastion can run fully offline, but every dependency must be brought in and verified by the client: the installer, container images, identity source, recording storage and every patch. On a connected bastion, most of these arrive over the network on demand. Inside an enclave, each one is a deliberate transfer that someone owns, checks and records. That changes the build in three ways. First, the installation is a media-based process: you stage the installer, the images and their dependencies on approved media, then install without any outbound call. Second, the identity layer cannot assume a cloud identity provider, so you need local sources such as LDAP or Active Directory and a tested fallback for break-glass accounts. Third, session recordings stay inside the enclave, so storage sizing, backup and retention become part of the design rather than an afterthought. Confirm with each vendor which features still work without connectivity, such as password rotation, approval workflows and recording transcoding, since offline behavior varies by edition. For broad protocol coverage and approval workflows, JumpServer is the stronger starting point, but confirm which of those features its licensing covers before you commit. For a lean browser gateway that mainly needs RDP, VNC and SSH with a small number of components, Guacamole is simpler to stage and reason about. Either way, ask your implementation partner to document the offline install procedure, the patch transfer process and the restore test before the first production session.
Which requirements shape an air-gapped PAM build
This table maps four requirements to the design choices an air-gapped bastion must make. Read each row as a question the build has to answer before installation, with the evidence an assessor will expect to see. The main takeaway is that the offline constraint does not relax these controls, so session recording, identity sources and package verification all need to live inside the enclave.
| Requirement | Source | What it means for the offline build |
|---|---|---|
| Unique user identification and audit controls for ePHI systems | 45 CFR 164.312 (HIPAA Security Rule) | Every administrator needs a named account, not a shared login, and the bastion must record sessions that reach systems holding ePHI. Local accounts and recordings stored inside the enclave must still be reviewable on demand. |
| Multi-factor authentication and monitoring of authorized user activity | 16 CFR 314.4 (FTC Safeguards Rule) | MFA has to work without internet access, so confirm which factor types the chosen gateway supports offline and how tokens are enrolled. Activity logs must be retained locally and forwarded to an in-enclave log store. |
| Interactive Remote Access through an Intermediate System with encryption and MFA, plus vendor session disable | NERC CIP-005-7 | Vendor and engineer sessions must pass through a single intermediate host with encryption and MFA. The build needs a documented way to detect and end an active vendor session from inside the enclave, without depending on a cloud console. |
| Software integrity and authenticity for carried packages and patches | NERC CIP-013-2 | Every installer, container image, rule set and patch moved across the boundary on media needs a verification step, such as checksums or signatures, recorded in the change log. Confirm the vendor's signing practice and keep a copy of the verification method with the media record. |
Which platform fits which enclave constraint
JumpServer suits an enclave that must broker SSH, RDP, Kubernetes, databases and web access from one workspace, and that needs approval workflows before privileged sessions start. JumpServer describes itself as an open-source PAM platform and bastion host, and its Community edition is free for self-hosted use up to 5,000 assets in a standalone topology. Many enclave requirements, however, sit in the Enterprise tiers, so the feature list has to be checked against the design before the architecture is fixed.
- Edition boundary: Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, custom roles, multi-tenancy, SSO, RADIUS, LDAP HA and cloud asset sync are listed as Enterprise features.
- Asset ceiling: The Community edition is standalone and capped at 5,000 assets, and higher tiers add active-standby HA or a full HA cluster, which changes the network design.
- Offline install: The platform publishes container images on Docker Hub and an installer project, so the enclave team needs a plan to mirror both into the isolated registry.
- Support model: Community users rely on GitHub and the forum, while Enterprise adds email and ticket support with an SLA and an account manager.
- Licensing: JumpServer is GPL-3.0, so the team should confirm with counsel how modifications and distribution inside the enclave are treated.
Confirm with JumpServer which features in your enclave are included in the edition you plan to buy, and ask for the offline installation steps in writing before you commit.
Apache Guacamole fits an enclave where administrators and vendors need RDP, VNC or SSH access from a standard browser, with no client software on the workstation. It is a clientless gateway released under the Apache License 2.0, and version 1.6.0 was released on June 22, 2025. Its architecture separates the Java web application from the guacd daemon, which loads protocol plugins, so the components can be placed and hardened separately inside the enclave.
- Authentication extensions: The manual documents Active Directory and LDAP, Duo and TOTP multi-factor authentication, CAS, OpenID Connect, SAML and smart card single sign-on, and encrypted JSON or HTTP header authentication.
- Session recording: A session recording player extension is included in the documentation, which supports reviewing sessions stored on enclave media.
- Database backends: Guacamole stores its configuration in MariaDB or MySQL, PostgreSQL or SQL Server, so the database must be built and backed up inside the enclave.
- Installation options: Native and Docker installation are both covered, so the team can choose the method that fits its offline image process.
- Scope limits: Guacamole's web application speaks only the Guacamole protocol, so a new remote desktop protocol requires a plugin, and approval workflows and password vaulting are not part of the core product.
Before relying on Guacamole for an enclave, confirm which authentication extension you will use, how recordings are stored and reviewed, and which parts of the approval and credential workflow must be built or supplied by a separate tool.
Platforms that fit an isolated bastion and the trade-offs
An isolated bastion needs an access gateway, a way to authenticate users locally, and evidence stores that stay inside the enclave. The cards below cover the gateway options, the identity and secrets pieces that usually sit beside them, and the companion tools whose offline install paths matter most. Each choice carries licensing and packaging limits to confirm before the transfer media is ordered.
JumpServer as the bastion
JumpServer is a PAM platform and bastion host licensed under GPL-3.0. Its open-source core includes Lina for the web interface, Luna for the web terminal, and KoKo as the protocol connector and proxy, which together cover SSH and the other session types the enclave needs. Container images are published on Docker Hub and an installer project handles setup, so the offline transfer set is a known list of images and packages. Check which protocols you need against the Community edition, because several Oracle, SQL Server, RDP and database proxy components are listed as Enterprise features. Confirm the Community asset limit fits your enclave before you commit.
Apache Guacamole as a clientless gateway
Guacamole is a clientless gateway for VNC, RDP and SSH that runs from an HTML5 browser. The Java web application handles authentication and the interface, while the guacd daemon loads the protocol plugins that reach target machines. Installation works both natively and in Docker, and the manual documents database authentication on MariaDB, MySQL, PostgreSQL or SQL Server, so the account store can live inside the enclave. Plan for the session recording player extension and confirm that the protocols and extensions you need are included in the version you transfer. Guacamole has no native Kubernetes or database session model, so those paths need separate tooling.
Security Onion as a sensor and evidence store
Security Onion is not a bastion, but it is often the place where enclave access evidence ends up. Its ISO carries the packages along with NIDS, YARA and Sigma rules, so a full install does not need internet access. Updates in airgap mode come from newer ISO media via the soup tool, which means every upgrade follows the same media transfer and verification process as the bastion. Confirm that the license terms work for your organization, since the project uses the Elastic License 2.0, and decide which bastion logs and session metadata it should ingest.
Wazuh for host logs and offline detection
Wazuh publishes an offline installation guide for systems without internet connectivity, so its manager, indexer and agents can be deployed inside the enclave. For bastion work, it collects host and authentication logs from the jump hosts and target servers, and its vulnerability detection can run from an offline vulnerability repository instead of the cloud threat intelligence service. Confirm the vulnerability feed update process, because a stale offline repository weakens detection. The core repository is GPL-2.0 licensed, so review the license terms for any add-on components you plan to use.
Keycloak as a local identity broker
Keycloak can federate LDAP and Active Directory users, so the bastion authenticates against the directory that already lives in the enclave instead of a cloud identity provider. It also supports OpenID Connect, SAML 2.0 and clustering, which lets the bastion sit behind a local login that can enforce multi-factor authentication. Keycloak is Apache-2.0 licensed and is a CNCF incubation project. Confirm that the gateway you choose accepts the protocol Keycloak issues, and test group mapping and offboarding through the broker before go-live.
Secrets storage with OpenBao or Vault
If the bastion holds injected credentials or certificates, the secrets store has to run in the enclave too. HashiCorp Vault 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license, so confirm the license terms with your legal team before adopting it. OpenBao is MPL-2.0 licensed and hosted under the OpenSSF, and its v2.7.1 release was published on October 1, 2026. Confirm which features and upgrade paths your chosen store needs, and plan how its unseal material is handled offline.
How to install and patch the access layer without internet
Installing and patching a bastion inside an enclave starts outside it. Build a verified transfer bundle on a connected staging host that contains the installer, every container image, OS packages, browser or protocol plugins, and a manifest with SHA-256 checksums for each file. Inside the enclave, check the manifest against checksums recorded at build time, confirm who signed the bundle and from which source, and only then import it. Log every transfer with the bundle identifier, the operator, the media serial number, the approver and the import time. That log is the evidence that the access layer runs only the software you reviewed.
For JumpServer, the README asks for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM, installed with a quick_start.sh script from the GitHub releases. Confirm that script's dependencies (package manager repositories, Docker or container runtime, image pulls) before the bundle is built, because a script that quietly fetches a missing package will fail in the enclave. Load container images into a local registry and point the installer at it. If your enclave already runs Kubernetes, the same pattern applies: kubeadm can pre-pull control plane images and --image-repository points it at a private registry. Treat that as an analogy for your own workflow, not a JumpServer requirement. Guacamole offers a native install (the Java web application, guacd, and the protocol plugins) and a Docker install, and the choice should follow your team's ability to patch OS packages by media versus importing image tarballs.
Patching by media needs a rollback plan before the first update. Snapshot or back up the JumpServer data volumes and the database, keep the previous bundle on the media shelf, and write down the order of steps and the verification test (a test login, a recorded test session, and a check that recordings are still readable). Ask your vendor or implementation partner which upgrades require database migrations, because those are the hardest to reverse. Also confirm that session recordings and audit logs survive the upgrade and remain in the enclave. Apply patches to a non-production copy first, and schedule the cutover around change windows that the operations team already controls.
How a bastion rollout moves from design to evidence
The sequence turns an air-gapped bastion from a set of requirements into a tested, recorded and patchable access layer, with each phase closing on a document or artifact that an assessor or internal reviewer can inspect. Ownership and sign-off sit with the client, with DeployOpen typically preparing and executing the technical work under a written scope.
Define scope and target inventory
Start by listing every server, database, network device, Kubernetes cluster and vendor-facing system that the bastion will reach, along with the protocols each one needs (SSH, RDP, VNC, database clients or Kubernetes API). Record which enclave, zone or data classification each target sits in and who owns it. The output is a scope statement and a target inventory signed by the system owners. The step is complete when every in-scope target has a named owner and a protocol list, and anything out of scope is written down with a reason.
Design identity sources and MFA
Decide where users are authenticated inside the enclave: a local LDAP or Active Directory domain, a local identity provider, or local accounts for break-glass use only. Define how MFA is delivered without internet access, such as local hardware tokens or an on-premises TOTP or RADIUS service, and how dedicated administrator identities differ from everyday accounts. The output is an identity and MFA design record plus a role matrix. It is done when each role has a source of truth, an authentication method and a documented fallback if the directory is unavailable. Confirm which MFA options your chosen platform and edition support offline.
Build and verify the offline bundle
On a connected build host, collect the installer, container images, packages, OS updates and any rules or reference data the platform needs, then record each item with its version and checksum. Verify signatures or published hashes against the vendor's release channel before transfer, and keep the manifest with the media. The output is a signed offline bundle manifest and a transfer record. The step closes when the enclave side can reproduce the checksums on arrival and the manifest matches what was approved. Ask the vendor which artifacts are required for an air-gapped install and whether any licensing check calls out to the internet.
Stage the install and test access paths
Install the bastion and its supporting services in a staging copy of the enclave using only the transferred bundle. Connect a test set of targets, then exercise login through the identity source, MFA prompts, a session to each protocol, file transfer restrictions, and session recording. Test failure modes such as directory outage and certificate expiry. The output is a staging test report with pass or fail results per test case and a list of configuration changes. Done when every protocol in the inventory has a passing session and every recorded session can be found and played back.
Cut over and test break-glass access
Move the approved target list onto the production bastion in a planned window agreed with system owners, and retire direct access paths only after the bastion path is confirmed. Before closing the change, test the break-glass account under supervision, including how credentials are stored, who can retrieve them and how use is logged and reported. The outputs are a cutover record, an updated network and access diagram, and a break-glass test record. The step is complete when direct paths are disabled or documented as exceptions and a break-glass use has produced an audit entry that the security team reviewed.
Set recording retention and prove export
Define how long session recordings are kept inside the enclave, where they are stored, who may view them and how access to recordings is itself logged. Set the storage location and capacity alert, then test an export of a recording and its metadata to an approved evidence location that an auditor can read without internet access. The output is a retention schedule and an evidence export procedure with a sample export. The step is complete when a sampled session can be traced from the access request to the recording and the log entry, and the retention rule matches the framework or internal policy that applies. Confirm retention obligations with your compliance lead, since the bastion does not decide them.
Run the first media-based patch cycle
Repeat the offline bundle process for the first security update of the access layer. Build the update on the connected side, verify it, carry it across on approved media, apply it in staging, run the access test set again, then promote it to production with a rollback point. Record each transfer in the chain-of-custody log. The output is a completed patch record that shows the version change, verification results, staging test outcome and rollback plan. Done when production is on the new version, the regression tests have passed, and the patch record is filed with the change ticket. This cycle becomes the template for later updates.
Evidence auditors ask for from an offline bastion
This table lists the evidence an assessor typically samples from a bastion running inside an enclave, which component produces each item, and what the reader must confirm before the audit. Read each row as a question to answer during design, since the evidence only exists if the platform, its identity source and the media process were set up to generate it. The main takeaway is that most gaps come from settings and procedures that were never configured, not from missing features.
| Evidence | Component that produces it | What the reader must confirm |
|---|---|---|
| User access lists and unique identities | Bastion user and asset records, plus an export from the local identity source (LDAP or Active Directory) | Each administrator has a named account with no shared logins, and the export matches the bastion user list at the sample date |
| MFA enforcement evidence | Gateway authentication configuration and login logs, including the MFA factor used for each session | MFA is enforced for every protocol path, the factor is local to the enclave, and logs show a second factor on each login |
| Session recordings and retention | Session recording storage on the bastion or an enclave file store, with the recording player or export tool | Where recordings are stored, how long they are kept, who can view them, and that they are backed up inside the enclave |
| Approval and break-glass records | Ticket or approval workflow logs, and the break-glass account usage log | Approvals are recorded before access, break-glass use triggers an alert, and the reason and reviewer are captured |
| Vendor session disablement logs | Session termination records and access policy change logs on the bastion | Vendor access can be detected and ended promptly, and the disablement event is logged with timestamp and operator |
| Package integrity records for each media import | Hash and signature check records kept with the import log, plus the transfer manifest for each media set | Each package is verified against the vendor's published checksum or signature before install, and the verifier and date are recorded |
Questions buyers ask before an air-gapped PAM build
Can JumpServer or Guacamole run with no internet access?
Yes, both can be deployed in an enclave with no internet route, but the work is in preparing the offline media, not in the software itself. JumpServer installs from a quick start script that is normally fetched from the GitHub releases page, so the team must stage the installer, container images and dependencies on a transfer medium and verify them before import. Guacamole is an Apache-licensed gateway with a Java web application, a guacd daemon and protocol plugins, so the build set includes the server packages, the database backend and any authentication extensions. Confirm with the vendor which artifacts the installer pulls at runtime, because an installer that silently reaches out for packages will fail in a sealed network. A proof of installation in a lab network that mirrors the enclave is the most reliable test.
Which JumpServer edition does a regulated enclave need?
The edition choice depends on the features the enclave needs and on the asset count, not on the air gap alone. JumpServer's pricing page lists a free self-hosted Community edition up to 5,000 assets in a standalone topology, with Enterprise Basic, Standard, Pro and Ultimate tiers priced by quote. Several features that regulated teams often require, including Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, SSO, RADIUS and LDAP high availability, sit in Enterprise. High availability tiers are the cost driver when an active-standby pair is required. Ask the vendor to confirm in writing which features are included in each tier and whether the Enterprise support model works without internet access. Guacamole is Apache-licensed, so its licensing cost is zero, but extension, hardening and support work still carry cost.
How long does an air-gapped PAM rollout take, and what drives it?
The duration depends mainly on how many systems must be onboarded, how many identity sources are integrated, and how long change approvals take inside the enclave. Each protocol, such as SSH, RDP, Kubernetes or database access, needs its own connection test, account mapping and session recording check. Offline installation adds a media transfer cycle for every package, patch and rule set, and each transfer usually passes a security review. Teams should expect separate phases for build, lab validation, production cutover and vendor access onboarding. Ask for a written plan that lists the systems in scope, the change windows, and the acceptance tests. No timeline is given here because it depends on the environment; the scope agreed in writing will set the duration.
What must the client team provide before a bastion build starts?
The client team supplies the information and access that DeployOpen cannot infer from outside the enclave. Typical inputs include network diagrams that show zones, firewalls and the path from the bastion to targets, a list of target systems with protocols and owners, the identity sources such as Active Directory or LDAP and their certificate chains, and an inventory of MFA devices or tokens the enclave accepts. The team should also name a location for session recordings and backups, define retention rules, and confirm change windows and approvers. Access to a staging environment that matches production is valuable for lab testing. Requirements from frameworks such as NERC CIP-005-7 should be written down early because they set the access path and session controls. A kickoff checklist agreed before work starts prevents most rework.
Can our team administer the bastion after handover?
Yes, if the handover includes training, runbooks and a tested recovery path, and if the team has someone who can run Linux services and manage certificates and accounts. Day-to-day tasks include onboarding targets, managing roles, reviewing audit logs, rotating credentials and applying offline updates. The team should also own the procedure for importing vendor patches through the media transfer process and for checking their integrity before installation. Support from DeployOpen after handover is available through retainers, which are agreed in writing. Ask for documented procedures, a restore test, and a clear split of who approves changes. Teams with a small operations group often keep vendor support for upgrades and for recovery events.
How are session recordings stored and searched without internet access?
Recordings are stored on storage inside the enclave, and search works only on the data the platform indexes locally. Teams should decide where recordings live, how long they are kept, how they are encrypted at rest and who may replay them. JumpServer's session recording transcoding worker is listed among Enterprise components, so check whether the recording pipeline in your chosen edition works fully offline. Guacamole's manual describes a session recording player extension that replays recorded sessions, but the storage, retention and access controls around it must be designed by the team. Plan storage capacity from the number of sessions, the protocols used and the retention period, and confirm with the vendor how recordings are exported for an auditor. The FTC Safeguards Rule and HIPAA both expect activity logs to be reviewable, so search and replay need to be tested end to end.
How do we patch the access layer when nothing reaches the internet?
Patches arrive by media transfer, and each package must be verified before it enters the enclave. Start by subscribing to vendor security notices and by keeping a register of every component, including the operating system, JumpServer or Guacamole packages, database and certificate tools. Each update should be downloaded outside the enclave, checked against published checksums or signatures, scanned, and moved across the boundary under a documented procedure. NERC CIP-013-2 addresses verifying software integrity and authenticity for vendor software and patches, which is a useful model even outside utilities. Test every patch in a lab copy of the bastion before production. Confirm with the vendor what release cadence applies to the edition you choose and how long older branches are supported.
What should a vendor or implementation partner confirm in writing for an air-gapped build?
Ask for a written statement of scope that lists the protocols, target systems, identity integrations, edition, and each artifact the offline install needs. The statement should confirm which features work without internet access, including authentication, recording, backup and upgrades, and which features depend on online services. Ask how the partner handles evidence for compliance assessments, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications. Ask for acceptance criteria, a test plan, a handover schedule and the terms for post-handover support. Request a sample of the offline media process so you can judge whether your change board will accept it. Fixed scope agreed in writing is the normal basis for these engagements, so quotes should follow directly from that document.
What to ask an implementation partner before signing
Start with how the offline bundle is built and verified. Ask the partner to list every artifact carried across the boundary: the JumpServer installer and container images, the Guacamole web application, guacd and protocol plugins, the operating system packages, and any database or identity connector. Ask how each artifact is pinned to a version, how checksums or signatures are published and checked inside the enclave, and who holds the signing keys. Under NERC CIP-013-2, the procurement process for vendor software and patches must address verification of integrity and authenticity, so ask for that verification step to be written into the statement of work with a named owner. Then ask how edition and asset limits are confirmed in writing. JumpServer's Community edition is free up to 5,000 assets in a standalone topology, while high availability, Oracle and SQL Server access, password rotation, just-in-time approval and SSO sit in Enterprise tiers. Require the partner to name the edition, asset count, and topology in the quote, and to state which of your planned features are included.
Next, ask how recordings are retained, searched and exported without a network path to a central store. Confirm where session recordings are written, how long they are kept on enclave storage, how they are exported to offline archive media, and how integrity of exported files is shown. The HIPAA Security Rule at 45 CFR 164.312 and the FTC Safeguards Rule at 16 CFR 314.4 both expect activity to be recorded and examined, so ask how a reviewer finds a specific session months later. Ask how break-glass access works when the identity provider is unreachable: which local account exists, where its credentials are stored, who can unlock it, and how each use is logged and reviewed afterward. Ask how MFA is enforced at the gateway itself, including which factor types work offline and whether a local directory or Guacamole's TOTP or Duo extension is used. Finally, ask how patches cross the boundary, meaning the media transfer cadence, the verification steps, and the rollback plan. Ask what evidence the partner prepares for assessors, such as configuration baselines, access lists and transfer logs. DeployOpen prepares systems, controls and evidence for assessments, but does not issue audit reports or certifications, so confirm that the assessor and certification body are your own choices.
How DeployOpen scopes, builds and supports air-gapped PAM
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For privileged access, that means a bastion built, tested and handed over entirely within the enclave, with offline installation media, local identity sources and session recordings that never leave the boundary.
How we scope
- Inventory the protected systems, protocols and asset counts that the bastion must reach inside the enclave.
- Confirm which identity sources, such as local directories, must authenticate administrators without internet access.
- Agree in writing where session recordings are stored, how long they are kept and who can search them.
- Confirm which edition covers the required features, since air-gapped support is often a paid-edition feature.
How we build
- Prepare offline installation media and verify the integrity and authenticity of every package before it crosses the boundary.
- Configure the bastion, protocol connectors and local identity integration inside the enclave, with recordings stored on enclave storage.
- Test privileged sessions, approval paths, break-glass access and recording playback against the agreed scope.
- Document the access model, configuration baseline and the procedure for patching the access layer by media transfer.
How we hand over
- Deliver the written configuration, runbooks and offline update procedure to the operations team that will own the platform.
- Walk administrators through account onboarding, access requests and session review with the recorded evidence.
- Provide access-control and audit-trail evidence in a form that compliance leads and independent auditors can examine.
- Agree the handover acceptance criteria in the written scope before implementation begins.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
- Apply upgrades and security fixes through media transfer, with each package checked before installation.
- Re-test the access layer after changes to identity sources, protocols or the enclave network.
- Confirm support terms, response expectations and included services in the quote, since the company does not publish a price list.
