OT Network Segmentation: Purdue, Zones and Conduits, and What IEC 62443 Expects

A plant network engineer plugs a laptop into the office VLAN to check email during a shift changeover. From that same jack, the laptop can reach the HMI on the bottling line, the PLC driving the filler, and the historian logging tank levels. Nothing stops it. There's no firewall rule to trip, no VLAN boundary to cross, because the whole plant sits on one flat network.

That setup isn't rare. It's the default state of a lot of plants that grew network by network, contractor by contractor, over twenty years. The fix has a name, three names actually: the Purdue model for structure, zones and conduits for enforcement, and IEC 62443 for the standard that ties both together. None of the three is optional if you want a defensible answer to "what happens if a laptop gets infected."

TL;DR: OT segmentation works in three layers. The Purdue model assigns every device a level, from field sensors to corporate IT. IEC 62443 groups devices that share risk into zones and connects zones only through controlled conduits, enforced with a deny-by-default firewall rule. An industrial DMZ (Level 3.5) sits between IT and OT so no enterprise system ever talks to a controller directly. NotPetya proved the cost of skipping this: flat networks let the malware wipe HMIs and SCADA servers at Maersk, Merck, and Mondelez in 2017, with global damages near $10 billion (NotebookLM, OT Segmentation notebook, 2026).

What Is the Purdue Model, and Where Does It Still Hold?

The Purdue model splits an industrial network into six functional levels, Level 0 through Level 5, so equipment only trusts the layers it needs to talk to (NotebookLM, OT Segmentation notebook, 2026). Built in 1991 for manufacturing data flow, not security, it now doubles as the reference architecture every OT segmentation project starts from.

Level 0 is the physical process: sensors, actuators, valves, and drives touching the product directly. Level 1 holds the PLCs and RTUs running millisecond control loops on that equipment. Level 2 adds supervision, HMIs and SCADA, where an operator watches the process and adjusts setpoints. Level 3 aggregates that data plant-wide through MES and historians. Levels 4 and 5 are business systems and corporate IT, ERP, email, and the wider enterprise network.

Levels 2 and 3 carry the highest lateral-movement risk of the bunch. They run standard, commercial operating systems, frequently Windows, which makes them the same class of target an attacker already knows how to compromise on the IT side (NotebookLM, OT Segmentation notebook, 2026). A PLC running proprietary firmware is a harder target. An HMI running Windows 10 with a shared admin password is not.

Citation capsule: The Purdue model assigns industrial equipment to six levels, from Level 0 physical processes through Level 5 enterprise IT, so each layer only trusts the layers designed to communicate with it. Level 2 and Level 3 systems run standard commercial operating systems, usually Windows, which makes them the primary lateral-movement targets for attackers pivoting from a corporate network into the physical control environment (NotebookLM, OT Segmentation notebook, 2026).

The model shows its age at the edges. It was never built for cloud analytics or direct MQTT publishing from the field, which is why a plant running a unified namespace architecture has to decide deliberately where that broker sits relative to Level 3, rather than assuming the six-level chart already answers the question. What the model still gets right is the trust boundary logic: a device at one level should never accept an unsolicited connection from two levels up.

What Are Zones and Conduits, in Practice?

A zone is a group of assets that share the same security requirements, a robotic cell, a chemical dosing skid, a maintenance VLAN, each with a defined perimeter around it (NotebookLM, OT Segmentation notebook, 2026). A conduit is the controlled pathway connecting two zones, and it's the thing an attacker actually has to defeat, not the zone boundary on a network diagram.

Every conduit runs on one rule: deny by default, allow by exception. That's IEC 62443's Foundational Requirement 5, Restricted Data Flow, and it means a firewall between zones starts blocking everything, then opens only the specific ports and protocols a documented business need requires (NotebookLM, OT Segmentation notebook, 2026). A conduit between a general operations zone and a chemical dosing zone might allow read-only polling and nothing else. A command to change a dosing setpoint from the wrong side of that conduit gets dropped, not logged and forwarded.

Grouping matters as much as the firewall rule itself. The standard requires safety-related systems, corporate business assets, and temporary devices like contractor laptops to sit in separate zones, each with its own conduit into the rest of the plant (NotebookLM, OT Segmentation notebook, 2026). Put a safety instrumented system in the same zone as general HMIs, and you've erased the distinction the standard is asking you to draw.

Citation capsule: Zones and conduits are the technical mechanism behind IEC 62443's Foundational Requirement 5, Restricted Data Flow. Zones group assets that share a risk profile; conduits enforce deny-by-default, allow-by-exception traffic control between them, so a compromised zone can't propagate to the rest of the plant without crossing an inspected boundary (NotebookLM, OT Segmentation notebook, 2026).

The zones-and-conduits model replaces the air gap, and that replacement is the entire point. Plants used to claim isolation by having no wire at all between OT and the internet. Vendor laptops, cellular modems for remote diagnostics, and cloud analytics pilots killed that claim years before most plant managers admitted it. Zones and conduits assume the connection exists and design around containing it instead.

What Is the Industrial DMZ For?

The industrial DMZ, Level 3.5 on the Purdue chart, is a buffer zone that forces every IT/OT connection to terminate and restart rather than pass through (NotebookLM, OT Segmentation notebook, 2026). It sits between enterprise IT and the OT network as a third zone, with its own servers and its own security policy, not as an extension of either side.

The rule that makes it work is simple to state and easy to violate: no Level 4 or Level 5 system ever initiates a connection that reaches Level 3 or below directly (NotebookLM, OT Segmentation notebook, 2026). Everything an enterprise system needs from OT, historian data, log feeds, patch distribution, gets staged in the DMZ instead. An analytics platform queries a read-only historian replica sitting in the DMZ. It never touches the production historian on the OT side.

The standard build is a dual-firewall architecture, with an outer, IT-facing firewall and an inner, OT-facing one, ideally from two different vendors so a single software flaw can't compromise both boundaries at once (NotebookLM, OT Segmentation notebook, 2026). The inner firewall runs a deny-all inbound policy, so every OT-to-DMZ connection has to originate from inside OT. That single design choice is what stopped Colonial Pipeline's 2021 ransomware from reaching the physical pipeline control network at all; the shutdown happened because business systems the pipeline depended on, billing and dispatch, were compromised without an intervening DMZ decoupling them (NotebookLM, OT Segmentation notebook, 2026).

A DMZ isn't a place to park general-purpose servers. It hosts specific, narrow services: jump servers for remote access, patch mirrors, MQTT brokers or OPC tunneling endpoints for telemetry, and log collectors feeding a SIEM. Anywhere a plant is bridging OPC UA traffic out to enterprise analytics, that tunneling endpoint belongs here, not on a dual-homed server straddling both networks. A server with network cards on both the IT and OT sides defeats the whole architecture in one cable run, which is exactly what happened in the 2017 Triton attack on a Saudi petrochemical plant, where a dual-homed engineering workstation bridged the safety network directly to the process network (NotebookLM, OT Segmentation notebook, 2026).

Which Firewall and Conduit Rules Survive Contact With Production?

Firewall rules that survive contact with production share one trait: they name a specific protocol and a specific direction, never "allow any." Port-and-IP filtering alone can't tell a legitimate historian query from a crafted attack using the same port, which is why defensible OT firewalls run application-layer, stateful inspection that validates the actual industrial protocol crossing the wire (NotebookLM, OT Segmentation notebook, 2026).

A production-tested rule set looks narrow on purpose. The active OT historian pushes data outbound to a read-only replica in the DMZ over one named port. Edge gateways push telemetry outbound over TLS to a broker in the DMZ. OT endpoints forward logs outbound to a collector. Patch mirrors get pulled by OT, never pushed from IT. Remote access runs inbound only as far as a broker in the DMZ, never straight to a controller (NotebookLM, OT Segmentation notebook, 2026). Every one of those rules states a direction, a protocol, and an endpoint, not a subnet.

The rule that kills more segmentation projects than any exploit is the temporary one nobody removes. A vendor requests open access to diagnose a fault, the technician grants an "allow any/any" rule to save time, and it stays live for the next two years because closing it means finding whoever's still using it (NotebookLM, OT Segmentation notebook, 2026). Tie every exception to an expiration date at creation, or route it through a brokered access gateway instead of a standing firewall hole.

Two audits catch the drift that accumulates anyway. First, compare the actual firewall ruleset against the documented network diagram on a fixed schedule, because permissive rules survive long after the reason for them is forgotten. Second, watch for dual-homed devices creeping back in, an engineering laptop with a wireless card active while it's plugged into the OT switch counts, even without a second wired NIC.

Citation capsule: IT-aware but not OT-aware firewalls filter only by port and IP address, which can't distinguish a legitimate historian query from an attack using the same port. Defensible OT segmentation requires application-layer, stateful inspection that validates the actual industrial protocol, paired with a deny-by-default rule and an expiration policy on every temporary exception (NotebookLM, OT Segmentation notebook, 2026).

When Are Data Diodes Justified?

A data diode is a hardware device built to make reverse traffic physically impossible, not merely blocked by a rule that a misconfiguration could undo (NotebookLM, OT Segmentation notebook, 2026). Two boards connected by a short fiber-optic cable do the work: the sending board has a laser, the receiving board has a photodiode and nothing capable of transmitting light back. There's no software patch that reopens that path, because the path was never wired in the first place.

That guarantee comes at a cost most plants don't need to pay. Standard protocols like TCP/IP need a two-way handshake to function at all, so a pure diode would break every connection running over it. A unidirectional gateway solves that with software proxies on each side: the OT-side proxy terminates the handshake locally and pushes only the raw payload across the diode, and the IT-side proxy rebuilds it into a normal database write on a replica (NotebookLM, OT Segmentation notebook, 2026). The historian never knows its replica lives on the other side of hardware that can't send anything back.

Diodes earn their keep in a narrow set of cases: nuclear, electric grid, pipeline, and defense environments where a cyber-physical attack could cause catastrophic, irreversible damage, and where the data only ever needs to leave, never arrive (NotebookLM, OT Segmentation notebook, 2026). IEC 62443 recommends them specifically as the hardware-based boundary protection for SL4 zones, the tier built to resist a nation-state attacker (NotebookLM, OT Segmentation notebook, 2026). A firewall can be reconfigured under duress or compromised through a vulnerability. A diode's guarantee doesn't depend on a rule staying correct.

Most plants don't need one. A dual-firewall DMZ with a deny-all inbound rule already stops the direct-connection attack a diode is built for, and it costs a fraction as much while still supporting bidirectional traffic where a plant genuinely needs it, like brokered remote access. Reach for a diode when the answer to "does this zone ever need inbound traffic at all" is a hard no, not when it's merely inconvenient.

What Do SL1 Through SL4 Actually Demand?

IEC 62443 assigns each zone a Target Security Level, SL1 through SL4, scaled to the sophistication of the attacker that zone is realistically expected to face, not the highest tier available (NotebookLM, OT Segmentation notebook, 2026). Matching the control to the threat is what keeps the standard affordable across a whole plant instead of gold-plating every device equally.

SL1 protects against casual or accidental misuse: an employee plugging in an infected USB drive, or a mistyped setpoint. Its baseline is unique logins instead of shared credentials, basic network separation from IT, and disabling unused ports on devices (NotebookLM, OT Segmentation notebook, 2026). Most maintenance laptops and low-criticality sensors sit here.

SL2 assumes an attacker using simple, widely available tools with low skill and low motivation, still the largest population of real intruders. Requirements step up to role-based access control, a jump server for any remote access rather than a direct VPN into OT, and the deny-by-default conduit rule discussed earlier (NotebookLM, OT Segmentation notebook, 2026). This is where the bulk of a typical plant's production zones land.

SL3 assumes sophisticated, moderately resourced attackers, targeted ransomware and OT-specific malware. It adds mandatory multi-factor authentication on all remote access, OT-aware intrusion detection, and encrypted data in transit where latency allows (NotebookLM, OT Segmentation notebook, 2026). Reserve it for zones where a breach means significant financial loss or a safety hazard, not everything on the floor.

SL4 assumes nation-state resources and motivation. It demands MFA across all networks, not just remote access, hardware-based security like TPMs, and physical or hardware-enforced isolation such as data diodes for the most critical, ultra-sensitive assets (NotebookLM, OT Segmentation notebook, 2026). Very few zones in a typical industrial plant need this tier, and applying it everywhere just burns budget that SL2 and SL3 zones need more.

How Do You Stage a Segmentation Project?

Segmentation fails when a plant tries to draw every zone boundary in one pass. A staged rollout limits the risk of blocking a command nobody documented, which is the single most common way a segmentation project causes an outage instead of preventing one.

Stage one: build the asset inventory. You cannot protect what you don't know exists, and enforcing zones on top of an incomplete inventory is how a firewall rule ends up blocking traffic between a safety controller and a valve that nobody mapped (NotebookLM, OT Segmentation notebook, 2026). Combine passive monitoring, listening on a SPAN port, with active discovery during a planned maintenance window, since passive monitoring alone misses dormant devices and active queries alone risk crashing a fragile legacy PLC.

Stage two: map data flows, not just devices. Knowing a PLC exists tells you nothing about what it talks to. Trace which controllers issue commands to which sensors, how HMIs query historians, and where every external entry point, a vendor's 4G modem, a contractor's laptop, touches the network (NotebookLM, OT Segmentation notebook, 2026). That map is what turns into your conduit rules later; skip it and every conduit becomes a guess.

Stage three: draw zones around risk, not geography. Group by shared security requirement, not by which building the equipment sits in. A safety instrumented system needs its own zone regardless of which line it protects. A maintenance VLAN for contractor laptops needs its own zone regardless of how many devices are on it.

Stage four: stand up the DMZ before you touch the firewall rules between existing zones. Get jump servers, historian replicas, and patch mirrors working in the DMZ first, so remote access and IT reporting have a legitimate path before you start closing the illegitimate ones.

Stage five: apply deny-by-default incrementally, one conduit at a time, watching for the blocked traffic that reveals a data flow you missed in stage two. Log everything before you enforce, then enforce in a maintenance window with a rollback plan ready.

Stage six: fix vendor remote access last, and fix it properly. Retire any standing VPN that drops a vendor's device onto the OT subnet directly. Replace it with a jump server in the DMZ, time-bound to the maintenance window, scoped to the one asset the vendor actually services, and recorded end to end (NotebookLM, OT Segmentation notebook, 2026). The 2021 Colonial Pipeline breach traced back to a legacy VPN account with no multi-factor authentication; the 2021 Oldsmar water plant incident traced back to a remote-access tool bridged straight to the SCADA HMI with no DMZ in between at all (NotebookLM, OT Segmentation notebook, 2026).

Where your PLC, PAC, or RTU platform choice is still open, decide that before you finalize Level 1 zone boundaries, since the controller platform shapes what a Level 1-to-Level 2 conduit needs to carry. The same logic applies to the network layer underneath it: choosing between PROFINET and EtherNet/IP affects which switches and monitoring taps a Level 1 zone can support.

Frequently Asked Questions

What is the Purdue model in OT security?

The Purdue model is a hierarchical reference architecture that splits an industrial network into six layers, from field sensors at Level 0 to corporate IT at Level 5, so each layer trusts only the layers designed to talk to it (NotebookLM, OT Segmentation notebook, 2026). Level 3.5, the industrial DMZ, was added later to stop enterprise traffic from touching production directly.

What is the difference between a zone and a conduit in IEC 62443?

A zone groups assets that share the same security requirements, such as a packaging cell or a safety system, into one defined perimeter (NotebookLM, OT Segmentation notebook, 2026). A conduit is the controlled channel, usually a firewall or a data diode, that governs exactly what traffic may cross between two zones.

Do I need a data diode or a firewall for my OT DMZ?

Most plants need firewalls: a dual-vendor pair at the DMZ boundary covers the large majority of IT/OT data exchange (NotebookLM, OT Segmentation notebook, 2026). Data diodes earn their cost only where a zone must send data out but must never physically accept a return connection, such as a safety system feeding a historian.

What security level, SL1 through SL4, does a typical plant need?

Most production zones land at SL2, which covers unique logins, role-based access, and a deny-by-default firewall at the boundary (NotebookLM, OT Segmentation notebook, 2026). Reserve SL3 for zones facing targeted, well-resourced attackers and SL4 for the few assets where a nation-state attacker is a genuine threat model.

What is the first step in segmenting a flat OT network?

Build a full asset inventory before you write a single firewall rule. IEC 62443 segmentation applied on top of an incomplete inventory routinely blocks a command nobody documented, which can stop production or trip a safety interlock (NotebookLM, OT Segmentation notebook, 2026).

Conclusion

Every flat-network plant I've walked into had a reasonable-sounding excuse for it: air-gapped once, never revisited, or "too disruptive to fix now." NotPetya, Triton, and Colonial Pipeline are what happens when that excuse meets a compromised office laptop or an unpatched VPN.

The fix isn't exotic. Map what's actually on the network, group it by shared risk into zones, and let a firewall or diode enforce exactly what crosses between them. Put a real DMZ between IT and OT so no enterprise system ever reaches a controller directly. Match the security level to the threat each zone actually faces instead of guessing.

None of this happens in one weekend, and none of it should. Stage the rollout, inventory first, and treat the vendor VPN as the last mile, not the first fix. A segmented plant turns a compromised laptop into a contained problem instead of a plant-wide one.