What can reach your control layer?If you don’t know the answer, an attacker might find it before you do.

01 · The failure shape

The mistake that keeps everything working

I want to start with the mechanics, because the mechanics are duller and more useful than the story. Picture a programmable controller, or the engineering-access port on one, that is reachable inbound from the public internet. Somebody leases a virtual machine from an ordinary hosting provider and runs the manufacturer’s own programming software, the same package your own integrator carries on a laptop. It connects, and the endpoint answers, because answering is what a programming port exists to do.

Notice what is missing. There was no exploit, no zero-day and no chained vulnerability. The firewall forwarded what it had been 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 sits in the arrangement itself, and an arrangement is something you redesign rather than something you patch. Inbound paths like these have been exploited before. A joint advisory from seven US federal agencies, updated as recently as this July, names water systems and energy among the sectors targeted this way, and many companies are now putting in the infrastructure to make their boundaries more resilient. What a water utility still has to move on the day it disconnects everything is in After the disconnect, and the wider advisory picture, now spanning six industries, is in PLC internet exposure: two advisories, one answer.

So what are you holding when you keep one of these open? An inbound listener might be a forwarded port, a NAT entry, or a remote-access appliance with a public address. Whichever form it takes, it is a standing assertion rather than a decision, because you are asserting that one configuration stays correct across a twenty- to thirty-year asset life. It has to survive every later firewall change, including the two in the morning ones made to restore something unrelated, and it has to survive the day nobody on staff can explain why it exists, which is the day it stops being removable.

And what do you see when it goes wrong? You see nothing at all. A rule scoped to any host instead of to one management subnet still passes the traffic you wanted, so nothing breaks, no alarm fires, and the ticket closes. The mistake stays invisible precisely because the thing you were trying to make work now works. An inbound connection can be used to change setpoints, or to read critical confidential information, and no one will know unless they look closely.

02 · Not a door

Not a stronger door, the absence of a 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 same flow. The enterprise side holds the listening socket, and the plant side holds none at all. It does not hold a hardened one, or a filtered one, or one sitting behind an allow-list, because there is nothing there listening. The pattern is perfectly ordinary, and two protocols you already run do it this way. 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 down. What those two each solve is in Cutting Through the Noise.

Now look at the same boundary the way an attacker would. An inbound path means something on the plant side is listening for connections, and anything that listens can be found, probed, and attacked through whatever vulnerabilities it carries. An outbound-only path leaves nothing on the plant side listening at all, so there is no port to scan, no login to guess at, and no exposed service whose next vulnerability becomes your emergency patch. What an attacker cannot find, they cannot exploit. It comes down to which side holds the listening socket, and the side that listens is the side that can be attacked.

I want to be clear about what kind of claim that is, so here it is with its limits attached in the same breath. It describes what exists in a configuration, and it says nothing about how well anything is defended. There is no inbound rule to widen by accident, because there is no inbound rule, and no port-forward left behind after commissioning. It is one path, not all paths, and the cellular modem on a skid, the vendor support appliance and the historian with its own published endpoint are each a separate inbound decision taken on a separate day, so enumerating all of them is still the hard part of the work. And direction of initiation is not direction of data, because once a session exists bytes move in both directions, so whether what runs over that session may write back into the control layer is a separate decision you have to take, scope and record on its own.

The door was also doing something, because work that genuinely requires reaching in, such as a vendor performing a live download, still needs a deliberate path governed separately, and an argument that does not replace the need behind a path will not remove the path. However if we change the direction of that call we can still allow that needed path while providing a secure method to do so. None of this is a rating or a certification, and when I talk about zones and conduits in the IEC 62443 sense I mean a design intent rather than an assessment result. An outbound-only path is not a stronger door, it is the absence of a door, and a door that does not exist cannot be broken into.

03 · The answer

An answer you can say out loud, and check yourself

So what does any of this actually buy you? It buys you an answer. A path with no inbound listener gives you an exposure inventory that is clearly documented. The same argument, applied at a working water plant, is in Reaching your plant data without a rip-and-replace. If your boundary is formalised and every entry gets defended on a cycle, a path with no inbound rule is short to describe and cheap to re-verify.

Getting there starts with replacing a question nobody can answer. Instead of “Are we exposed?”, ask which of your paths somebody designed deliberately and which one exists because somebody needed something to work on a Friday afternoon, and ask what would bring a new one to your attention if it appeared tomorrow. The first of those is an inventory problem, and no architecture will substitute for the work of sitting down and answering it.

Every path you decide to keep, you can then check for yourself, because direction of initiation shows up in a firewall ruleset and in a packet capture, so I would ask for it in exactly those terms. Here are three questions I would put to anyone selling you a path across the OT/IT boundary, ourselves included.

1. 01

   On the plant side of this path, does anything listen for an incoming connection, and if it does, which process is it, on which host, and on which port?

2. 02

   Which side initiates the connection, and does that direction ever invert during failover, commissioning, remote support or an upgrade?

3. 03

   Are there any open ports that are not used at all and were left after commissioning or after some equipment was decommissioned?

The answers to these questions should give you a good idea of your current exposure and allow you to plan for steps to mitigate them.

04 · How we help

How can we help?

You do not answer the exposure question with a purchase. You answer it with an inventory, and then with a decision, taken path by path, about which direction each remaining one initiates. We come in on the paths you decide to keep.

Flowgate is one place where this arrangement is already built. Relay nodes inside the plant initiate every connection outward to the node above them, over connections that are encrypted and secure, so the control side of that path carries no inbound rule and holds no listening door for anyone to find. Readings buffer at the sending end while a link is down, which turns a dropped connection into late data instead of missing data. Sign-in binds to the Active Directory you already run rather than to another shared password, so an action carries a name. And changes land in a timestamped, hash-chained record, so an entry altered after the fact is easily identifiable and can be investigated.

I want to be plain that this describes how the parts are put together, not what they withstand, and the questions above are the ones we would want asked of us. What you can put in front of your board afterwards is a boundary described by one outbound connection and a list of the paths you kept on purpose, and that is a list you can still defend the next time somebody asks.

05 · Sources

Sources

• CISA, joint cybersecurity advisory AA26-097A (published 2026-04-07, updated 2026-07-22)