Every plant network diagram ever drawn for an auditor has the same problem: it’s aspirational. It shows the Purdue model in its clean, textbook form — Level 0 sensors at the bottom, Level 3 MES in the middle, a nice firewall icon between Level 3 and Level 4 — and it bears almost no resemblance to what’s actually plugged into that unmanaged switch behind the palletizer. CISA’s push toward documented, verifiable segmentation is forcing a reckoning with that gap, and it’s happening at the same time IEC 62443-3-3 conformance is starting to show up as a line item in cyber-insurance renewals and OEM customer questionnaires. That combination means the diagram now has to match reality, because someone is finally going to check.
The standard itself doesn’t tell you where to draw the lines. IEC 62443-3-3 defines system-level security requirements and gives you the vocabulary — zones as groupings of assets that share a security policy, conduits as the communication paths between them, foundational requirements mapped to security levels — but it is deliberately silent on methodology. Most teams default to the one methodology everyone already knows: group by device type, or worse, by Purdue level. That’s the mistake. It produces a diagram that’s easy to draw and nearly useless for actually stopping lateral movement.
Why device-type grouping fails on a real floor
Grouping “all PLCs” into one zone and “all HMIs” into another feels tidy, but it ignores the thing that actually matters for a security architecture: what happens if this asset is compromised. A PLC controlling a non-critical conveyor and a PLC running a batch reactor’s safety interlocks are the same device type and completely different risk profiles. Put them in the same zone with the same conduit rules and you’ve either over-restricted the low-consequence asset or, far more commonly, under-restricted the high-consequence one because the zone’s rules got set to the lowest common denominator to keep production running.
Flat OT networks didn’t get flat by accident — they got that way because segmenting by function is hard and segmenting by convenience is easy. Ransomware advisories keep citing the same root cause because that root cause keeps getting reproduced: one broadcast domain, one compromised engineering laptop, and the attacker has line of sight to everything from the barcode scanner to the safety PLC.
Group by consequence of compromise, not by what the asset is
The framework that actually holds up under audit and under attack starts with a different question for every asset: if this thing is compromised or taken offline, what’s the worst realistic outcome? That question sorts assets into zones far more usefully than “is it a PLC or a historian.”
A practical way to run this exercise on a live plant:
- Safety consequence first. Anything tied to a SIS, interlock, or physical safety function goes into its own zone, full stop, regardless of what protocol it speaks or what vendor made it. This zone gets the highest security level target (SL-T) in the plant and the most restrictive conduit rules, typically one-way or tightly whitelisted communication out.
- Production-continuity consequence next. Group assets by what section of the process would actually stop if this device went down or started misbehaving — not by control layer, but by process cell or unit operation, echoing the ISA-88 model more than a pure Purdue layer. A line’s PLCs, drives, and local HMI that all serve one unit operation can reasonably share a zone even though they’re “different device types,” because their failure modes are coupled anyway.
- Data-sensitivity consequence separately. Historians, MES servers, and quality databases often need their own zone because the consequence of compromise there is data integrity and IP exposure, not a stopped line — a genuinely different risk than the plant-floor zones and one that usually justifies a different conduit posture (allow reporting traffic up, restrict engineering traffic down).
- Vendor remote-access paths get quarantined, not trusted. Any device or workstation that supports third-party remote access — OEM support laptops, remote monitoring gateways — belongs in a zone that assumes it will eventually be the entry point, because statistically it often is.
Notice what this framework does not do: it doesn’t require you to rip out your existing VLAN structure or re-IP the plant. Most plants already have partial segmentation from network design decisions made for entirely different reasons — broadcast domain size, cable plant history, a merger that never got fully integrated. The consequence-based exercise tells you which of those existing boundaries are load-bearing and which ones are accidental, and where the real gaps are.
Conduits are where the actual security work happens
Zones get the attention in planning meetings, but conduits are where you either enforce the policy or fail to. A conduit in IEC 62443-3-3 terms is not just “a firewall between two subnets” — it’s a defined communication relationship with an expected protocol set, expected direction, and expected data volume. That specificity is what makes a conduit defensible to an auditor and useful to an incident responder.
When you write the firewall rule for a conduit, justify it in terms the standard actually asks for: which foundational requirement it satisfies (FR 5, restricted data flow, is the obvious one, but access control and use control conduits matter too), and what security level it’s targeting. “We block port 445 between the historian zone and the process-cell zone because there is no legitimate SMB traffic in that direction, and lateral movement via SMB is the dominant technique in the ransomware advisories this plant’s risk assessment cites” is a sentence an auditor can work with. “We have a firewall there” is not.
The shutdown-window reality
You will not get a clean-sheet re-architecture. You get a maintenance window, maybe two, and a plant manager who wants the line back up on schedule. The honest way to sequence this: implement conduit enforcement in monitor-only mode first, wherever your firewall or industrial IDS supports it, and run it for a production cycle before you flip anything to block. That surfaces the legacy traffic nobody documented — the historian pull that runs at shift change, the OEM’s undocumented polling protocol — before it becomes a 2 a.m. outage call. Segmentation done in a single blocking cutover during a shutdown is how you turn a security project into a downtime incident, and downtime incidents are what get security projects cancelled.
What auditors and insurers are actually going to ask
The bar being set right now isn’t “show me a segmented network.” It’s “show me you can explain why the segmentation is drawn where it’s drawn, and show me the conduit rules trace back to that reasoning.” A zone diagram with a one-line justification per zone — the consequence category it’s protecting against, the target security level, the conduits in and out — will hold up far better than an elaborate diagram with no rationale behind the lines. That’s also, not coincidentally, the version of the exercise that actually makes the plant harder to move laterally through, which is the point CISA’s guidance is making in the first place.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
