One firewall rule is usually all a plant data project asks for: TCP 1433 outbound, from a gateway at 192.168.1.40 on the cell network to a SQL Server at 10.20.4.16 on the business network. That rule gets refused, and the refusal is right.
What gets approved instead is a broker sitting in a demilitarised zone between the two networks, two separate sessions rather than one connection, and a gateway that queues on disk while the path is down. The argument for that shape is the whole of this page, together with the four questions an IT security team will ask and the numbers that answer them.
None of those questions is unreasonable. All four have numeric answers, and you can have them before you walk in.
Both arrows stop at the broker. Neither of them runs from 192.168.1.0/24 to 10.20.0.0/16 in one hop, which is the property the whole design exists to have.
What the refusal is actually about
The objection is not to the port. It is to what a single connection means once it exists.
A rule permitting 192.168.1.40 to open a TCP session to 10.20.4.16 is also a rule permitting anything that gets code execution on 192.168.1.40 to open a TCP session to 10.20.4.16, and the gateway on that address sits on the same VLAN as an L83E, four PowerFlex 525s and a remote 1734 rack. Rockwell and Cisco write the policy out plainly in ENET-TD009C-EN-P: eliminate direct traffic between the Enterprise and Industrial Zones, and do not create rules that allow IACS protocols through the Industrial Zone interface, naming CIP as the example. NIST SP 800-82r3 says the same thing from the other side, and adds the part that catches most people out: organisations should consider making outbound rules as stringent as inbound rules, because an unmanaged outbound path out of a control network is a significant risk in itself. That is the sentence to read twice. “It is only outbound” is the argument every controls engineer reaches for first and it is not enough on its own, because a session opened outbound still carries bytes in both directions once it is up. What makes the outbound path defensible is not its direction but what is at the other end of it: a host that holds nothing, knows nothing about the controller, and can be switched off without stopping a machine.
So the design is not a better firewall rule. It is a different topology.
The shape that gets approved
A buffer network between the two zones, with brokers in it, and no traffic that crosses it end to end.
ENET-TD009C-EN-P calls it the Industrial Demilitarized Zone and gives it five properties worth memorising, because they are the properties you will be asked to demonstrate. All IACS network traffic from either side terminates in the IDMZ; no traffic traverses it. EtherNet/IP stays in the Industrial Zone and does not enter the IDMZ at all. All data in the IDMZ is transient, and primary services are not permanently stored there. Functional sub-zones inside it separate IT, operations and any trusted partner. And the last one, which is the test that decides whether the design is real: a properly designed IDMZ can be unplugged if it is compromised while the Industrial Zone carries on operating.
That last property is the one to design for first, because everything else follows from it.
If the plant stops when the broker stops, the broker is part of the machine and you have built a dependency rather than a data layer. If the plant does not notice, then the path between zones is a firewall rule somebody in IT wrote, owns, logs and can turn off, which is a completely different conversation from the one that starts when an auditor finds a controls PC with two addresses on it. The practical shape for plant data is an MQTT broker in the middle. The gateway on the cell side opens a session outward to the broker on 8883 and publishes; the historian on the enterprise side opens a session outward to the same broker on 8883 and subscribes. Two sessions, both opened from the inside of their own zone, and nothing that starts on 10.20.0.0/16 ever reaches an address on 192.168.1.0/24. The topics and the payload shape are the same ones the MQTT and Sparkplug gateway article works through, and the broker being in the IDMZ rather than in the cell is the only difference that matters here.
Write the last row yourself before anyone asks for it. A table that names the rule you are not requesting is read very differently from one that only lists what you want.
Which direction the connection opens
Outbound from the plant, always, and the reason is what happens when the far end is wrong.
An inbound rule means a host on the business network initiates. That host is patched by somebody else, joined to a domain you do not control, and reachable by every laptop in the building. An outbound rule means the plant initiates and the far end can only answer on a session the plant already opened, so a compromised enterprise server has nothing to knock on. The stronger version of this is the data diode, which NIST SP 800-82r3 calls a unidirectional gateway and defines by what its hardware cannot do: it cannot be programmed to allow data to flow in both directions, because the hardware is incapable of it. The glossary entry is worth quoting to anybody who thinks a diode is just a strict firewall — hardware that permits data to flow from one network to another but is physically unable to send any information at all back to the source network, paired with software that replicates databases and emulates protocol servers on the far side.
The cost of that absolute guarantee is TCP.
There is no acknowledgement, so the sending side never learns whether a byte arrived, and the replication software on both ends exists precisely to fake a protocol across a link that cannot carry one. That rules out MQTT with QoS 1, it rules out a SQL client, and it rules out any design where the plant is told the data landed. For a site where a regulator or an insurer is asking the question, that is a price worth paying. For a packing line that wants its counts in a report, it is not, and a broker in an IDMZ gets you most of the isolation for none of the operational pain.
The row that decides it is the second one. Everything else on the table is a cost comparison; that row is the difference between a path somebody can walk and a path that terminates.
The four questions, and the numbers that answer them
What talks to what, and in which direction. This is the connection table in the second figure and it should exist on paper before the meeting. Five rows, each with a source address, a destination address, a port, a direction and a named owner. The fifth row is the one to write yourself: the rule you are not asking for, CIP on 44818 inbound to a controller, marked refused. ENET-TD009C-EN-P builds its entire design methodology out of the reconnaissance and requirements phases, which are nothing more than interviewing every asset owner about what their system needs to do and writing it down. Arriving with that already done changes the meeting completely.
What happens when we patch it. NIST’s OT guidance is explicit that DMZ components should be prioritised for patching, which means the broker will be rebooted on somebody else’s schedule and not yours. The answer is that the gateway queues. A SQLite file on the gateway holding 1200 tags at one second per tag, at the 47 bytes a row that a typed indexed table measured on a Pi, is 4.9 GB after 24 hours and fills a 32 GB partition in 158 hours. A ten-minute patch window is not visible in that arithmetic. The SQLite queue and backfill article is the implementation, including the rule that matters most here: delete nothing the far end has not acknowledged.
Who owns the credentials. The broker account belongs to IT, in whatever identity store the rest of the site uses, with its own certificate. Controls owns no credential on the enterprise network at all, and that is the point. The answer that loses the room is a shared service account whose password is in a text file on the engineering workstation, because it makes every future question about the plant network into a question about that file.
How long can it stay down. ENET-TD009C-EN-P puts this fourth in its own list of design questions and phrases it as how long the Enterprise systems can stay disconnected from the Industrial Zone before connectivity is restored. Answer it as two numbers. Production: indefinitely, because nothing upstream is in any interlock. History: 158 hours, then the oldest rows start to go.
Halve the tag count or halve the rate and the answer doubles. This is the only one of the four questions where the honest answer is a design decision rather than a fact.
What this costs you, honestly
A host somebody has to own, patch and monitor, and a second hop in every data path.
That is a real cost and it is worth saying out loud rather than pretending the broker is free. It also buys something the direct rule cannot: the ability to change the historian, add a second subscriber, or move the enterprise database to a different address without touching anything on the cell network or asking for a new firewall rule. Segmenting the industrial side properly underneath it is the other half of the job, and the VLANs and ring topology article covers what that looks like below the IDMZ. If the data crossing is OPC UA rather than MQTT, the same argument holds with a UA aggregating server as the broker instead, and the OPC UA tag to client path is the shape of what terminates on each side.
The third column is the useful one. Each of those failure modes is an answer somebody has actually given, and each of them ends the meeting badly.
Next step
Draw your own version of the five-row table, with real addresses, before you ask for anything. Then measure the two numbers in it: count the tags you intend to send, multiply by the rate and by the bytes a row costs on your own gateway, and work out how many hours of buffer the disk you have actually gives you. If that number is under a working week, fix it before the meeting rather than during it, because “how long can it stay down” is the question where a vague answer does the most damage. Then unplug the uplink on a Friday afternoon and see whether anything on the line notices; if something does, you have found the dependency that would have been discovered by an auditor instead.