Zero trust network access for air-gapped networks starts with the boundary
Operators of isolated networks can run identity-based access without any internet dependency, but only if the control plane, identity provider, certificate authority and logs all live inside the boundary. A SaaS control plane or a public identity provider cannot be reached from a network that never touches the internet, so every component that issues identities, evaluates policy or records access must be installed on premises and verified offline before any application is moved behind it. This applies to utilities, plants, labs, classified or sensitive enclaves, and clinical or financial segments alike. The design question is where each component sits. The controller or management plane, the identity provider that authenticates people and devices, the certificate authority that issues workload and user certificates, and the log store all need to be inside the isolated network. If any of them depends on an outside service for token validation, certificate revocation checks, software updates or telemetry, the boundary is not isolated. Confirm with each vendor which features require outbound connectivity, which can use local certificate revocation data, and how package and container images are imported across the boundary with integrity checks. For the platform choice, OpenZiti fits best where services should be dark with no listening ports, since its edge routers and tunnelers connect outward and access can be revoked immediately, and where SDK or tunneler access suits the applications. NetBird fits where an overlay network with self-hosted management is the goal, using a combined management, signal, relay and STUN configuration and an embedded identity provider that can be pointed at an internal one. Its self-hosting quickstart assumes a public domain and Let's Encrypt by default, so an isolated install needs its own certificate and DNS plan. Offline support depends on edition and vendor documentation, so confirm in writing that the exact edition supports a no-internet install before committing.
Which regulations shape an isolated ZTNA design
This table maps four regulatory requirements to what each one asks for on a network with no internet path and what that means for the ZTNA build. Read each row as a design input to settle before choosing components, since the control plane, logs and vendor access paths all follow from it. The main takeaway is that the regulations shape where the control plane sits, how vendor sessions are brokered and how every package crossing the boundary is verified.
| Requirement | What it asks for | What it means for the isolated build |
|---|---|---|
| NERC CIP-005-7 (interactive remote access) | Interactive remote access to high and medium impact BES Cyber Systems passes through an Intermediate System with encryption and multi-factor authentication, and active vendor sessions can be detected and disabled. | Place the ZTNA broker or edge router as the Intermediate System in front of OT segments, require MFA on every vendor identity, and build a way to list and terminate live sessions from inside the boundary. |
| NERC CIP-013-2 (vendor software and patches) | Supply chain procurement processes address verification of software integrity and authenticity for vendor software and patches. | Every container image, package, certificate bundle and ZTNA client installer carried across the air gap needs a recorded hash or signature check before import, and the ZTNA components must be included in that vendor review. |
| HIPAA 45 CFR 164.312 (technical safeguards) | Access control with unique user identification, audit controls that record and examine activity in systems holding ePHI, person or entity authentication and transmission security. | Issue one identity per clinician or service account, forward ZTNA and application access logs to an on-premises store that reviewers can examine, and confirm that service-to-service traffic is encrypted end to end. |
| FTC Safeguards Rule 16 CFR 314.4(c) | MFA for any individual accessing any information system, encryption of customer information in transit and at rest, and monitoring and logging of authorized user activity. | Enforce MFA at the identity provider used by the overlay or proxy, keep certificate and key stores encrypted at rest inside the isolated zone and retain logs of who reached which dark service and when. |
How offline installs differ across the stack
Clusters and virtual machines are the first thing to prepare, because every component above them depends on their images and binaries. Kubernetes can be built without internet access. Operators run kubeadm config images list to see which control plane images a version needs, pull them ahead of time with kubeadm config images pull, and point kubeadm init at a private registry with the --image-repository flag. The work is planned on a connected staging network and then carried across the boundary.
- Image inventory: Record every control plane, add-on and platform image with its exact tag, so the list can be reviewed before transfer.
- Private registry: Host the images in a registry inside the isolated network and confirm that every node resolves it.
- VM baselines: Build operating system images, packages and time sources from media that were verified before entry.
- Certificates and DNS: Plan internal names and certificate authorities in advance, since public services cannot issue them offline.
Confirm with your platform team which Kubernetes version and add-ons your chosen ZTNA controller requires, then test the full bootstrap on an isolated lab before the production build.
Mirrors carry the software that the platform installs and updates, from operating system packages to container images and language libraries. Each mirror needs a defined source, a transfer method and a verification step before anything enters the isolated network. This is where supply chain controls are applied in practice, and NERC CIP-013-2 is one framework that expects procurement processes to address software integrity and authenticity for vendor software and patches.
- Source selection: Pull packages only from the vendor repositories you have approved, and keep a record of the release each one came from.
- Integrity checks: Verify checksums and signatures on every artifact before import, and keep the results with the transfer record.
- Transfer media: Define the approved route for moving data across the boundary, including who authorizes it and how the media is logged.
- Dependency coverage: Mirror transitive dependencies as well as direct ones, since a missing library is a common cause of failed offline installs.
Ask the implementation partner to show the full transfer chain for one component, from download to import, before the first production install.
Several security and collaboration platforms publish their own offline procedures, and they differ in how much they expect to fetch at install time. GitLab documents running self-managed instances in offline, air-gapped environments, and it provides separate guidance for running its security scanners and for GitLab Duo Self-Hosted offline. Security Onion supports full installs without internet access, because its ISO carries packages along with NIDS, YARA and Sigma rules. Wazuh publishes an offline installation guide for systems without connectivity.
- Security Onion media: The ISO carries the packages and detection rules needed for a full install, so the transfer unit is the ISO image itself.
- Wazuh vulnerability data: Vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, which must be built and refreshed deliberately.
- GitLab scanners: Security scanning in an offline instance is documented separately from the core install, so plan for it as a distinct item.
- Feature gaps: Some features in these platforms need external services, so list each one and confirm whether an offline alternative exists.
Read each vendor's offline guide against your target version before you commit to a design, and record which features you will run without external data.
Installation is a one-time event, but updates recur for the life of the platform, and they are where many isolated deployments drift. Security Onion's soup tool updates from newer ISO media in airgap mode, so each update is a new media release that must be carried across the boundary. Wazuh rule and vulnerability content also needs a refresh path. Plan updates as a standing process with a schedule, a test environment and a rollback plan.
- Update cadence: Set how often media and content are carried across, and who approves each transfer.
- Staging copy: Test each update on a lab copy of the production stack before it reaches the isolated network.
- Content freshness: Track the age of detection rules and vulnerability data, since stale content weakens coverage without any visible error.
- Rollback path: Keep the previous media and configuration so a failed update can be reversed inside the boundary.
Ask the partner how updates are packaged, verified and documented, and whether the process covers both platform versions and detection content.
Air-gapped support is often tied to a paid edition, so the offline design depends on licensing as much as on technology. Mattermost lists air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from the free Starter plan, and Metabase offers it only on its Enterprise plan. Element Server Suite has a free AGPL Community edition, a Pro edition and a Sovereign edition for air-gapped deployments. Plane offers Community, Commercial and Airgapped self-hosted editions, and its Community edition is AGPL-3.0 while the Commercial and Airgapped editions are proprietary.
- Named features: Confirm in writing that offline installation and updates are included in the edition you plan to run.
- Separate codebases: Where an edition is a distinct codebase, as with Plane, plan for its own release cycle and migration path.
- Support scope: Check whether support covers the offline update process, not only the online product.
- Exit terms: Ask what happens to a running deployment if the license lapses or changes.
Confirm edition rights and the offline feature list with each vendor before the design is approved, because a later change of edition can force a re-architecture.
Which ZTNA platform fits an air-gapped network and why
An isolated network changes what each ZTNA component must do on its own: the control plane, the data plane, the identity provider and the certificate authority all have to run inside the boundary. The cards below cover the platform choices and supporting components, and what to confirm for offline operation before you commit.
OpenZiti as the overlay in the boundary
OpenZiti puts the controller and edge routers inside your boundary, and its private routers make only outbound connections, so no inbound firewall rules are needed. Services can be dark, with no listening ports, and revoking an identity ends active connections at once. Choose between tunnelers for unmodified software and SDKs for applications you build or control. The platform is Apache 2.0 licensed, and v2.0.6 is the latest non-prerelease 2.0 release. Confirm that your chosen tunnelers and SDKs run without any outbound calls.
NetBird self-hosted as a WireGuard overlay
A self-hosted NetBird deployment runs management, signal, relay and STUN from one combined configuration, with a dashboard, a Traefik reverse proxy and an embedded Dex identity provider. Traefik requests Let's Encrypt certificates by default, which an isolated network cannot reach, so you must replace that path with an internal certificate authority. The repository is BSD-3-Clause, but the management, signal, relay and combined directories are AGPLv3, so review that split with counsel. The latest release we list is v0.81.2.
Keycloak or authentik as internal identity
An overlay or proxy trusts whatever identity provider you give it, so the provider must live inside the boundary and reach your directory without internet access. Keycloak supports OpenID Connect, SAML 2.0 and LDAP or Active Directory federation, and it is Apache-2.0 licensed. authentik is MIT licensed apart from its enterprise directory, which carries a separate license. Confirm that the provider's MFA and passkey methods work with no external calls, and that NetBird's embedded Dex or your chosen external provider can point at it.
OpenBao for internal certificates and keys
Every tunneler, edge router and NetBird peer needs a certificate that chains to an authority you control, because public certificate authorities are unreachable from the isolated network. OpenBao can issue and rotate secrets, certificates and keys, and it is MPL-2.0 licensed under the OpenSSF. HashiCorp Vault 1.15.0 and later uses a Business Source License, which is not OSI-approved, so check that licence fits your procurement rules. Confirm which certificate issuance flows OpenBao supports offline, and how you will rotate the trust roots that OpenZiti and NetBird depend on.
Choosing between the two overlays
OpenZiti fits when you need dark services, app-level encryption through its SDKs, or tight control of who can dial each service. NetBird fits when you need a familiar peer-to-peer network with routes into existing segments, exit nodes and device posture checks. Both can run in a boundary with no internet, but the NetBird quickstart assumes a public domain and open ports 80, 443 and UDP 3478, so those assumptions must be removed. Run a proof of concept in a lab that mirrors your isolation rules before committing to either.
Integration points for certificates, identity and logs
An air-gapped ZTNA deployment depends on four integration points that run entirely inside the isolated network. Each one must be designed before the overlay goes live, because none of them can fall back to an internet service when something breaks.
Internal identity provider and MFA
The overlay can only authorize users that an identity provider vouches for, so the build needs an identity provider inside the enclosure that federates with the internal directory and enforces MFA. Confirm which directory is the source of truth, how group membership maps to access policy, and whether the MFA factors work with no outbound calls to a vendor cloud. Test a full login and a revoked account with the network cut off from the internet, since that is the condition the design must handle.
Internal PKI for controller and service identities
OpenZiti issues x509 identities to every controller, router, tunneler and SDK-embedded application, so a private certificate authority must exist before the first enrollment. The build must define who holds the root key, how intermediate authorities are issued and rotated, and where enrollment tokens are stored and expired. Ask the vendor how certificate renewal behaves when the controller is offline for a period, because an expired identity can silently cut off an isolated site.
Offline transfer path for packages
Every software update, container image, rule set and vulnerability feed that crosses into the enclosure needs a documented transfer path and an integrity check at the boundary. The build must produce a manifest of hashes and signatures, verify them on the inside, and keep an audit record of each import. Map this path to the supply chain controls your sector expects, and confirm with each vendor which artifacts are signed and how their offline bundles are verified.
Controller and router logs into local SIEM
The OpenZiti controller and edge routers produce authentication, policy and connection events that must reach a SIEM running inside the enclosure, such as Wazuh or Security Onion. The build must define the log format, the forwarding agent, the retention period and who reviews alerts for revoked identities or denied dial attempts. Confirm that the SIEM ingests these events without a cloud component and that its own updates follow the offline path above.
How an isolated ZTNA rollout runs in phases
The sequence moves an isolated network from an inventory of what must be reached to a tested, dark-service overlay that runs beside the VPN until the team is confident enough to retire it. Each phase closes with a named output that the next phase depends on.
Map the boundary and inventory assets
Architects and network owners record every enclave, its trust level, the applications and protocols that must be reached, the users and service accounts that need them, and the systems that can never accept inbound connections. Security and operations sign off on the list. The output is a signed boundary and asset inventory that defines which services become dark and which identities may reach them. The phase is complete when every in-scope service has an owner and a documented access need.
Import and verify offline artifacts
Engineers build a transfer bundle outside the boundary containing container images, packages, OpenZiti or NetBird release artifacts, operating system repositories and rule sets, then carry it across through the approved transfer process. Inside the enclave, they verify checksums and signatures against the vendor publications and record the result. The output is a verified artifact repository and a transfer log that a reviewer can follow. Confirm with the vendor which signing keys and release channels apply to your edition, and check the supply chain control your regulator expects for software carried across the boundary.
Build the control plane inside the boundary
Platform engineers deploy the OpenZiti controller and edge routers, or the NetBird management, signal, relay and STUN components, on infrastructure inside the enclave, pointing container and package sources at the internal mirror. They configure high availability, backups and the admin console only on the management network. The output is a running control plane that answers health checks and issues no traffic yet. Confirm with the vendor how the chosen edition handles upgrades without internet access, since the self-hosting guidance places backups, upgrades and scaling on the operator.
Issue internal identity and certificates
The team connects the control plane to the internal identity provider, such as Keycloak, an Active Directory federation or another directory approved for the enclave, and sets up an internal certificate authority or the platform's own certificate issuance. Groups from the directory map to access policies, and multi-factor authentication is enforced for every human identity. The output is a tested set of enrolled identities, certificates with documented lifetimes and renewal steps, and a rule that no identity can reach a service without a policy. Confirm how the chosen platform handles certificate revocation when the network cannot reach a public responder.
Pilot a small set of dark services
The team selects a few services with clear owners and low operational risk, configures them as dark services with the tunneler or SDK beside each application, and lets only the named groups dial in. Engineers confirm that the service accepts no inbound connections, that revoking a user ends active sessions, and that users can complete the task without the VPN. The output is a pilot report listing each service, its policy, the test results and the issues raised. Pilot users should include at least one administrator who can operate the system without the vendor on site.
Test lateral movement and validate logs
An independent tester, either an internal red team or an outside firm, attempts to reach services from enclaves, compromised endpoints and pilot identities that should have no access. They check whether a stolen session can pivot to adjacent hosts, whether policies block unlisted ports, and whether the control plane and tunnelers write the events needed for audit, such as authentication, policy decisions and session start and end. The output is a findings register and a logging validation record that maps each audit event to the evidence it supports. Fix and retest all high-severity findings before moving on.
Cut over with the VPN retained
Operations moves user groups onto the overlay in waves, keeping the VPN available for an agreed period so that staff can fall back if a service breaks. Each wave has a rollback plan, a named owner and a check that the logs reach the monitoring platform. The VPN is switched off only after the business owners accept the migrated services and the security team confirms that the retirement plan, access reviews and evidence are in place. The output is a cutover record, an updated access procedure and a decommissioning plan for the VPN, with the retention period set in writing.
Evidence an auditor will ask for from an isolated ZTNA
This table maps each piece of evidence an assessor is likely to request from an isolated zero trust deployment to the component that produces it and the gap to confirm before the assessment. Use it to check whether logs, policy history and offline import records exist in your design. DeployOpen prepares this evidence, but auditors and assessors issue any opinion on whether controls are effective.
| Evidence | Producing component | Gap to confirm |
|---|---|---|
| Access decisions and policy versions | OpenZiti controller policy history and admin audit records | Confirm the controller retains versioned policy changes offline and can export them for a fixed review period |
| Connection and session logs | OpenZiti controller and edge routers, plus tunneler or SDK host logs | Confirm which events are logged at each edge router and whether logs stay inside the enclave |
| Revocation records showing active sessions terminated | OpenZiti controller revocation events and router session teardown logs | Test revocation on a dark service and confirm the termination timestamp is recorded |
| MFA enforcement records | Internal identity provider such as Keycloak or ZITADEL authentication events | Confirm MFA events are written per login and map to the user IDs used in the controller |
| Certificate inventory and renewal logs | Internal CA or OpenBao PKI, plus controller x509 identity issuance records | Confirm an inventory of issued identities exists and that renewal and expiry events are logged |
| Artifact integrity records for offline imports | Checksum and signature verification logs from the transfer process and offline media records | Confirm each package, image and rule set carried across the boundary has a recorded hash and verification step |
| Network boundary and device inventory | NetBird management records or controller router inventory, plus host inventory tooling | Confirm the inventory of routers, tunnelers and dark services is complete and reconciled against the enclave |
What do buyers ask before running ZTNA in an air-gapped network?
What drives the cost of an air-gapped ZTNA deployment?
The cost depends on the written scope, so there is no fixed price to quote here. The main components are the design work, the installation of the control plane and edge routers inside the boundary, identity and certificate integration, migration of each application, and handover documentation. Most of this is one-time. Recurring costs are operations, the offline update process, and any support retainer. Edition licensing matters too: OpenZiti is Apache 2.0 licensed and NetBird's self-hosted components are split between BSD-3-Clause and AGPLv3, but some vendors reserve air-gapped deployment for paid editions, so confirm in writing which edition and features you need. Ask for a quote that separates one-time and recurring items.
How long does an air-gapped ZTNA rollout take?
The timeline depends mainly on boundary complexity, the number of applications to migrate, and how the offline import process is approved and run. A single enclave with a few internal web apps is simpler than several isolated networks with overlapping address ranges and separate identity providers. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for the schedule to be tied to specific milestones such as the offline bundle transfer, the first dark service and the first migrated application. Confirm the change approval window with your security team before you agree a date.
What does the client team need to provide for the project?
The work needs named people from several teams. Boundary owners approve which networks the controllers, routers and tunnelers may reach and how traffic crosses the enclave edge. Identity owners provide the internal identity provider, groups and MFA method. PKI owners decide how the internal certificate authority issues and renews identities, since OpenZiti issues x509 identities for every participant. Change advisory approvers must sign off on installation and each import of software into the isolated network. Application owners confirm which services are migrated and who tests them. Agreeing these owners early usually shortens the schedule more than any technical choice.
Can our own team run an air-gapped ZTNA platform without a partner?
Yes, a capable internal team can run it, provided it has working skills in Linux administration, certificate lifecycle management and identity federation, and a documented process for offline updates. Day-to-day tasks include adding identities and services, reviewing policies, rotating certificates, backing up the controller, and staging each release. Teams that lack one of these skills often choose a partner for the initial build and keep operations in-house. DeployOpen plans, implements, documents and supports self-hosted platforms inside the client's own network, and ongoing support is available as a retainer. Ask any provider to name which tasks it hands over and which it keeps.
How do we update an isolated ZTNA platform and verify the packages?
Updates arrive as reviewed bundles that cross the boundary through an approved transfer path. Each package should be checked against the publisher's published checksums or signatures before import, and the verification result should be recorded in the change ticket. NERC CIP-013-2 is a useful reference for regulated operators, since it expects procurement processes to address the integrity and authenticity of vendor software and patches. Keep a staging copy of the previous release so you can roll back. Track the OpenZiti and NetBird release notes separately, because prerelease builds and stable releases follow different schedules, and only promote stable builds into production.
How do we retire the VPN safely after the ZTNA platform is live?
Retire the VPN one application at a time, not all at once. Start by publishing a small set of internal services as dark services, where the service or its tunneler dials out to an edge router and no inbound ports are opened. Run both paths in parallel, move users group by group, and watch the access logs for failed connections. Once an application works through the overlay and its users are confirmed, remove its VPN route and the matching firewall rule. Revoking an identity in OpenZiti terminates its active connections immediately, so keep the revocation procedure tested before cutover. Keep the VPN concentrator available until the last application is verified.
Which compliance evidence does a ZTNA platform in an isolated network produce?
The platform produces evidence for access control and audit requirements, but it does not create an audit report on its own. Typical evidence includes the policy export showing which identities reach which services, the list of authenticated sessions, and the logs of connection and revocation events. For a HIPAA covered entity, the technical safeguards in 45 CFR 164.312 cover unique user identification, audit controls and person authentication. For a financial institution, the FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication and logging of authorized user activity. Auditors and certification bodies make the determination, so confirm the evidence format with your assessor early.
What to ask an implementation partner before an isolated build
Start with the offline artifact supply chain, because an isolated network is only as trustworthy as what crosses the boundary. Ask the partner to list every artifact in the build: OpenZiti controller and router binaries, NetBird management, signal, relay and STUN components, tunneler packages, container images, operating system packages and any Wazuh or Security Onion updates. For each one, ask how it is obtained, how its hash or signature is verified before import, who approves the transfer, and where the record is kept. Ask how they map this to the software integrity expectations in NERC CIP-013-2 if your environment falls under that standard. Also ask which images are pulled through a private registry, and how the partner confirms that no build step quietly reaches out to a public source.
Next, ask where the control plane and logs run and who can read them. For OpenZiti, the controller issues and verifies identities and holds the service policies, so ask whether it runs on hardware inside the enclave with its own backups, and whether edge routers in the trusted zone dial out only to approved peers. For NetBird, ask how the self-hosted quickstart components are split, how the embedded identity provider is configured without an external SSO, and which component writes the activity and traffic event logs. Ask where those logs are forwarded, how long they are kept and how the partner proves that the logs contain the unique user identity and access decisions your audit controls need.
Then test the lifecycle questions that most isolated builds leave open. Ask how internal certificates are issued, rotated and revoked when there is no public certificate authority to fall back on, and which tool holds the signing keys. Ask how revocation is tested: the partner should demonstrate that disabling an identity ends active sessions and that a dark service stops answering. Ask for a documented lateral movement test that starts from a compromised endpoint in one zone and shows what it can reach. Finally, confirm edition and licensing rights in writing, because some vendors reserve air-gapped deployment for paid editions, and ask what documentation, runbooks, configuration exports and test evidence will be handed over at the end of the engagement.
How DeployOpen scopes and builds isolated ZTNA
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For isolated ZTNA, we start from the network boundary and the identities that must reach each application, then build the access layer entirely inside that boundary.
How we scope
- Inventory which internal applications, SSH hosts and network segments need dark-service access and which must stay unreachable.
- Confirm the internal identity provider, certificate authority path and how signed software packages will cross the isolated boundary.
- Agree the written scope, deliverables and timeline before any work starts, with ongoing support available as a retainer.
How we build
- Deploy the OpenZiti controller and edge routers, or the NetBird management stack, on the client's own hosts with no internet dependency.
- Configure dark services so applications expose no listening ports and connect outbound to in-zone edge routers only.
- Test revocation, policy enforcement and lateral movement paths, then document results against the agreed acceptance criteria.
How we hand over
- Deliver architecture diagrams, runbooks for identity, certificate and policy changes, and the offline package update procedure.
- Document which edition features the air-gapped design depends on, so the client can confirm licensing before go-live.
- Walk operations staff through access reviews, log export to the client's SIEM and backup and restore of control plane data.
How we support
- Provide upgrade, patch and configuration support under a retainer, including review of each signed package before it enters the enclave.
- Run recurring security testing of access paths and the control plane, with findings tracked to closure.
- Prepare the access control, audit log and transmission security evidence the client's assessor will ask for, without issuing any attestation.
