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 it explains almost nothing, because it names the mechanism and not the property the mechanism delivered. The property was that nothing inside was listening. A scan from outside returned no open port because there was no outside from which to scan. An adversary holding a working exploit for the exact controller in the exact room still had no path along which to deliver it.

That distinction is not pedantry, it is the whole argument. Isolation was one way to arrive at the 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 the property. That decision was often correct. What went wrong is that the property was surrendered along with the mechanism, and nobody recorded that as a decision at all.

The April 2026 joint guidance 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. The protected machine holds no listening service and no published address. It opens an authenticated outbound session and every subsequent flow, including sessions that logically run towards it, is carried inside connections it established. Identity is mutual and certificate-based at both ends, so authorisation is a property of the peer rather than of the source address. An adversary scanning the address space of the plant finds nothing, which is precisely what the air gap delivered, and 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. Conventional ZTNA also removes the exposure of the application, and it does so by putting a gateway in front: the client reaches the gateway, the gateway authenticates and brokers the session. That is a real improvement over publishing the application. It does not restore the property, because the gateway itself listens. It has an address, it accepts connections from anyone who can route to it, and it is therefore a thing to enumerate, fingerprint and exploit. The history of the last several years is unkind on this point: 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.

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.

Mohd Atasha, From air gap to zero trust, version 1.0, revised 2026-08-08. Available at mohdatasha.com/doctrine/air-gap-to-zero-trust/