--- title: ZTNA for Air-Gapped and Isolated Networks | OpenVPN Blog description: Every major ZTNA platform assumes it can reach its own cloud. Here's what Zero Trust looks like when the network can't reach the internet at all. image: https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_1_V1.png --- - [Blog](https://blog.openvpn.net) - [Zero Trust](https://blog.openvpn.net/tag/zero-trust) - [self-hosted](https://blog.openvpn.net/tag/self-hosted) - [ztna](https://blog.openvpn.net/tag/ztna) # ZTNA for Air-Gapped and Isolated Networks Oct 12, 2026 • 11 min read ![](https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_1_V1.png) Share - - - - ZTNA for Air-Gapped and Isolated Networks | OpenVPN Blog 14:59 By Heather Walters ## ZTNA is a different beast when the network is completely isolated. There's a conversation that happens in defense, classified, industrial, and some research environments, and it stalls in the same place every time.  Someone says the organization should adopt Zero Trust. Everyone agrees. Then someone asks which platform, and the answer is that every product on the shortlist requires outbound connectivity to the vendor's cloud to make an access decision—and this network doesn't have outbound connectivity to anything, by design and often by law. At which point the conversation usually concludes that Zero Trust isn't available here, and the network keeps running whatever it was running. That conclusion is wrong, and it's worth unpacking why. ## **Why every platform assumes it can phone home** Cloud-delivered ZTNA works by putting the policy engine in the vendor's infrastructure. Connectors inside your network dial out; users authenticate against the vendor's service; the vendor decides; the connector enforces. That architecture has real advantages, and one hard requirement: something inside your network must be able to reach the vendor continuously for access to work at all. Not once at setup — every time a decision is made. In an isolated network, that requirement isn't inconvenient; it's disqualifying. There's no firewall rule to write. The egress path doesn't exist, and creating one would defeat the reason the network is isolated. [![Subnet Calculator Blog Image CTA ](https://no-cache.hubspot.com/cta/default/43411546/d6dc0237-1a8c-4671-8c67-4261b3f56777.png)](https://cta-redirect.hubspot.com/cta/redirect/43411546/d6dc0237-1a8c-4671-8c67-4261b3f56777) So the question isn't which cloud ZTNA product tolerates poor connectivity. It's whether Zero Trust is achievable with no connectivity, and the answer is yes — because nothing in the architecture requires the internet.[NIST SP 800-207 describes a policy engine, a policy administrator, and enforcement points](https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf), and is entirely silent on where they run. An enclave with its own policy engine inside it satisfies the architecture completely. It takes putting all five components — data plane, control plane, certificate authority, policy store, and logs — inside the boundary. Which, if you're air-gapped, you were going to do anyway: the data plane is the one component an isolated network never had a way to give away. [![openvpn\_ztna-research-report\_email\_800x200](https://blog.openvpn.net/hs-fs/hubfs/openvpn_ztna-research-report_email_800x200.png?width=2500&height=625&name=openvpn_ztna-research-report_email_800x200.png)](https://go.openvpn.net/ztna-research-report-2026) ## **The four problems ZTNA vendors usually encounter** The architecture is straightforward. The operational details are where isolated deployments get difficult, and they're rarely discussed because most vendors never encounter them. ### **1. Certificate lifecycle with no reachable CA** Certificate-based authentication is the right foundation here — it's strong, it doesn't depend on a live identity provider at connect time, and it gives you real revocation. But the modern PKI ecosystem assumes reachability. Automated issuance depends on a public CA. Revocation checking assumes clients can fetch a CRL from a distribution point or query an OCSP responder. Short certificate lifetimes only work when renewal is automated. Inside an enclave, all of that has to be internal: - **Run your own CA inside the boundary.** Offline root, issuing intermediate, and ideally the root's private key on an HSM or smartcard in a safe. - **Host the CRL distribution point and OCSP responder internally**, and make sure the URLs baked into issued certificates point at internal names that resolve inside the enclave. Get this wrong and clients will attempt revocation checks against an unreachable address — which, depending on configuration, either fails closed and blocks everyone or fails open and silently stops checking revocation. Neither is what you want to discover during an assessment. - **Choose certificate lifetimes you can actually service.** Ninety-day certificates are excellent practice when renewal is automated and painful when it's a person with a checklist. Either build the internal automation or use longer lifetimes with tighter revocation — and be able to explain the choice. ### **2. MFA enrollment without an identity provider round trip** Cloud MFA doesn't work here. Push notifications need the internet. SMS needs a carrier. A hosted identity provider needs to be reachable. Two things work well: **TOTP with an internal enrollment flow.** The server generates the secret and presents a QR code; the user scans it with an authenticator app on a phone; verification happens entirely inside the enclave. No external dependency at any point. The wrinkle is that if phones aren't permitted in the facility — common in these environments — you need dedicated hardware TOTP devices instead. **Hardware tokens, which are the better answer.** A PIV-capable smartcard or security key holding the client certificate needs no network, no time synchronization, and no identity provider. The factors become possession of the token and knowledge of its PIN, both of which are verified locally. For an air-gapped network, hardware-backed certificate authentication is close to ideal — and it happens to align with the smartcard credentials many of these organizations already issue for physical access. ### **3. Time synchronization, which nobody thinks about until it breaks** TOTP is time-based. Codes are computed from a shared secret and the current time in thirty-second steps. If server and client clocks drift apart by more than the tolerance window, authentication fails for reasons that look nothing like a clock problem. Connected networks solve this invisibly with public NTP. Isolated networks have no such thing, and unsynchronised clocks in a room full of VMs will drift. You need an authoritative internal time source: a GPS-backed stratum-1 appliance is the usual answer where a sky view is possible, and where it isn't, a well-maintained internal NTP hierarchy with a documented drift budget. Whatever you choose, monitor it — clock drift is the failure mode most likely to produce a confusing outage six months after a successful deployment. This is also the strongest practical argument for hardware tokens over TOTP in these environments: certificate authentication doesn't care what time it is. ### **4. Getting software in** Your VPN server needs patching. So does the OS under it. In an air-gapped network, there's no package repository to pull from. The realistic options are an internal mirror populated through whatever your approved transfer process is, a one-way data diode if you have one, or a documented manual procedure with integrity verification. Whichever it is, it needs to be a *routine* — quarterly at worst — because an isolated network is not a safe network, and unpatched access infrastructure inside an enclave is still unpatched access infrastructure. Verify signatures on everything that crosses the boundary. The transfer process is the enclave's largest attack surface, and it's the one people take for granted. ## **What you can achieve** With those four handled, an isolated deployment can genuinely offer: - **Explicit identity verification** against an internal directory, with hardware-backed certificates - **Multi-factor authentication**, verified locally - **Least-privilege access** scoped per group or per user, enforced by internal policy - **Application-level rather than network-level access**, so an authenticated user gets a path to one resource and no route to anything else - **Complete audit logging** held entirely inside the boundary, which in this context is a feature rather than a constraint — your evidence has never left your control Compared with what these networks typically run — a flat internal network where anyone who's physically present can reach everything — that's a substantial improvement, and every part of it is available without a single outbound packet. ## **Degrees of isolation** Worth distinguishing three cases, because they're often discussed as one and the engineering differs. **Fully air-gapped.** No network path in or out. Everything above applies, and software transfer is a manual process. **Restricted egress.** Outbound connectivity exists but is tightly allowlisted, often through a proxy with inspection. Some cloud services are technically reachable, but each allowlist entry is a documented exception someone must justify — and a ZTNA product that needs continuous outbound access to a vendor's cloud is a permanent, high-volume exception rather than a one-off. Self-hosting removes the exception entirely, which is frequently an easier argument to win than the technical one. **Cross-domain.** Two networks at different classifications with a controlled interface. The access architecture on each side is a separate design problem, and the guarded interface between them is governed by rules well outside the scope of any VPN product. The middle case is the most common and the most winnable. Organizations often think of themselves as air-gapped when they actually have restricted egress, and the practical benefit of self-hosting there is less about capability and more about not having to defend a standing firewall exception every audit cycle. ## **The compliance angle** For defense contractors, [CMMC Level 2](https://openvpn.net/openvpn-compliance/) requires the 110 controls in NIST SP 800-171, several of which land squarely on remote access — access enforcement, least privilege, session control, [cryptographic protection of remote sessions](https://openvpn.net/as-docs/fips-compliance.html), and audit record generation and retention. Nothing in those requirements mandates self-hosting. But two things follow from an isolated architecture that assessors tend to like: your audit records demonstrably never left your control, and there's no third-party processor in your remote access path whose own compliance posture you'd need to evidence. The second point is worth more than it sounds during an assessment, because a subprocessor in the access path is a question that generates further questions. For ITAR-controlled technical data, the relevant concern is access by foreign persons and export of controlled data. An access architecture where no third party holds the data or the access decision is a materially simpler story to tell than one involving a vendor cloud, wherever that cloud is hosted. ## **If this is your environment** The honest summary: Zero Trust is achievable in an isolated network; the architecture is not the hard part, and the difficulty is concentrated in PKI lifecycle, local MFA, time synchronization, and patch transfer. If you're being told Zero Trust isn't available for air-gapped networks, what you're actually being told is that cloud-delivered ZTNA isn't available for air-gapped networks. That's true, and it's a much narrower statement. Access Server runs entirely inside a boundary with no external dependency at runtime, which is why it turns up in these environments. Whether it's right for you depends on specifics worth an actual conversation rather than a web page—particularly around your PKI, your accreditation requirements, and how you handle software transfer. ### Ready to see how OpenVPN can help protect your organization from attacks? Try the self-hosted Access Server solution or the managed CloudConnexa service for free, no credit card required. [See Which One is Right for You](https://openvpn.net/product-comparison/?_gl=1*1hi46u*_ga*NDgyODEwNDkyLjE3NzIxMjIzNDE.*_ga_E45Z33NTV7*czE3Nzc5ODY2ODIkbzExMiRnMSR0MTc3Nzk4ODMyMSRqNTUkbDAkaDE4NzIyNTczNDc.*_fplc*dVltNzJ6YmZ0bFZTdld4NjRtWVpVWXclMkJEV3AzZGhPUlRZaUppdWNxQkRjOER3MFN0VW84JTJCdEJGdnRDTmVYNlI5NlJBdTRLZ0VGOTNHMHc0U3l3bVFsR3NzQXk5RzJIQVdzNHE0QVJHcSUyQlVKUlRsNTM0S1RWZERyZ0V4NDNnJTNEJTNE*_gcl_au*MTM5NjEwNTIxNy4xNzcyMTIyMzQx*_ga_SPGM8Y8Y79*czE3Nzc5ODY2ODEkbzExMyRnMSR0MTc3Nzk4ODMyMyRqNTMkbDAkaDA.) ## Frequently asked questions ### **Can an air-gapped computer connect to the internet?** By definition, no — an air-gapped system has no network path, wired or wireless, to any external network. In practice, "air-gapped" is often used loosely for networks with heavily restricted rather than absent egress, and the distinction matters: a truly isolated network cannot use any cloud-dependent service, while a restricted-egress network can, at the cost of a documented and permanently maintained firewall exception. ### **Can air-gapped systems be compromised?** Yes. Isolation reduces the attack surface substantially but doesn't eliminate it. Realistic vectors include removable media, the supply chain for software and hardware brought across the boundary, insiders with physical access, and the transfer process itself—which is usually the weakest point because it's routine. This is why least-privilege access control still matters inside an enclave: physical presence shouldn't grant access to everything, and a flat internal network means one compromised workstation reaches the whole environment. ### **Is air gap security still relevant?** Yes, for environments where the consequence of compromise is severe enough to justify the operational cost — classified systems, industrial control and safety systems, and some financial and research infrastructure. What has changed is that air-gapping is no longer treated as sufficient on its own. Modern practice is defense in depth inside the enclave too, which is exactly where Zero Trust principles apply. ### **What's an example of an air-gapped network?** Common ones include classified government and military systems, industrial control networks running physical plant, safety-critical systems in energy and transport, certificate authority root key infrastructure, and cryptocurrency cold storage. The shared characteristic isn't sensitivity of data alone — it's that the cost of compromise is high enough to outweigh the considerable inconvenience of having no internet. ### **Does CMMC Level 2 require MFA for remote access?** CMMC Level 2 incorporates the 110 controls of NIST SP 800-171, which include requirements for multi-factor authentication on privileged accounts and for network access. The precise applicability depends on your system boundary and how remote access is defined in your system security plan, so this is a question for your assessor or C3PAO rather than a blog post. As a practical matter, MFA on remote access is expected, and a self-hosted deployment can satisfy it entirely with internal factors. ### **Can you self-assess CMMC Level 2?** Some contracts permit Level 2 self-assessment while others require certification by a third-party assessor, and which applies depends on the contract and the sensitivity of the controlled unclassified information involved. Both routes require the same 110 controls to be implemented and documented — the difference is who verifies it. Check the specific contract requirement rather than assuming. ### **Can you run ZTNA without any cloud connectivity?** Yes, provided the policy engine, certificate authority, policy store, and logs all run inside your boundary. The Zero Trust architecture described in NIST SP 800-207 says nothing about where its components run — cloud delivery is a commercial choice rather than an architectural requirement. What you need is a platform that operates with no external runtime dependency, plus internal answers to certificate revocation, MFA enrollment, and time synchronization. [![openvpn\_ztna-research-report\_email\_800x200](https://blog.openvpn.net/hs-fs/hubfs/openvpn_ztna-research-report_email_800x200.png?width=2500&height=625&name=openvpn_ztna-research-report_email_800x200.png)](https://go.openvpn.net/ztna-research-report-2026) [Heather Walters](https://blog.openvpn.net/author/heather-walters) Heather is a writer for OpenVPN. ## Related posts from OpenVPN ### Subscribe for Blog Updates ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Heather Walters", "url" : "https://blog.openvpn.net/author/heather-walters" }, "dateModified" : "2026-10-12T16:15:00.935Z", "datePublished" : "2026-10-12T16:15:00.000Z", "headline" : "ZTNA for Air-Gapped and Isolated Networks | OpenVPN Blog", "image" : [ "https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_1_V1.png" ], "mainEntityOfPage" : { "@id" : "https://blog.openvpn.net/ztna-air-gapped-isolated-networks", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.openvpn.net/hubfs/Dark=True%20Medium.png" }, "name" : "OpenVPN" } } ```