Every security story about OT these days starts with Zero Trust. And rightly so. The principle is sound: trust nothing implicitly, verify where possible, restrict access, and minimize the blast radius.
But try explaining that to a Siemens S7-300 from 2008.
That PLC has no TLS stack. No certificate store. No modern authentication. It speaks Profinet, MPI, or maybe Modbus/TCP. It has been doing exactly what it needs to do for fifteen years. The line runs on it. The operators know its behavior. The maintenance technician knows which indicator lights are normal. And somewhere there is still an engineering laptop running software that nobody likes reinstalling.
You are not simply going to replace that PLC. Not because security doesn’t matter. But because the line would be down for weeks, the vendor may no longer exist, the documentation is incomplete, and nobody knows exactly what happens inside that program.
That is the reality of OT security. Not the whitepaper version. The factory floor version.
The problem with “just segment it”
Segmentation is often presented as if it is a matter of creating VLANs and writing firewall rules. In IT, you can sometimes get away with that. Endpoints speak TCP/IP, support TLS, authenticate against an identity provider, and can be patched relatively easily.
In OT you are in a different universe. Devices that do not support modern security. Protocols without authentication. Firmware that cannot be patched. Serial connections that suddenly appear on the network through converters. Engineering workstations that need to reach both corporate IT and the process network. Vendors who want remote access via TeamViewer on a shared laptop.
Segmentation in OT is therefore not a network question. It is a design question. You need to know not just which systems talk to each other — you need to understand why they do, and what physically happens if you interrupt that communication.
Zones and conduits: IEC 62443 in practice
IEC 62443 provides the right framework for this: zones and conduits. A zone is a group of assets with a comparable risk profile and the same function. A conduit is the controlled connection between zones.
In practice: a group of PLCs that together control one production line form a zone. The SCADA server that reads them sits in a different zone. The communication path between them is the conduit — and that is precisely where you enforce control.
The key point: you do not need to modernize the PLC itself. An old PLC cannot speak TLS, but the network segment around it can absolutely be bounded, monitored, and controlled. In OT, the defense is not inside the device. The defense is around it.
What you do at the boundary
Protocol-aware firewalls. Not a standard enterprise firewall that only sees ports. Because allowing TCP port 502 is not the same as allowing safe Modbus traffic. A Modbus read is different from a Modbus write. Reading data is different from forcing a coil.
A good OT firewall understands that distinction. SCADA may read registers. Engineering may write, but only from a controlled workstation. Vendors only enter through a jump host. Maintenance access is temporary, logged, and traceable.
Unidirectional gateways. If a zone only needs to deliver data — process data to a historian or cloud platform — there is no reason for bidirectional communication. A data diode is not a firewall rule. It is a physical constraint. Data can go out; traffic cannot come back. You do not need to teach the PLC to trust certificates. You simply ensure that no return path exists.
Not everything needs to become smarter. Sometimes the architecture just needs to become stricter.
Monitoring on the conduit. Not everything can be blocked — in OT, a wrong firewall rule can halt production. But if you cannot encrypt traffic, you can inspect it. Deep packet inspection on OT protocols reveals which commands traverse the wire.
A PLC that has not been modified in three years and suddenly receives a firmware upload deserves attention. An engineering workstation writing to controllers outside of maintenance windows deserves attention. An unknown device communicating with a production line deserves attention.
In OT, security is not only about blocking. It is about understanding normal behavior and recognizing deviations.
The Purdue model as a starting point
In practice, the Purdue model is still useful — not as dogma, but as a conversation framework. At the bottom: physical processes and controllers. Above that: SCADA and HMI. Above that: site operations with historians, MES, and engineering workstations. Between OT and IT: a real DMZ with jump servers, patch proxies, and data export.
But the biggest gains often do not come from the IT/OT boundary. That one usually gets attention. The forgotten boundaries are lower: between production cells, between the process network and the safety network, between an old serial world and a new IP network.
Those are precisely the risks nobody sees anymore, because the network was once built flat and has kept running ever since. Until it doesn’t.
NIS2 makes complacency harder
With NIS2, OT security becomes less optional. For sectors such as energy, water, food production, manufacturing, and other vital or important processes, it is increasingly necessary to demonstrate proportionate and appropriate measures. “We have a firewall between IT and OT” is no longer enough.
You must be able to explain which assets you have, how your OT environment is structured, which communication flows are necessary, how remote access is managed, and how incidents are detected.
IEC 62443 helps with that. Not because it solves everything, but because it provides a language suited to industrial environments. If you can explain segmentation in terms of zones, conduits, and control measures, you have a story that is technically sound and manageable at the executive level.
Where to start
The temptation is to start with technology. Selecting firewalls, drawing VLANs, comparing monitoring tools.
Don’t start there.
Start with an asset inventory. Not what the documentation says — what is actually there. Which PLCs, switches, converters, engineering laptops, vendor systems, and legacy connections actually exist?
Then map the communication. Which device talks to which device, over which protocol, in which direction, and why? That “why” is crucial. If nobody can explain why two systems are communicating, you have either found a risk or an unnecessary connection.
Only then do you draw zones. Based on function, risk, and operational cohesion — not based on IP ranges.
And every zone and every conduit needs ownership. Who can approve changes? Who controls the firewall rules? Who periodically validates whether the communication is still necessary? Without ownership, segmentation is a drawing. With ownership, it becomes control.
The core
OT security rarely fails because people do not know Zero Trust or IEC 62443. It fails because those models too often remain above the factory floor.
An old PLC is not going to support modern security. A Modbus connection does not suddenly become safe. A line that has been running for fifteen years is not replaced because the security architecture would look nicer.
That is why OT security does not start with trust, and not with distrust either. It starts with boundaries.
You do not need to explain Zero Trust to a Siemens S7-300. You need to design the network around it so that it never has to understand it.