Segmentation is consistently identified as the OT control with the widest gap between how important it is and how well it is actually implemented. Everyone agrees it matters. Comparatively few environments have it in a form that would contain an incident.
The reason is rarely disagreement about the goal. It is that segmentation depends on prerequisites most programs skip, and it is governed by two frameworks that people routinely treat as competing when they are complementary.
Is the Purdue model still relevant?
Yes as a reference for understanding how a plant is organized, no as a literal description of how modern industrial networks are built.
The Purdue Enterprise Reference Architecture organizes industrial systems into levels — physical process at Level 0, sensors and actuators, basic and supervisory control, site operations at Level 3, and enterprise IT at Levels 4 and 5, with a DMZ between the operations and enterprise domains. As a shared vocabulary for where an asset sits and what it talks to, it remains indispensable.
What has changed is the data flow. IIoT sensors report directly to cloud analytics platforms. Vendors maintain equipment through remote connections that do not traverse the levels in order. Historians replicate upward continuously. A strict reading of Purdue says traffic moves level by level; in real plants it does not.
The correct conclusion is not that Purdue is obsolete. It is that Purdue tells you how your environment is structured, and IEC 62443 tells you how to protect it. Use both.
How zones and conduits work
IEC 62443-3-2 replaces "which level is this on" with two concepts:
- A zone is a grouping of assets that share the same security requirements. Membership is determined by required protection, not by physical location or network topology.
- A conduit is a defined communication path between zones, with explicitly specified traffic and a documented security control at each end.
The practical difference is significant. A safety instrumented system and a general HMI may sit on the same Purdue level and belong in entirely different zones because they require different protection. Conversely, assets in different physical buildings that share a criticality and a protection requirement can be one zone.
The method, in order:
- Identify the system under consideration — draw the boundary of what you are protecting.
- Partition into zones by required protection, criticality and consequence of compromise.
- Identify every conduit between zones, including the ones nobody documented.
- Assess risk per zone and assign a target security level (SL-T) from 1 to 4.
- Apply controls at the conduits sufficient to meet the target.
- Document it in a form an auditor and a control engineer can both read.
Step 3 is where programs find the surprises: the engineering laptop that bridges two zones, the vendor modem nobody knew was installed, the historian with a route to the business network that was meant to be temporary.
What CISA now expects in an asset inventory
You cannot zone an estate you have not enumerated, which is why asset inventory has become the gating requirement in OT guidance. CISA's guidance for critical infrastructure sets out 14 attributes to record for every OT asset:
| Asset number | Manufacturer |
| Asset role / type | Model |
| Hostname | Operating system |
| IP address | Physical location |
| MAC address | Ports and services |
| Active communication protocols | User accounts |
| Asset criticality | Logging configuration |
Three of these do most of the work and are the three most often missing. Active communication protocols tell you what the conduits actually carry. Asset criticality determines which zone an asset belongs in and how much protection it justifies. Logging configuration determines whether you would ever detect a compromise — and the majority of organizations still lack the visibility to spot reconnaissance or lateral movement before operations are affected.
Collect this passively wherever possible. Active scanning of a live control network is a genuine operational risk, and in many facilities it is prohibited for good reason.
Why the air gap is a myth worth abandoning
True air gaps are rare and impractical. You need process data for billing, maintenance planning, quality, and increasingly for the analytics that justified the investment in the first place. Declaring an air gap that does not exist is worse than admitting the connection, because the undocumented path gets no controls and no monitoring.
The goal is strict, monitored, documented segmentation — not isolation. An IT/OT DMZ where data is brokered rather than routed, with no direct path between enterprise and control networks, is the working version of the idea.
Why remote access keeps causing incidents
The dominant initial-access pattern in OT incidents is not a clever exploit against a PLC. It is a path that was built for a legitimate reason and left standing:
- Vendor maintenance connections. OEMs often maintain equipment remotely across many customers. If the vendor is compromised, their legitimate connections become downstream paths into every site they serve.
- Shared credentials. Accounts used by multiple technicians, unchanged for years, with no attribution.
- Direct internet exposure. Control devices reachable from the public internet, frequently with default credentials — a finding CISA has repeatedly warned about.
- IT-to-OT pivot. Ransomware that arrives through email, spreads across a flat network and reaches control systems because nothing stopped it at the boundary.
What works: no direct vendor connections into the control network at all. Broker access through a jump host inside a DMZ, tie every session to a named individual, enforce multi-factor authentication, grant access only for the duration of the work, and record the session. Identity-based, per-resource access — where the technician never receives a network position and reaches exactly one asset — is the model to build toward.
Enforcement that understands industrial protocols
A firewall between IT and OT that permits "any/any" satisfies a network diagram and stops nothing. Enforcement at a conduit needs to inspect the protocols themselves — DNP3, Modbus, EtherNet/IP, IEC 61850, OPC UA — and apply controls at the function level.
The concrete example: a monitoring segment should be able to issue read requests to a controller and should never be able to issue a write. Only a firewall that parses the industrial protocol can enforce that distinction, because both ride the same TCP port.
A sequence that does not break production
The reason segmentation projects stall is fear of stopping the plant, which is rational. The sequence that works:
- Inventory passively. Build the asset register with the 14 attributes. Expect six to twelve weeks in a substantial facility.
- Map actual flows. Observe what genuinely talks to what, for long enough to catch monthly and quarterly processes. Design from observed traffic, never from the as-built drawings.
- Design zones and conduits on paper. Review with control engineers and operations, not only with IT.
- Deploy in monitor mode. Put enforcement points in place passing all traffic while logging it. This is where you find the flows the mapping missed.
- Enforce incrementally, one conduit at a time, during planned windows, with a tested rollback.
- Monitor continuously. Segmentation without detection tells you nothing about whether it held.
What this buys you
Segmentation does not prevent compromise. It reduces the blast radius of one — which is precisely what regulators have converged on. TSA's aviation directives require that OT can continue operating safely if IT is compromised. NERC CIP builds on the Electronic Security Perimeter. NIST SP 800-82 and IEC 62443 describe the same architecture in different vocabularies. The consistency across sectors is not coincidence; it reflects what incident response teams learn repeatedly about how these events unfold.
BlackHawk Data holds the Fortinet OT Security specialization alongside our Fortinet Platinum partner tier, and our OT security assessment delivers the asset inventory, flow mapping and zone design described above as a defined engagement. Practice detail is at /solutions/ot-cybersecurity, with a deeper technical treatment in the OT technical guide.