Your plant network is flat, and the drawing says otherwise

There is a drawing. There is always a drawing. It is usually a PDF exported from Visio, it is usually two to four years old, and it shows the enterprise network at the top, a firewall in the middle, and the plant network underneath, tidily separated. Everyone in the room believes it, including the people who would have had to make it true.

We have not yet assessed a site where it was accurate. That is not a claim about anyone's competence; it is a claim about how plant networks are built, which is incrementally, under time pressure, by several parties who do not talk to each other, over a period longer than most people's tenure. The drawing records what somebody meant. The switch records what happened.

The four places the drawing is usually wrong¶

The first is the VLAN that is not a boundary. Two VLANs on the drawing look like two networks, and they are two broadcast domains, which is a different and much weaker claim. If a layer 3 device routes between them and the rule permitting it is any/any, or is scoped to a subnet that has since grown, then what you have is one network drawn as two. This is the single most common finding, and it is invisible from the diagram by construction, because the diagram's whole vocabulary is boxes and lines rather than rules.

The second is the dual-homed machine. An engineering workstation, a historian, a SCADA server, or a quality PC with two network adapters, one on each side, bridging the boundary the firewall is enforcing. It is nearly always there for a good reason, and the reason is nearly always a reporting requirement that nobody wanted to route properly. On the drawing it appears once, on one side.

The third is remote access, and it is the one that matters most. Somewhere on the plant network there is a path in from outside, and it was almost certainly established by an integrator or an OEM during a commissioning weekend, using whatever tool that vendor uses, with credentials shared among that vendor's engineers, and it was never removed because removing it means the vendor cannot help you at two in the morning. It is not on the drawing. It is frequently not known to the IT function at all. When we ask how many vendors have standing remote access to production, the median first answer is wrong by a factor of two or more.

The fourth is time. The drawing was accurate on the day a line was commissioned. Since then a cell was added, a vendor swapped a panel, a temporary link was run for a trial and stayed, and a switch was replaced by whoever had one in the van. Nobody updated the PDF, because updating the PDF is nobody's job.

Why the IT playbook does not transfer¶

The instinct on finding those four is to apply what works on the corporate estate: patch aggressively, deploy agents everywhere, enforce authentication, scan continuously. NIST's guide to operational technology security (opens in a new tab) exists in large part because that instinct is wrong, and it is worth being concrete about why rather than repeating that OT is different.

You cannot patch on your own schedule. The controller's firmware is validated by the OEM against the machine, and applying an update outside that validation can void support on an asset worth more than the security program. The window in which you can take the line down may be two shutdowns a year.

You frequently cannot install anything. A twelve-year-old PLC has no agent, will never have one, and in many cases will fall over if you scan it hard enough. Active scanning has knocked production offline more than once, which is why passive collection is the default in this environment rather than a preference.

And an authentication prompt is not free here. On a corporate laptop, a locked screen is an inconvenience. On an HMI, a login standing between an operator and a stop command at three in the morning is a safety consideration, and safety outranks security every time, correctly. This is why the shared HMI login is so persistent: it is not laziness, it is a rational response to a real hazard, and any control that does not account for it will be defeated within a week by people acting reasonably.

One thing the standard line about protocols gets wrong¶

Everyone who works in this area, ourselves included, has said some version of: the industrial protocols authenticate nothing, so whatever can reach the port can command the process. The second half is true and load-bearing. The first half is now only half true, and the half that is wrong changes what you should ask a vendor for.

The IANA service name and port number registry (opens in a new tab) lists a secure counterpart for several of them. Modbus at port 502 has a registered secure counterpart, mbap-s, at 802, named Modbus Application Protocol Secure. OPC UA at 4840 has opcua-tls at 4843. DNP3 at 20000 has dnp-sec at 19999. Where those rows exist, running the plaintext port is a choice, and it is a choice somebody made: usually the integrator, usually years ago, usually because the secure variant was not supported by one device in the cell and never revisited.

Where there is no such row, the honest answer is different. S7comm rides iso-tsap at 102 and BACnet sits at 47808, and neither has a registered secure sibling. For those the fix is not a different port, it is a different control: the conduit carrying them is what has to be constrained, because the protocol will not help you.

This matters commercially rather than academically. "Our protocols cannot be secured" ends a conversation, and it is the wrong sentence for over half the traffic on a typical plant. "Which of these has a registered secure variant, which of our devices support it, and what is the compensating control for the rest" is a procurement question with an answer, and it is the one to put to an integrator in writing.

What to do instead, in order¶

Measure before designing. The first deliverable is not an architecture, it is an accurate inventory and an accurate picture of what actually talks to what, which is a passive collection exercise rather than a scan. Nearly every site is surprised by the result, and the surprises are what the design has to accommodate.

Then segment, and do it before investing in detection. This is the ordering we argue for most often and the one that gets the most pushback, because monitoring is easier to buy. But a monitored flat network tells you that something is spreading, at three in the morning, while a segmented one stops it at a boundary and lets you deal with it on Monday. Segmentation is also usually the cheaper of the two, and it does not carry a subscription.

Then deal with remote access as its own project, because it is the boundary that is actually load-bearing: named accounts per vendor engineer rather than a shared one, access that is requested and expires rather than standing, and a recording of what was done. Vendors accept this more readily than most plants expect, because their larger customers have already asked.

Detection comes last, and it works far better once the first three are done, because a segmented network with a known inventory has a definition of normal that a flat one does not. We have written separately about detecting a changed controller with fuzzy hashing, including what that technique misses.

The test¶

Take the drawing to the switch. Pick the single most important boundary on it, the one between the plant and everything else, and ask what enforces it, then read that device's actual configuration rather than its label. Then ask who can reach production from outside the building today, and count the vendors.

If those two answers come back quickly and match the drawing, your plant is in better shape than most and the rest of this is not urgent. If either takes a week to establish, that week is the finding, and no product purchased before it is answered will be pointed at the right thing.