From air gap to zero trust

The air gap is usually described as a physical fact: two networks, no cable between them. The description is accurate, and earlier revisions of this document went too far in dismissing it. Separation is precisely what an air gap was, and it is worth being honest about how much it bought, because the argument that follows only needs one part of it and should not pretend to restore the rest.

What it removed was the normal network path by which a remote service could be discovered, reached and administered. Several distinct protections travelled with that. There was no routable path across the boundary. There were no reachable trust relationships to abuse, no management plane an outsider could log into, no ordinary remote administration to hijack, and no internet-borne delivery route for a payload. In many real plants it also meant no externally reachable listener existed inside the OT environment at all, though a machine in an air-gapped room may well have had services listening on its local interfaces. The difference was that nothing outside could reach them.

Three things are worth keeping apart, because conflating them is what makes this conversation go wrong. Air-gapped isolation means there is no normal network path across the boundary. No directly reachable inbound service means no external route or listener is exposed into the protected environment. Zero trust means access is authenticated and authorised explicitly, per resource, with no implicit trust granted by network position. Those can coexist and they are not interchangeable, and this document is about the second one.

That is the distinction the whole argument rests on. Isolation was one way to arrive at the second property. It was never the only way, and it was always the most expensive way, because it also removed the diagnostics, the telemetry and the vendor support that the plant genuinely needed. Every organisation that later connected its OT network was, in effect, deciding that the price of the mechanism had become higher than the value of everything it delivered. That decision was often correct. What went wrong is narrower and more recoverable than the loss of the air gap in its entirety: when connectivity arrived, reachability was reintroduced through inbound remote-access services, and nobody recorded surrendering that as a decision at all.

The joint guidance of 29 April 2026 on adapting zero trust to operational technology holds both halves of this in the same document, which is why it repays a close reading rather than a summary. It notes that legacy OT already possesses foundational segmentation techniques, "including physical air gaps, dedicated virtual local area networks (VLANs), and carefully controlled access to sensitive zones, providing a useful baseline for ZT implementation", ZT being its abbreviation for zero trust. Twelve pages earlier it warns operators to "avoid procuring components or systems that assume security through air-gapping or segmented architecture alone, as modern threats can exploit the false sense of isolation these models provide". Those two statements only look contradictory if you treat the air gap as a mechanism. Read as a property, they are consistent: the property was real and worth keeping, and assuming you still have it because you once did is the error.

No plant lost its air gap in a single change. It went in increments, each one documented, justified and signed. A turbine vendor needed maintenance access under a support contract the plant could not operate without. A regulator or a corporate reporting line needed process data upstream, so a historian was given a route out and then, for reconciliation, a route back in. An integrator arrived for a commissioning window with a laptop and a deadline. A remote pumping station forty kilometres away had to be reachable at three in the morning by somebody who was not going to drive there.

The joint guidance states the resulting bind in one sentence, and it is worth quoting because it concedes both sides: "Remote access is a major weakness in OT as it represents an initial access vector into an insecure legacy network, but remote access may be necessary for operating distributed infrastructure." Necessary and dangerous, in the same breath. Nothing in that sentence can be resolved by telling an operator to be more disciplined.

The mechanism of the erosion is administrative, not technical. Each change was assessed against the question "is this access justified", which it invariably was, and never against the question "what does this leave listening when the work is finished". The first question belongs to change control and has an owner. The second belongs to architecture and, in most institutions, has none. So the plant accumulated inbound pathways the way a building accumulates keys, and the total was never anybody’s document. Ask for the list and you will usually be given a firewall ruleset, which is a record of what was permitted rather than a record of what is reachable.

Connectivity is a word without a direction in it, and that is why it takes the blame. Almost every access requirement in the previous section can be met by a connection the protected machine opens itself. Almost every one of them was instead met by a connection something outside opens to the protected machine: a forwarded port, a published address, a VPN concentrator, a listening service. The requirement was access. The implementation was exposure. They are not the same thing and the difference is directional.

The reason direction matters more than protocol is that it changes what an adversary has to do. Against an inbound service, reconnaissance is free and continuous: the port is there whether or not anyone is attacking it, and it can be found by somebody who has never heard of the plant. Against an outbound-only endpoint there is nothing to enumerate, so the adversary needs a foothold somewhere in the path before the target is even visible. That does not make the system safe. It moves the work from scanning, which is cheap and automatable, to intrusion, which is neither.

This is the sharpest available version of the claim, and it is not this practice’s invention. The joint guidance sets out the difference between IT and OT segmentation in a table, and under the row headed Directionality the OT column reads: "Primarily unidirectional–OT systems push data out, minimizing inbound connections". A federal joint publication, aligned to the NIST Cybersecurity Framework functions and to ISA/IEC 62443, states the principle plainly. What the guidance does not do, and what the rest of this document attempts, is follow it to its conclusion for the access cases that appear to require an inbound path.

Air-gap zero trust network access is the name this practice gives to the architecture that follows from the previous section, and it is a local analytical term rather than a recognised category: nobody should go looking for a product sold under it. The protected machine holds no listening service and no published address. A connector inside the protected environment establishes and maintains an authenticated outbound channel, and authorised sessions are then brokered or multiplexed through it according to the design of whatever product is doing the work. The connector-to-broker channel wants strong mutual workload authentication, commonly mutual TLS with rotated certificates or hardware-backed keys, while the human at the other end is separately authenticated through multifactor and privileged-access controls with time-bounded policy. Those are the right patterns rather than inherent properties of the arrangement, and describing them as inherent was an overstatement in earlier revisions.

The honest version of the payoff, stated before the diagram rather than after it. An adversary scanning the plant's externally reachable address space finds no directly exposed OT service, which is the part of the air gap's protection that can survive connectivity. What they do find is the broker or service edge, because the externally reachable surface has moved there rather than ceased to exist. That component must be designed, monitored and operated as a high-value control-plane component, and the trade only makes sense if it is. What the plant gets in exchange is that the thing anybody can reach is now a component it chose, placed, monitors and can replace, instead of a listener on the boundary of a plant that cannot be patched during production. The vendor still gets their maintenance window.

The distinction from mainstream zero trust network access is the part that matters, and it is where a sceptical reader should push. This section used to draw it wrongly, and the correction belongs in the open, because getting it wrong would cost the argument its credibility with exactly the readers it needs. The claim was that conventional ZTNA puts a gateway in front, so the client reaches the gateway and something on the protected side still listens. That describes a 2020-era deployment and it is not what mainstream ZTNA does now. The NCSC's own reference architectures set out the modern pattern plainly: "At the edge of each network segment, a component designed to be exposed to the public internet such as a connector, proxy or a VPN endpoint is deployed and will establish outbound (reverse) tunnels to the policy engine", which allows "access to be brokered without requiring inbound network connectivity to the application or hosting environment". Outbound initiation is not this practice's discovery. It is the reference architecture.

The honest distinction is therefore narrower than the one this document used to draw, and it is not about the direction of the first move. Both patterns remove the directly reachable listener from the protected environment, and both therefore relocate the reachable surface rather than remove it, onto a connector, policy engine or provider edge that is deliberately exposed and has to be run as a high-value control-plane component. What stays genuinely different for operational technology is where policy is enforced, which component remains publicly exposed and who operates it, how sessions are brokered and cut, and whether the arrangement tolerates the timing, safety and vendor-support constraints of a plant that cannot be rebooted to replace a certificate. Those are the questions to press. The history of the last several years is unkind on the exposed component in either design: the concentrators, gateways and edge appliances bought to reduce exposure have themselves been a recurring initial access vector, for the ordinary reason that a device which must accept connections from everywhere is reachable from everywhere. That argument survives the correction; it simply applies to the broker here too, which is the subject of the last section.

There is hardware precedent for the direction argument and it is worth being clear about its limits. The joint guidance lists data diodes among OT segmentation tools and describes them as enforcing "unidirectional communications via hardware controls". A diode is the strongest possible statement of the principle: one direction, no return path, physically. That is why it suits telemetry and historian replication and why it cannot serve a maintenance session. The argument here is narrower and more useful in brownfield: take the interactive session an operator actually needs, and carry it over a connection the protected side initiated, so that the direction of the initiation is decoupled from the direction of the work.

The honest tension with the guidance sits here rather than being tucked into a footnote. Having stated that OT should be primarily unidirectional, the same document later recommends a jump host: "Jump hosts are dedicated, hardened jump boxes within the OT demilitarized zone (DMZ) acting as the sole entry point for remote access. The authoring agencies strongly recommend a jump host for adding user authentication to legacy networks and enforcing segmentation." A jump host is a listening service. Concentrating remote access into one hardened, monitored, multifactor-protected entry point is a very large improvement on the alternative, which is per-device exposure scattered across a plant, and for an operator who cannot change their architecture this year it is the right advice. What it is not is a restoration of the property, and the guidance’s own Directionality row is the reason why. Both things are true, and a document that pretended otherwise would be less useful to the person who has to choose.

The guidance is organised on the Cybersecurity Framework functions and is careful to position zero trust as working alongside safety rather than above it. Read as an operator with equipment older than the document, three of its asks are immediately actionable, and several quietly assume a plant you do not have.

What is realistic. The asset inventory is genuinely first, genuinely foundational, and achievable in a brownfield plant if you accept passive discovery. The guidance is unusually candid about why that caveat exists, noting that active scanning "may knock a legacy device offline", so it asks for comprehensive inventory while conceding that the standard IT means of obtaining one is unsafe in the environment where it is being asked for. That is not a contradiction, it is a tooling constraint, and it is the single most useful sentence in the document for anyone building a business case: budget for OT-aware passive discovery, not for a scanner licence. Segmentation as policy rather than architecture is also realistic and underrated. The instruction to treat segmentation as "a dynamic, enforceable security policy instead of a one-time architectural decision", and to manage it out of band of the operational network, is achievable without touching a single controller.

Where it assumes a greenfield. The identity sections are the clearest case, and the guidance says so itself: "Many OT systems predate modern ICAM capabilities and often require compensating controls above the device level." Read that carefully. The identity layer cannot reach the thing being protected, so authentication happens somewhere upstream of the asset and the asset continues to trust whatever arrives. Every claim about per-asset identity in an OT environment should be read against that admission. The same pattern recurs in secure communications: the modern protocol variants exist, and the document notes they are "often disabled to allow for simpler integration or backwards compatibility", with the fallback being to wrap legacy protocols in TLS-enabled gateways so that "encryption and authentication occur outside the control devices themselves". That is the brownfield answer, and it is worth naming plainly: you are not securing the protocol, you are building a shell around a protocol that cannot be secured.

Two further asks deserve credit for realism rather than criticism. Emergency access is treated as "non-negotiable", with break-glass accounts held to limited lifespans and stringent auditing, which is a guidance document conceding that a control which can prevent an operator from reaching a plant in an emergency will be removed by the operator, correctly. And on patching it declines the usual answer: patch windows are operational, patching outside them "is discouraged unless there is an outsized risk of exploitation and impact", decisions are pushed towards a structured method such as SSVC, and where patching cannot happen promptly, "The focus should shift to isolating vulnerable systems and applying compensating controls". An OT operator has heard "just patch it" for twenty years. This document does not say it, which is the strongest signal that practitioners were in the room.

ISA/IEC 62443 gives the vocabulary this argument needs. A zone is a grouping of assets sharing a security requirement; a conduit is the permitted communication between zones; the discipline is that every flow crossing a boundary is a conduit somebody named, rather than a route that happens to work. The value of the standard in brownfield is not the target architecture, which most plants will never reach. It is that it forces the inbound pathways of the second section to be written down as objects with owners.

What is achievable without stopping production. Drawing zone boundaries on paper against the plant as it actually runs, and enumerating every flow that crosses them, requires no outage and is usually the first time the true count of inbound paths exists in one place. Establishing a boundary at the OT and IT interface, and putting historian and reporting flows through it in the outbound direction, is achievable because those flows are already one-directional in intent even where they were built two-directional in fact. Retiring conduits nobody can name is achievable and is the cheapest security work available in an OT estate: the pathway opened for a commissioning contract that ended in 2019 is still there, and closing it costs a change window rather than a capital programme.

What is not achievable, and should not be promised. Microsegmentation down to the individual controller on a flat, unauthenticated fieldbus, without an outage, is not a brownfield project. The protocols carry no identity, the devices cannot enforce policy, and the enforcement point therefore has to sit above the device, which is the compensating-control admission from the previous section restated as an architectural limit. Anybody selling per-device zero trust into a plant of that vintage is selling an enforcement point in front of the plant and describing it as an enforcement point inside it. The honest brownfield position is a small number of well-defended zones with a fully enumerated and mostly outbound set of conduits, achieved this year, in preference to a microsegmentation roadmap that is still a diagram in three years.

The sequence matters more than any individual item in it, because the common failure is not omission but ordering: segmentation designed before the inventory exists, and microsegmentation scoped before anyone has counted the doors that open inward.

Days one to thirty, find out what you have. Passive asset discovery, on the explicit understanding that active scanning can take a legacy device down. In parallel, and this is the part usually skipped, enumerate every inbound pathway: every forwarded port, every vendor tunnel, every dial-in, every VPN account, every remote-access tool installed for a project. Produce one list with a named owner and a live business justification against each entry. The firewall ruleset is not this list. It records what was permitted, not what is currently reachable, and the gap between the two is the finding.

Days thirty-one to sixty, close and consolidate. Every pathway on the list without a current owner and a current justification is retired, and that will typically be a meaningful fraction of the total. Whatever survives is converted, in preference order: to outbound-initiated access where the vendor and the equipment allow it; failing that, into a single hardened, monitored, multifactor entry point rather than several unmonitored ones. Write down which pathways could not be converted and why, because that document is the honest description of your remaining exposure and it is what a regulator or an insurer will actually ask for.

Days sixty-one to ninety, make it hold. Zone boundaries on paper against the plant as it runs, conduits named, and the segmentation policy managed out of band so that changes to it are visible. Monitoring concentrated at the boundaries, since the guidance is candid that OT environments "often lack robust logging, monitoring, and detection capabilities" and boundary visibility is what you can actually get. Break-glass access defined, time-limited and audited, before somebody needs it at three in the morning. Then rehearse the case where the pathway you rely on is the pathway that is compromised, because that is the scenario the architecture is for.

Removing the listening surface removes one class of attack: the one that begins with an adversary finding you. It does nothing about the classes that begin elsewhere, and a document that stopped before saying so would be advocacy rather than doctrine.

It does not address the insider, or the engineer with entirely legitimate credentials and poor judgement, because an architecture built on authenticated identity does exactly what an authenticated identity asks of it. It does not address the supply chain: firmware, an integrator’s laptop, a vendor’s update channel, or a compromise inside the software that establishes the outbound session itself. It does not address removable media, which is why the joint guidance devotes attention to media protection precisely because isolated plants attract USB as the transfer mechanism of last resort. It does not address availability and safety, which outrank it: any control capable of preventing an operator from reaching a plant during an incident will be bypassed in that incident, and should be.

There is one limit specific to this architecture and it belongs in the open. If the protected machine reaches outward to a broker, then the broker, its operator and its software supply chain are in the trust path. The exposure has not been eliminated, it has been relocated, from an appliance on the plant boundary that anybody can scan to a component you can choose, place, monitor and, if necessary, replace. That is a considerably better trade than the one most plants have today, and it is a trade rather than a solution. Whoever operates that component should expect to be asked how it is built, where it runs, and what happens when it fails. Those are fair questions and this practice’s answer to them is a legitimate part of the assessment.

Two controls follow from that admission and were missing from earlier revisions, which is an omission rather than a matter of emphasis: without them the architecture solves the old problem and creates a new one. The first is egress governance. Outbound-only is safe only where egress is constrained: destinations permitted by identity or name rather than left open, authenticated proxying, restricted name resolution, alerting on destinations never seen before, a standing prohibition on arbitrary tunnels, and certificate rotation and revocation defined before they are needed. A protected machine permitted to open any outbound connection it likes has been given a durable command-and-control and data-exfiltration path, engineered and signed off. The direction argument cuts both ways, and this is the edge that points inward.

The second is a stated failure and compromise model for the broker. Whoever specifies this architecture should be able to say, before it is built, whether the broker is vendor-operated, customer-operated, single-tenant or shared; what fails open and what fails closed; which route is the safety-approved break-glass when the broker is the thing that is broken; how a session is cut mid-flight; which logs are retained and where they are held; how a connector identity is revoked; and how the plant keeps running safely when name resolution, internet transit, the broker or the identity provider is unavailable. The NCSC makes the same point for ordinary zero trust deployments, emphasising centralised logging and tightly governed, tested break-glass mechanisms. In operational technology it is not a refinement. A plant whose remote access depends on a component it does not operate has acquired a new single point of failure, and the only acceptable version of that is one where somebody has written down what happens when it fails and has rehearsed it at three in the morning.

Mohd Atasha, From air gap to zero trust, version 1.1, first published 2025-10-07, revised 2026-07-27. Available at mohdatasha.com/doctrine/air-gap-to-zero-trust/