Air-Gapped Remote Access: What It Actually Means and How to Achieve It

Air-gapped remote access sounds like a contradiction. An air gap is a physical separation between a network and the outside world: no cables, no wireless, no logical connection of any kind. Remote access is a connection. Put the two terms together and something has to give.

In practice, most organizations resolve this contradiction with software. They add a VPN with strict access control lists. They deploy a jump server. They implement a software-defined perimeter with micro-segmentation. And they describe the result as "air-gapped" remote access.

It is not. What they have built is a network with software controls: controls that can be misconfigured, exploited, or bypassed. The air gap is gone. A network path now exists between the remote user and the protected environment. The question is only whether that path is well-defended.

True air-gapped remote access means the remote session does not create a network path into the protected environment. Not a well-controlled path. Not an encrypted path. No path.

What is air-gapped remote access?

Air-gapped remote access is a remote access architecture in which the remote user can see and interact with a system in an isolated environment without any network packets crossing the boundary between the two environments. The remote operator receives a video stream of pixels from the remote system and sends mouse and keyboard input back. No data, no files, no network frames, and no IP packets travel in either direction. The air gap remains physically intact.

This is distinct from encrypted remote access, zero-trust remote access, or any software-defined access model. Those approaches control what travels across a network connection. Air-gapped remote access removes the network connection entirely. The isolation is enforced at the hardware layer: not by policy, not by configuration, and not by software that can be patched, exploited, or misconfigured.

Why software cannot enforce an air gap

Software runs on hardware. Hardware has network interfaces. Network interfaces can be reached.

A software-defined air gap is a policy that says: do not use this network interface in this way. Policies can be changed. Vulnerabilities in the software stack can expose the network interface to unintended use. An attacker who gains access to the software layer can modify the policy or bypass it entirely.

This is not a theoretical concern. A widely deployed remote access gateway was found to allow unauthenticated remote code execution on a product whose entire purpose was to control what crosses a network boundary. CISA Advisory AA26-097a documents how attackers exploited internet-connected PLCs at critical infrastructure facilities by targeting exactly this kind of software boundary. VPN vulnerabilities documented across 2024 and 2025 gave attackers persistence inside the remote access tool itself: the device designed to protect the boundary became the entry point.

A software-based remote access tool that claims to replicate air-gap isolation is making a claim about its own resilience. When that resilience is tested by a zero-day, a misconfiguration, or a supply chain compromise, the claim fails and the network behind it is exposed.

Hardware enforcement is different. The physical architecture of the device determines what can cross the boundary. There is no software patch that grants a pixel stream a new capability. There is no configuration that turns a mouse and keyboard channel into a data exfiltration path. The boundary is defined by the physics of the hardware, not by the correctness of the software.

Who actually needs true air-gapped remote access

Not every organization needs a true hardware air gap. Many organizations are well-served by zero-trust architectures, privileged access workstations, and well-configured VPNs with MFA. Those are appropriate controls for environments where a network connection to remote users is acceptable.

True air-gapped remote access is required in environments where a network connection is not acceptable under any circumstances:

Defense and classified environments. Systems handling classified data or critical military infrastructure require physical isolation. Remote maintenance and monitoring must happen without creating a network path between the classified environment and the outside world. Software-defined isolation does not meet this requirement.

Critical national infrastructure. Power generation, water treatment, gas distribution, and nuclear facilities operate systems where a successful intrusion can cause physical damage or loss of life. Regulatory frameworks including NIS2, NERC CIP, and IEC 62443 reflect this. NIS2 Article 21's implementing regulation requires physical or cryptographic channel isolation for remote access to critical infrastructure.

Industrial OT environments with legacy systems. PLCs, RTUs, and SCADA systems running legacy protocols cannot be patched on the same cycle as enterprise IT. They were designed for isolated environments. When remote access is required, the isolation architecture must protect systems that cannot protect themselves.

Financial infrastructure requiring physical separation. Core banking systems and trading infrastructure at tier-one financial institutions often operate on physically separated networks. Vendor access and remote monitoring require a mechanism that does not create a logical connection between those networks and the internet.

How hardware-enforced architecture maintains the isolation

The Zeroport Fantom Edge deploys at the OT perimeter for edge and distributed environments. The Zeroport Fantom Enterprise handles large-scale, centralized deployments. Both sit at the boundary of the protected environment. On one side is the isolated network: the OT system, the classified environment, the critical infrastructure. On the other side is the remote access channel.

The appliance captures the video output of the remote system and transmits a pixel stream to the remote operator. The remote operator's mouse and keyboard inputs are transmitted back. That is the complete extent of what crosses the boundary.

There is no IP address in the protected environment reachable from the outside. There is no network session between the remote user and the OT system. There is no software process on the appliance that can be exploited to extend the channel beyond its design parameters. The isolation is enforced by the hardware architecture of the device: by what the device is physically capable of transmitting, not by what it is configured to transmit.

The result is remote access that maintains the air gap. An operator can monitor a SCADA screen, interact with an engineering workstation, or support a vendor session without creating the network path that attackers look for and exploit.

For environments where the consequences of a breach reach beyond data loss into physical disruption or harm, this is not a nice-to-have. It is the only architecture that delivers what the term "air-gapped" actually means.

Book a Demo to see how Zeroport Fantom delivers hardware-enforced air-gapped remote access

‍