Ask a plant for its segmentation documentation and you will usually get a diagram. It will show a corporate network at the top, a demilitarized zone in the middle, a control network below that, and a set of cells at the bottom. It will be clean, and it will map onto the Purdue Enterprise Reference Architecture.
Then ask the same plant a narrower question: which devices in cell three currently talk to anything outside cell three, and over what protocols. Very few sites can answer that from data rather than from memory. The gap between those two answers is where most OT segmentation programs actually live.
The diagram is a statement of intent. The traffic is the state of the network. Security depends on the second one, and IT led programs consistently underweight it because in enterprise environments the two stay closer together than they do in a plant.
Mistake One: Treating Segmentation as a Topology Problem
In IT, segmentation is largely an addressing and policy exercise. You define subnets, you write firewall rules, you push host based controls, and the resulting posture is close to what you designed because the endpoints are managed and the design predates most of the traffic.
Industrial networks invert that order. The traffic predates the design. A control system was engineered to make a physical process work, and its communication patterns are a consequence of process engineering decisions made years before anyone drew a security zone around them. A segmentation project that starts from a diagram is asserting a policy over traffic it has not yet observed.
This is why so many OT segmentation efforts stall at the enforcement step. The design gets approved, the firewalls get deployed in monitor mode, and then the exceptions start arriving: a historian that pulls from more places than anyone documented, a batch server that reaches directly into a cell, peer to peer messaging between controllers in what were supposed to be separate zones. Each exception gets a rule. Six months later the rule set describes the original network with extra steps.
IEC 62443 is precise about this, and the precision is often skipped. The standard's unit of design is the zone, a grouping of assets with common security requirements, connected by conduits, which are the defined and controlled communication paths between zones. The obligation is not to draw zones. It is to enumerate the conduits, including the ones you did not intend to create.
Mistake Two: Assuming a VLAN Is a Boundary
VLANs separate broadcast domains. That is all they do. Two devices in different VLANs cannot reach each other only if nothing routes between them and no host bridges them.
In practice, plant networks accumulate bridges. Engineering workstations get a second network interface so they can reach both the business network and the control network without a badge trip. Vendor support appliances sit inside a cell with an outbound tunnel. Unmanaged switches appear under a panel because somebody needed three more ports during a shutdown, and nothing in the management plane knows they exist.
The Triton incident at a Saudi petrochemical facility in 2017 is the reference case for what this costs. The attackers reached Schneider Electric Triconex safety instrumented system controllers by way of a workstation that had connectivity to both the distributed control system and the safety system. The safety layer was supposed to be the most rigorously separated thing in the plant. The separation existed on paper and was defeated by a single dual homed host.
Every dual homed host is a conduit whether or not it appears in the zone diagram. If you cannot produce a current list of every asset in your control network with more than one active network path, your segmentation state is unknown, not partial.
Mistake Three: Guarding North and South, Ignoring East and West
Enterprise security instincts point at the perimeter, and the IT to OT boundary gets most of the attention and most of the budget. That boundary matters. It is also not where the consequential movement happens once an adversary is inside.
The 2015 Ukraine grid attack is instructive because the final actions were not exotic. Once the operators' own environment was reachable, the attackers used legitimate remote access to issue legitimate breaker commands. Nothing at a perimeter would have flagged an authorized workstation doing an authorized thing. What would have flagged it is a model of which workstation normally issues which commands to which substations, at what times.
Intra zone traffic in OT is dense and highly regular. Controllers poll field devices on fixed intervals. HMIs subscribe to specific tag sets. Historians collect on schedules measured in seconds. That regularity is the detection opportunity, and a segmentation strategy that only enforces at zone boundaries throws it away.
Mistake Four: Allowing a Port and Calling It a Policy
This is the most common technical error, and it is subtle enough that it survives audits.
A firewall rule permitting TCP 502 between a supervisory host and a controller permits Modbus. It does not distinguish a read of holding registers from a write of multiple registers, and it does not distinguish either from function code 43 device identification, which is how an attacker inventories what a controller actually is. On EtherNet/IP over TCP 44818, allowing the port allows the full range of CIP services, including the ones that stop a processor or download a program. DNP3 on TCP 20000 carries both routine polling and function code 13, cold restart.
The rule set says the conduit is controlled. What is controlled is the socket, not the semantics.
OPC Classic makes the problem visible in its most extreme form. Its DCOM foundation negotiates a dynamic port after the initial connection, which means a firewall that supports it naively ends up permitting a very wide ephemeral range between two zones. Many sites solved this years ago with a tunneling product and forgot that the original rule stayed in the configuration.
A conduit is only controlled to the depth your inspection goes. Port level rules give you port level control, and industrial protocols carry their consequences in the payload.
The useful question about any OT firewall rule is not whether it is scoped to the right hosts and ports. It is which protocol functions it permits, and whether anyone would notice if the mix of functions crossing that conduit changed tomorrow.
Mistake Five: Reaching for IT Microsegmentation Tooling
Modern data center segmentation leans on host agents, identity aware proxies, and active discovery. None of the three transfers cleanly.
You cannot install an agent on a PLC, an RTU, a protection relay, or a variable frequency drive. Many of these devices have no concept of user identity at all, only a protocol session. And active discovery, the technique that makes IT asset inventory tractable, carries real risk against equipment with constrained network stacks. There is a long operational history of legacy controllers faulting under scan traffic they were never designed to parse, which is why active methods in OT belong in maintenance windows with the process down, not on a weekly schedule.
The consequence is that the inventory and traffic matrix that segmentation depends on has to come from observation rather than interrogation. Passive collection from SPAN or mirror ports with full packet inspection produces the asset list, the protocol breakdown, the peer relationships, and the timing envelope without transmitting anything into the process network. Flow telemetry such as sFlow or NetFlow complements it usefully for breadth across many switches, but flow records alone will not tell you which CIP service or Modbus function code crossed a conduit, and that is precisely the resolution segmentation decisions require.
Mistake Six: Treating It as a Project With an End Date
Segmentation is usually funded as a capital project, which gives it a completion milestone. But the network keeps changing after the milestone. A line gets retooled, a vendor swaps a controller, an integrator adds a gateway during a turnaround, an emergency rule gets added at two in the morning and never removed.
Colonial Pipeline in 2021 is worth reading carefully here, because the segmentation largely held. The ransomware affected business systems, not the pipeline control systems. The pipeline stopped anyway, as a precautionary decision, because the operator could not quickly establish that the operational side was unaffected.
That is the real lesson for anyone building zones. Segmentation limits blast radius, but on its own it does not produce the evidence needed to keep running during an incident. The value of continuous behavioral observation at the conduits is not only detection. It is the ability to say, with data, that the control network's traffic looks exactly as it did last week, and therefore the process can stay up.
What the Sequence Should Be
Reverse the usual order. Observe first, then design, then enforce, then keep verifying.
Start by building the actual communication matrix from passive observation over a period long enough to include a maintenance cycle and a shift pattern, typically several weeks. Every OT network contains flows that only appear during a batch change or a monthly job.
Draw zones around what you find rather than around the reference architecture. The Purdue model is a good conceptual scaffold and a poor site plan. Where observed traffic contradicts the intended zone boundary, that is an engineering finding to resolve, not a diagram to overwrite.
Write conduit rules at protocol function granularity where your enforcement points allow it, and where they do not, compensate with monitoring that understands the payload.
Then treat the matrix as a living baseline. A new conduit appearing between two zones, a controller acquiring a peer it never had, a function code showing up on a link that has only ever carried reads: these are the signals that tell you the segmentation you deployed is still the segmentation you have. Devices in a control network are deterministic enough that changes like these stand out clearly.
Segmentation done this way stops being a diagram that ages badly and becomes a property of the network you can check on any given day.