What can reach your control layer?

Every data path across the OT/IT boundary has a direction of initiation. That one property decides which way its mistakes fall.

The shape of the failure

Start with the mechanics, because the mechanics are duller and more useful than the story. A programmable controller, or the engineering-access port on one, is reachable inbound from the public internet. Someone leases a virtual machine from an ordinary hosting provider and runs the manufacturer's own programming software: the same package the plant's own integrator has on a laptop. It connects. The endpoint answers, because answering is what a programming port does.

Notice what is absent. No exploit, no zero-day, no chained vulnerability. The firewall forwarded what it was configured to forward, and the controller accepted a session on the port it exists to accept sessions on. Every component worked to specification and the outcome was still wrong — so the defect is in the arrangement, and arrangements are not patched, they are redesigned. The path was simply there: an inbound route into the control layer nobody had decided to have.

The dated context: joint advisory AA26-097A, published 2026-04-07 and updated 2026-07-22 by seven US federal agencies. The update widened the manufacturer scope beyond the single brand the original centred on, and among the sectors named are water systems and energy. The rest of this is architecture.

What an inbound listener commits you to

Any inbound listener at the OT/IT boundary — a forwarded port, a NAT entry, a remote-access appliance holding a public address — is not really a decision. It is a standing assertion that one configuration stays correct for a twenty- to thirty-year asset life.

Consider what has to stay true. The rule has to survive every later firewall change, including the ones made at two in the morning to restore an unrelated service. The intent has to survive documentation drift — the point at which nobody left can explain why the rule exists, so nobody is confident enough to remove it. That is difficult not because the engineering is hard, but because it is a permanent obligation carried by an organisation with finite memory.

These paths exist for a reason, which is why “don't do that” has been the advice for two decades and the paths are still there. An argument that does not replace the need will not remove the path.

Restating the question so it can be answered

“Are we exposed?” is not answerable, so it does not get answered. Four that are:

1. 01Which hosts inside our OT zones accept connections that originate outside those zones?
2. 02For each one: who may initiate, how is the initiator authenticated, and what can it do once connected?
3. 03Which of those paths exists because someone designed it — and which because someone needed something to work on a Friday?
4. 04If a fifth one appeared tomorrow, what would surface it?

One and three are inventory problems; no architecture substitutes for doing them. Two and four are design problems — where the direction of initiation starts to matter.

Which way the mistake falls

The property worth designing for has nothing to do with how either arrangement behaves under attack. It is what happens when someone gets the configuration wrong — which, across enough years and enough sites, someone does.

An inbound listener that is wrongly reachable produces no symptom. The plant runs, the screens update, the historian fills. A rule scoped to any/any instead of one management subnet still passes the traffic you wanted, so nothing breaks, no alarm fires, and the ticket closes. The mistake is invisible precisely because the thing you were trying to make work now works, and because the difference is visible only from outside. A misconfigured inbound path fails open, and it fails quietly, and it can hold that state for as long as nobody happens to look.

Make the equivalent mistake on an outbound-only path and the connection simply does not establish. The wrong endpoint, the wrong certificate, an egress rule that does not match — and data stops arriving upstream, the buffer on the plant side fills, someone notices a gap in a trend that used to be continuous, and the reason is in a log with a timestamp. The failure is closed, it is loud, and it announces itself through a channel people already watch.

Same engineer, same Friday, same pressure; opposite default outcome. The asymmetry has nothing to do with how good anyone's firewall is. It is a property of which side holds the listening socket, and the side that listens is the side whose mistakes are silent. So the question worth asking of an architecture is not which is tighter the day it is commissioned, but which degrades gracefully as staff, priorities and memory turn over.

Not a stronger door — the absence of the door

In an outbound-only data path the plant-side process initiates the transport connection outward, and the stateful firewall permits the return traffic as part of that flow. The enterprise side holds the listening socket; the plant side holds none — not a hardened one, not a filtered one, not one behind an allow-list. None. The pattern is ordinary: an MQTT publisher dials its broker, and OPC UA has a reverse-connect arrangement in which the plant side initiates the transport connection. Store-and-forward buffering at the sending end keeps the path one-directional without costing you readings while the far end is unreachable.

The distinction worth holding onto is that this is not a stronger door. It is the absence of the door. A hardened inbound path is still an inbound path: a rule, an address, a scope, and therefore a configuration that can be wrong and has to be actively maintained. An outbound-only path removes the object that could be misconfigured — no inbound rule to widen by accident, because there is no inbound rule; no port-forward left behind after commissioning. That is a claim about what exists, not about how well anything is defended.

What the property does not buy you

An argument that lists only what it wins is a sales argument. Here is the boundary of the claim.

It is a boundary property, not an interior one. The controller still listens on its programming port to everything on its own segment. Anyone already inside sees exactly the listener they always saw.

It is one path, not all paths. Cellular modems on skids, vendor support appliances, a historian with its own published endpoint — each a separate inbound decision, on a separate day. Enumerating them is the hard part.

Direction of initiation is not direction of data. Once a session exists, bytes move both ways. Outbound-only describes who dialled; whether what runs over that session permits writes back into the control layer is a separate decision.

It relocates the trust decision rather than removing it. You stop asking who may reach in and start asking where this dials, and how it establishes the peer is who it claims — certificate issuance, enrolment, rotation, revocation. An unbounded egress allowance is its own standing configuration.

It is not detection. It removes a category of mistake. It does not tell you anything happened, and it does not log unless logging was built.

The door was doing something. Work that genuinely requires reaching in — a vendor performing a live download — still needs a deliberate, separately governed path. Outbound-only makes that need explicit and exceptional rather than standing.

None of it is a rating or a certification; IEC 62443 zones-and-conduits thinking is a design intent, not an assessment result.

Two sectors, one question, opposite reasons

Water systems and energy are named together, and the question bites in both for close to inverse reasons.

In water and wastewater the difficulty is geography and staffing. Lift stations, wells and chlorination sites are spread across a service area, connected over two decades with whatever reached them at the time. A small utility may have no dedicated OT security role: the person who would answer “what can reach the control layer” is also the person on call tonight. There, a path with no inbound listener has concrete value — its exposure inventory is a sentence rather than a spreadsheet, and it stays a sentence after the next three staff changes.

Power generation is the opposite shape of problem. Segmentation is formalised and the boundary documented, and the question arrives as an audit artifact: somebody has to produce the list of externally reachable connectivity and defend every entry. The work is not finding the paths but justifying them, and shrinking the number to justify again next cycle. A telemetry path with no inbound rule is short to describe and cheap to re-verify.

Questions to ask any vendor, including us

Direction of initiation is verifiable. It shows up in a firewall ruleset and in a packet capture, so ask for it in those terms.

1. 01On the OT side of this path, does anything listen? Which process, on which host, on which port?
2. 02Which side initiates — and does that ever invert? During failover, commissioning, remote support, upgrade?
3. 03Show us the firewall rules the deployment requires: direction, source, destination, port. Before purchase, not during commissioning.
4. 04Is the path read-only? If it can write, how is that separately enabled, scoped, approved and logged?
5. 05How is the far endpoint authenticated, and what happens on a certificate mismatch — fail closed, or warn and continue?
6. 06What identity does the path carry, does it bind to our directory, and what is recorded?
7. 07Where does that record live, and can we export it into our own tooling?
8. 08If the path is unavailable for six hours, what happens to the data — and to the plant?

Answers to the first two should take one sentence each. If they take a paragraph, the paragraph is the finding.

Where we sit

Flowgate is one place this arrangement is already built. Relay nodes inside the plant initiate the connection outward to the node above them, so the OT side of that path carries no inbound rule; data is buffered at the sending end; sign-in binds to Active Directory; and changes land in a timestamped, hash-chained record. That describes how it is put together, not what it withstands — and the eight questions above are the ones we would want asked of us.

The question is not answered by a purchase, but by an inventory, and then a decision, path by path, about which direction each remaining one initiates.

A note on sources.This piece describes AA26-097A at a summary level, from public reporting on it, and does not quote it. The advisory is the authority on its own contents and is worth reading directly, ahead of anyone's summary — including this one.