OT Network Segmentation - Protecting Industrial Systems from Cyberattacks
OT network segmentation per IEC 62443 - zones, conduits, implementation methods and monitoring tools. A practical guide with real-world incident examples.
Józef Sulwiński 
Attacks on industrial infrastructure are no longer a theoretical scenario. In December 2025, a coordinated attack struck over 30 Polish wind and solar farms, a CHP plant serving half a million customers, and a manufacturing company - damaging RTU controller firmware and severing operator communications (CERT Polska report, January 2026). Before that, Colonial Pipeline, Oldsmar Water Treatment, COSMICENERGY - each of these incidents demonstrated that a lack of segmentation between IT and OT networks leads to real-world consequences.
This article consists of two parts. The first explains the theoretical framework - what segmentation means under IEC 62443, which methods to apply, and which OT protocols to account for. The second shows how we approach this in practice - with specific matrices, checklists, and control mappings.
of Dragos assessments found weak IT/OT segmentation
of IR incidents - compromised VPN/jumphost as IT-OT pivot
of organizations invest in segmentation (SANS 2025)
avg ransomware dwell time in OT (vs 5 days with visibility)
Source: Dragos 2026 OT Cybersecurity Year in Review, SANS State of ICS/OT Security 2025
The Problem and the Framework
Why Segmentation Is Critical
Traditional OT environments were built as isolated networks. That isolation no longer exists - SCADA systems connect to the cloud, engineers remotely service PLCs, production data flows into ERP systems. Without segmentation, an attacker who gains access to one network segment can move laterally until reaching a PLC controlling a physical process.
Lessons from Incidents
Five incidents from recent years illustrate different scenarios where a lack of segmentation enabled or deepened an attack. Each carries a concrete lesson for zone and conduit architecture design.
| Incident | Year | What Happened | Segmentation Lesson |
|---|---|---|---|
| Colonial Pipeline | 2021 | IT ransomware - operator shut down pipeline because they could not verify MES (billing) system integrity | OT dependency on IT business systems requires analysis and isolation |
| Oldsmar Water | 2021 | Remote access (TeamViewer) to HMI - attempted chemical concentration change in water supply | No segmentation between remote access and the control system |
| COSMICENERGY | 2023 | Malware interacting with RTUs via IEC 60870-5-104 - switch manipulation | OT protocols without authentication require network-level isolation |
| Volt Typhoon | 2024 | Chinese APT group pre-positioning in US critical infrastructure IT (techniques mapped in MITRE ATT&CK) | Lateral movement from IT to OT as a strategic objective |
| Polish Renewables Attack | 2025 | Coordinated attack on 30+ wind/solar farms, CHP plant (500k customers), manufacturing company. RTU firmware damaged, wiper malware, operator communications severed | Destructive (not financial) attack - OT device firmware damage requires physical separation and monitoring |
Sources: CISA Alert AA21-131A, FBI/CISA/EPA joint advisory, Mandiant Threat Research, CISA Advisory AA24-038A, CERT Polska “Energy sector incident” (January 2026).
Zones and Conduits - The IEC 62443 Model
The Purdue Model (ISA-95) defines the industrial network hierarchy (levels 0-5), but the rigid level-based division does not capture the complexity of modern OT environments. IEC 62443-3-2 introduces a more flexible approach:
- Zone - a group of assets with common security requirements
- Conduit - a controlled communication channel between zones
- Each zone receives a Security Level Target (SL-T) on a scale from SL 1 to SL 4
- Zone boundaries are derived from risk assessment - not imposed top-down
Segmentation Methods - Comparison
In practice, OT network segmentation relies on several methods, often used in combination. Physical separation and DMZ protect the IT/OT boundary, firewalls with DPI control inter-zone traffic, and VLANs with micro-segmentation complement protection within zones. Method selection depends on the zone’s target Security Level (SL-T) - the higher the SL, the stronger the mechanisms.
| Method | Description | When to Use | Limitations |
|---|---|---|---|
| Physical separation | Separate switches, cables, infrastructure | SIS, most critical systems | Increasingly difficult as data exchange needs grow |
| DMZ zone | Buffer with firewalls on both IT/OT sides | Always - every installation should have a DMZ | Requires maintaining intermediary servers |
| VLANs with ACLs | Logical network division on switches | Basic segmentation within zones | Vulnerable to VLAN hopping, insufficient alone |
| Firewalls with DPI | Deep inspection of OT protocols (Modbus, OPC UA) | Boundaries between IEC 62443 zones | Requires OT protocol expertise |
| Data diodes | Hardware-enforced unidirectional data flow | Telemetry export from OT to IT | No return communication - not suitable for all scenarios |
| Micro-segmentation | Granular per-device policies (Zero Trust) | Supplement to zone-based segmentation | Early-stage adoption in OT environments |
OT Network Protocols - What to Know for Segmentation
Below are protocols that traverse Ethernet/IP networks and can be controlled by firewalls, ACLs, and DPI systems. Serial protocols (Modbus RTU, PROFIBUS, HART 4-20mA, CANbus) are not included here - they operate below the network layer and require physical protection, not network segmentation.
Control and SCADA communication protocols:
| Protocol | Port | Auth. | Encr. | Application | Segmentation Notes |
|---|---|---|---|---|---|
| Modbus TCP | 502 | None | None | PLC, RTU, SCADA | Filter by function code on DPI firewall |
| OPC UA | 4840 | X.509 cert. | TLS | System integration | Best secured - enforce signed+encrypted mode |
| OPC Classic (DA) | 135+ | Weak (DCOM) | None | Legacy SCADA systems | DCOM requires many ports - difficult to firewall |
| DNP3/TCP | 20000 | Optional (SA v5) | Optional | Energy, water utilities | SA v5 adds HMAC - many deployments without SA |
| IEC 60870-5-104 | 2404 | None | None | Power grid | Targeted by COSMICENERGY and Industroyer - isolate or DPI |
| S7comm | 102 | None | None | Siemens controllers | Exploited by Stuxnet. S7comm-plus (v4+) adds integrity |
Industrial automation protocols (Ethernet):
| Protocol | Port / Layer | Auth. | Encr. | Application | Segmentation Notes |
|---|---|---|---|---|---|
| EtherNet/IP (CIP) | TCP 44818, UDP 2222 | None* | None* | Rockwell/Allen-Bradley | *CIP Security adds TLS/DTLS with X.509 |
| PROFINET | L2 (EtherType) | None | None | Siemens, factory automation | RT/IRT bypasses IP stack - requires L2-aware firewalls |
| EtherCAT | L2 (0x88A4) | None | None | Motion control, robotics | ”Processing on the fly” - compromising one slave threatens the entire network |
| IEC 61850 MMS | TCP 102 | None | None | Electrical substations | MMS over TCP - controllable by firewall |
| IEC 61850 GOOSE | L2 (0x88B8) | None | None | Electrical substations | L2 multicast without authentication - VLAN as only isolation |
Building management and IoT protocols:
| Protocol | Port | Auth. | Encr. | Application | Segmentation Notes |
|---|---|---|---|---|---|
| BACnet/IP | UDP 47808 | None* | None* | BMS, HVAC, access control | *BACnet Secure Connect (2019) adds TLS. Segment from process OT |
| MQTT | TCP 1883 / 8883 | Optional | TLS (port 8883) | IIoT, telemetry | Do not allow port 1883 in production - enforce TLS |
| CoAP | UDP 5683 | DTLS (opt.) | DTLS (opt.) | Resource-constrained IoT | Verify endpoints and proxy configuration |
Source: protocol specifications (modbus.org, opcfoundation.org, IEEE 1815), NIST SP 800-82 Rev. 3.
Segmentation Below the Network Layer - Fieldbus and Serial Protocols
IEC 62443 zones and conduits apply to all assets - not just networked ones. An RS-485 cable between a PLC and an RTU is a conduit under the standard, just like an Ethernet connection. The problem is that for fieldbus/serial protocols there are no equivalents of firewalls or ACLs. The only available mechanisms are physical protection and device hardening.
Serial/fieldbus protocols in the segmentation context:
| Protocol | Physical Layer | Auth. | Encr. | Protection Mechanism |
|---|---|---|---|---|
| Modbus RTU | RS-485 / RS-232 | None | None | Physical cable and cabinet protection. Control at serial-to-Ethernet gateway (converter as inspection point) |
| PROFIBUS DP/PA | RS-485 / MBP (IEC 61158-2) | None | None | Physical protection. Disable unused master ports. Controller-level segmentation |
| HART (4-20mA) | Analog current loop with FSK | None | None | Physical junction box protection. Restrict access to configuration handhelds |
| WirelessHART | IEEE 802.15.4 (2.4 GHz) | Yes (network keys) | AES-128 | Only fieldbus with built-in encryption. Manage join/session/network keys |
| FOUNDATION Fieldbus | H1: IEC 61158-2, HSE: Ethernet | None (H1) | None (H1) | H1: physical protection. HSE: segment as Ethernet |
| CANbus / CANopen | Differential bus (ISO 11898) | None | None | Every node sees all traffic. CAN gateways as segmentation point between domains |
| AS-Interface | 2-wire (data + power) | None | None | Simple sensor/actuator protocol. Physical protection is the only option |
What this means in practice:
- Physical protection is segmentation - for serial protocols, a locked control cabinet, access control to technical rooms, and seals on junction boxes serve the same role as a firewall on an Ethernet network
- Protocol gateways as control points - a Modbus RTU -> Modbus TCP converter or PROFIBUS -> PROFINET gateway is the only place where fieldbus traffic can be inspected and filtered
- Device hardening - disable unused communication ports on PLCs and controllers, lock programming mode, password-protect configuration
- WirelessHART as the exception - the only fieldbus protocol with built-in encryption (AES-128) and key management. However, wired protocols have a significant advantage over wireless: disrupting communication requires physical access to the cable, which significantly raises the bar for an attacker. Wireless protocols, even with encryption, are vulnerable to radio jamming
Consequence for zone architecture: IEC 62443 defines a target Security Level (SL-T) for each zone. SL 2 and above require authentication and access control - requirements that serial protocols (Modbus RTU, PROFIBUS, HART) cannot by definition meet. This means devices communicating exclusively over fieldbus should reside in an SL 1 zone (protection against casual violations), and the SL 2+ zone boundary should run at the PLC/RTU controller - which is the gateway between fieldbus and Ethernet and the only device capable of implementing authentication and access control.
How We Do It - The SEQRED Approach
SEQRED Documentation Example: Zone-to-Zone Flow Matrix
In segmentation projects we use a zone-to-zone flow matrix - a table defining permitted connections, protocols, and communication direction for each pair of zones. This is the key document that becomes the basis for firewall configuration.
Zone definitions:
| Zone | Description | Example Assets | SL-T |
|---|---|---|---|
| Z1 - Control | Controllers and field devices | PLC, RTU, sensors, actuators | SL 3 |
| Z2 - Supervisory | Visualization and engineering systems | HMI, engineering workstations, OPC server | SL 2 |
| Z3 - Operations | Production management | Historian, MES, reporting servers | SL 2 |
| Z4 - DMZ | IT/OT buffer zone | Jump host, data mirror, OPC gateway | SL 2 |
| Z5 - IT | Corporate network | ERP, email, Internet | SL 1 |
Flow matrix (source -> destination):
| Source \ Dest | Z1 Control | Z2 Supervisory | Z3 Operations | Z4 DMZ | Z5 IT |
|---|---|---|---|---|---|
| Z1 Control | - | Modbus TCP (read), OPC UA | Deny | Deny | Deny |
| Z2 Supervisory | Modbus TCP (r/w), OPC UA | - | OPC UA (read) | Deny | Deny |
| Z3 Operations | Deny | OPC UA (read) | - | SQL, HTTPS (to mirror) | Deny |
| Z4 DMZ | Deny | Deny | SQL (read) | - | HTTPS, SMTP |
| Z5 IT | Deny | Deny | Deny | HTTPS, RDP (jump host) | - |
Key principles:
- No direct access from IT to the control zone - traffic from Z5 to Z1 traverses three intermediate zones
- DMZ as the only contact point - Z4 is the only zone communicating with both OT (Z3) and IT (Z5)
- Read/write differentiation - an HMI operator (Z2) can write to PLCs (Z1), but the historian (Z3) can only read from Z2
- Default policy: deny all - only explicitly listed flows are permitted
SEQRED Documentation Example: Segmentation Method vs Security Level Matrix
After defining zones and assigning target Security Levels (SL-T), you need to select appropriate segmentation methods. The matrix below shows which methods are sufficient and which require supplementation depending on SL. We use this as a starting point for client discussions - the final selection follows from risk assessment of the specific installation.
| Segmentation Method | SL 1 | SL 2 | SL 3 | SL 4 |
|---|---|---|---|---|
| VLANs with ACLs | Sufficient | Supplement | Insufficient | Insufficient |
| Firewall with DPI | Excessive | Sufficient | Sufficient | Supplement |
| DMZ zone | Recommended | Required | Required | Required |
| Data diode | Optional | Optional | Recommended | Required |
| Physical separation | Optional | Optional | Recommended | Required |
Sources: IEC 62443-3-2:2020, CISA “Layering Network Security Through Segmentation” (2022), NIST SP 800-82 Rev. 3. Matrix is a SEQRED development.
NIST SP 800-53 Control Mapping to OT Segmentation
Below is a mapping of key controls from the NIST SP 800-53 Rev. 5 catalog to OT network segmentation methods:
| Control | Description | OT Application |
|---|---|---|
| SC-7 Boundary Protection | Communication control at interfaces | Firewalls at zone boundaries, DMZ |
| SC-7(5) Deny by Default | Default traffic blocking | Deny-all policy between zones |
| SC-7(21) Isolation of Components | Component isolation | SIS separation from the rest of OT |
| AC-4 Information Flow Enforcement | Authorized flow enforcement | DPI rules controlling OT commands |
| AC-4(7) One-way Flow | Hardware unidirectional flow | Data diodes (Waterfall, Owl) |
| SC-3 Security Function Isolation | Security function isolation | Separate zone for SIS |
| CA-3 Information Exchange | Information exchange management | IEC 62443 conduits |
Source: NIST SP 800-53 Rev. 5 “Security and Privacy Controls for Information Systems and Organizations.”
Implementation Process - Step by Step
- Asset inventory - passive asset discovery (Nozomi, Claroty) without active scanning
- Risk assessment and zone definition - grouping assets into zones, assigning SL-T
- Conduit definition - permitted protocols, direction, control mechanism. Default: deny all
- Incremental deployment - starting with the most critical zones (SIS), gradual expansion
- Monitoring and validation - verifying that traffic complies with zone policy
Legacy environment challenges: lack of authentication in older PLCs (e.g., Siemens S7-300), flat networks in 10+ year installations, downtime risk during topology changes, temporary vendor remote access that is never removed.
Segmentation Readiness Checklist
Before starting a segmentation project, verify organizational readiness across five areas corresponding to implementation stages. The table below serves as a progress tracking tool - the “Status” column allows marking which elements are already in place and which require work.
| Stage | Element | Status |
|---|---|---|
| 1. Inventory | Complete list of OT assets (PLCs, HMIs, engineering workstations, servers, network devices) | |
| Documentation of network connections and data flows | ||
| Identification of communication protocols (Modbus TCP, OPC UA, DNP3, EtherNet/IP, S7comm) | ||
| List of remote access connections (VPNs, vendor service tunnels) | ||
| Passive monitoring tool deployed for asset discovery | ||
| 2. Risk assessment and zone definition | Security zones defined (IEC 62443-3-2) | |
| Target Security Levels (SL-T) assigned to each zone | ||
| Conduits between zones identified | ||
| Impact assessment of losing access to each zone on production | ||
| 3. Conduit definition | Zone-to-zone flow matrix completed for all zone pairs | |
| Permitted protocols and communication direction defined per conduit | ||
| Default deny-all policy confirmed | ||
| Firewall and ACL rules prepared for deployment | ||
| 4. Incremental deployment | Maintenance windows agreed for implementing changes | |
| Rollback plan prepared | ||
| Operators informed and trained | ||
| Deployment order established - starting with most critical zones (SIS) | ||
| 5. Monitoring and validation | Passive monitoring verifying traffic compliance with zone policy | |
| Firewalls with OT protocol support deployed at zone boundaries | ||
| Centralized security event logging (SIEM or log collector) | ||
| Incident response procedures defined per zone |
Passive OT Network Monitoring Tools
Segmentation without monitoring is half the job - you cannot know whether network traffic complies with zone policy or whether unauthorized devices have appeared. Passive monitoring tools listen to traffic without interfering with production systems and provide asset inventory, anomaly detection, and vulnerability identification.
| Tool | Vendor | Key Features |
|---|---|---|
| Guardian / Vantage | Nozomi Networks | Passive monitoring, asset inventory, anomaly detection |
| CTD / xDome | Claroty | Asset visibility, vulnerability management, secure remote access |
| Platform | Dragos | Threat detection, ICS-specific threat intelligence |
| OT Security | Tenable (formerly Indegy) | Asset discovery, risk-based vulnerability management |
| Defender for IoT | Microsoft (formerly CyberX) | Agentless monitoring, Microsoft Sentinel integration |
Conclusion
OT network segmentation is not a one-time project - it is a continuous improvement process. The Purdue Model provides the vocabulary, IEC 62443-3-2 provides the method (zones and conduits), and passive monitoring tools provide visibility.
The key is a pragmatic approach: asset inventory, risk assessment, incremental deployment, and continuous monitoring. Every step toward segmentation reduces risk and gives security teams time for detection and response.
NOTE
Data from the Dragos 2026 OT Cybersecurity Year in Review confirms that organizations with full OT visibility detected and contained ransomware incidents in an average of 5 days - compared to the industry average of 42 days. Visibility and segmentation work together: without asset inventory you do not know what to segment, and without segmentation even good visibility will not stop an attacker’s lateral movement.
Sources
- IEC 62443-3-2:2020 - Security risk assessment for system design
- NIST SP 800-82 Rev. 3 - Guide to OT Security
- NIST SP 800-53 Rev. 5 - Security and Privacy Controls
- CISA “Layering Network Security Through Segmentation” (2022)
- Dragos 2026 OT Cybersecurity Year in Review
- SANS State of ICS/OT Security 2025
- CISA Advisory AA24-038A - Volt Typhoon
Need help in this area?
Our experts will help you assess the risk and plan next steps.