OT Network Segmentation: From Purdue Model Theory to Working Practice

Almost every OT security assessment ends with the same finding: the network is flat. The HMI can reach the historian, the historian can reach the PLCs, the engineering workstation can reach everything, and one compromised laptop can reach all of it. Everyone agrees segmentation is the fix. And yet flat OT networks persist, because the traditional path to segmentation, firewalls, VLAN redesign, and change windows measured in quarters, asks operations to accept risk and downtime today for security benefits someday.

This guide explains what OT network segmentation needs to accomplish, where the Purdue model and IEC 62443 fit, why firewall-based projects stall, and how software-defined microsegmentation turns flat networks into segmented networks in hours instead of quarters.

Why Flat Networks Are the Attacker's Best Friend

Initial access to an industrial network is rarely the damaging step. The damage comes from what follows: lateral movement. An attacker who lands on a corporate-connected workstation or rides in through a vendor VPN session needs to travel, to enumerate the network, find the supervisory systems, and reach the controllers. A flat network turns that journey into a stroll. Every documented ICS attack playbook, from the Ukrainian grid incidents onward, depended on the freedom to move sideways.

Segmentation attacks the economics of the intrusion. When each zone contains only a few assets and each conduit permits only defined traffic, the attacker's every step requires a new compromise. Blast radius shrinks from "the plant" to "one cell."

The Purdue Model: Useful Map, Not a Security Plan

The Purdue model organizes industrial architecture into levels, from Level 0 field devices and sensors up through controllers (Level 1), supervision (Level 2), operations management (Level 3), the DMZ (3.5), and enterprise IT (Levels 4-5). It remains the shared vocabulary of OT architecture, and its central lesson, that control layers should be insulated from enterprise layers, still stands.

But the Purdue model describes layers, not security. Real plants now have cloud connections from Level 2, vendors tunneling directly to Level 1 devices, and IIoT sensors that ignore the hierarchy entirely. Segmenting "by Purdue level" leaves each level internally flat, and most lateral movement happens within a level, HMI to HMI, PLC to PLC.

IEC 62443 sharpens the model into something enforceable: group assets into zones by risk and function, connect zones only through controlled conduits, and assign each zone a target security level. Zones can and should be much smaller than Purdue levels, down to a single production cell or even a single fragile device.

Why Firewall-Based Segmentation Projects Stall

The conventional approach, inserting firewalls between VLANs, re-architecting the address space, and writing ACLs for every flow, fails for predictable reasons. It requires downtime that operations cannot grant. It demands a complete traffic map that nobody has for a 20-year-old network. Its rule bases grow brittle: every plant change requires firewall changes, and misconfigurations, not firewall product failures, are behind the overwhelming majority of firewall-related breaches. And it does nothing about identity: a firewall permits traffic between addresses, but cannot ask who is at the keyboard.

The result is the industry's dirty secret: segmentation projects that run 18 months, consume the security budget, and end with a handful of coarse zones and an exception list that swallows the policy.

Software-Defined Microsegmentation: Zones and Conduits as Policy

Software-defined segmentation implements IEC 62443 zones and conduits as an overlay on the existing network. No re-addressing, no new hardware between devices, no downtime window.

With BlastWave's BlastShield, the model works like this:

Zones are defined logically. A production cell, a set of pumps, or a single unpatchable RTU becomes a protected zone regardless of its physical wiring or IP address. Devices inside are cloaked: invisible and unreachable except through policy.

Conduits are identity-based. Instead of "this subnet may reach that subnet," the policy says "this engineer, on this enrolled device, may reach this PLC over this protocol." Access is authenticated with passwordless MFA, so a conduit cannot be borrowed by whoever steals a password.

Legacy devices get a virtual air gap. The 15-year-old controller that cannot be patched is placed in a zone of one. Its vulnerabilities remain, but nothing unauthorized can reach them, which converts an urgent patching problem into a controlled reachability problem.

Changes are policy edits, not network projects. A new vendor, a new line, or a decommissioned asset is a policy change that takes minutes, not a firewall change request that takes weeks.

Because it deploys this way, microsegmentation also fixes the segmentation-vs-remote-access tension: the same policy engine that walls off zones is the one that grants OT secure remote access through them, so segmentation never becomes the reason vendors circumvent security. (See also: Securing Vendor Remote Access to OT Systems.)

A Pragmatic Segmentation Sequence

1. Start with the crown jewels and glass jaws. Zone your safety systems, your most critical process, and your most fragile unpatchable devices first. Don't wait for a full asset inventory to protect the ten devices you already know matter.
2. Wrap the access paths. Put identity-based policy on every remote and cross-zone path, especially vendor connections, since that's where intrusions start.
3. Expand zone by zone. Each cell or process area becomes a zone as you go; the overlay model means each step is independent and reversible.
4. Test like an attacker. After each phase, verify whether a compromised workstation in one zone can discover or reach assets in another. Reachability, not rule count, is the metric.

‍