Why it matters
What segmentation actually prevents
Most OT incidents that reach the physical process — from Triton/TRISIS to Colonial Pipeline — involved an attacker moving laterally from an IT-connected system into the OT environment. Segmentation limits how far that movement can go.
The Purdue model
The reference architecture
The Purdue Enterprise Reference Architecture defines six levels of an industrial network — from field devices at Level 0 to enterprise IT at Level 4–5. IEC 62443 uses this model as the basis for zone definition.
Level 4–5
Enterprise / IT network
Business systems, ERP, email, internet access. This is where your IT team operates. Should be fully separated from OT by a DMZ — no direct connections to Level 3 or below.
DMZ
Demilitarised zone
The buffer between IT and OT. Historians, remote access servers, and data exchange systems sit here. Data flows should be one-directional where possible — OT to IT, not IT to OT.
Level 3
Site operations / SCADA
Supervisory control systems, SCADA servers, data historians, and engineering workstations with access to the control network. Often the most vulnerable level — many attacks target this zone first.
Level 2
Area control / HMIs
Human-machine interfaces, area controllers, and local data servers. Direct visibility of process state. Changes here can affect physical process — access must be tightly controlled.
Level 1
Basic control / PLCs
PLCs, RTUs, and other basic control devices. These execute your control logic and drive final elements. Firmware updates and configuration changes require formal MoC processes.
Level 0
Process / field devices
Sensors, actuators, and final elements. Physically connected to the process. While traditionally "air-gapped by physics," smart sensors and field buses increasingly introduce network exposure.
Implementation
How to segment your OT network
Segmentation is an engineering project, not a product purchase. Follow the same structured approach you would for a safety lifecycle — assess current state, define the target, implement, then maintain.
01
Draw the current state
Before you can segment, you need to know what's on your network. Produce a network diagram showing every device, switch, firewall, and communication path. Focus on L1–L3 first. If you don't have this, a passive network monitoring tool (like Claroty, Nozomi, or Dragos) can generate it without touching your devices.
02
Identify your natural zones
Group assets by function, criticality, and required communication. Your Safety Instrumented System, DCS, historian, and engineering network are natural candidates for separate zones. Consider: what would happen if this group of devices was compromised? High-consequence groups need tighter isolation.
03
Audit your conduits
For every zone boundary, list every communication path crossing it — firewall rules, VPN connections, historian links, remote access tools. Challenge each one: is this communication necessary? Can it be one-directional? Can it be replaced by a data diode? Every unnecessary conduit is an unnecessary risk.
04
Implement the DMZ first
If your IT and OT networks share any direct connectivity, establishing a DMZ is the highest-impact first step. Move the historian and any data exchange systems into it. Enforce that no IT system can initiate a connection directly to Level 3 or below — all data flows through the DMZ.
05
Apply firewall rules by zone pair
Document the allowed communication between each zone pair — not a blanket "allow between L2 and L3" but specific source IPs, destination IPs, ports, and protocols. Start with a default-deny approach and add exceptions. This is your conduit specification — it should be under your MoC process.
06
Test and monitor
Segmentation is not a one-time exercise. Firewall rules drift, new devices get connected in the wrong zone, and temporary maintenance connections become permanent. Schedule quarterly reviews of your conduit documentation and alert on any traffic that doesn't match your zone model.
Common mistakes
What looks like segmentation but isn't
Soft segmentation — VLANs without firewall enforcement
VLANs separate broadcast domains but don't enforce traffic rules. Routed traffic between VLANs needs a firewall with explicit allow/deny rules to constitute real segmentation.
Historian directly bridging IT and OT
Historians that connect directly to both the IT network and the control network create a conduit that bypasses your firewall. Move the historian to a DMZ with separate connections to each side.
Remote access VPN terminating inside the OT zone
VPN endpoints should terminate in the DMZ, not in Level 2 or 3. Remote users then access specific OT systems through a jump server — every session is authenticated and logged.
"Temporary" maintenance connections that stay permanent
Every connection added for maintenance should be in your MoC system with a removal date. An annual audit of your firewall rules against your conduit documentation will catch these.
Stay informed
Get the daily OT brief — free
CVE alerts, vendor advisories, and ICS security news — curated daily for controls engineers. Under 5 minutes to read.
Get tomorrow's brief free →