OT network segmentation, step by step

OT network segmentation splits an industrial network into zones, so that a problem in one part (malware on an office laptop, a misconfigured vendor laptop, a compromised remote session) cannot reach the controllers that run the process. The firewall rules between those zones are where the design becomes real: a zone is only as separate as the rules on its boundary allow.

This guide is the starting point. It walks through segmentation from the asset list to the rules, and links to the deeper guides on the Purdue model, IEC 62443 zones and conduits, NIST SP 800-82r3, the industrial DMZ, industrial protocols in firewall rules, flat OT networks, east-west segmentation inside OT, the firewall rule audit, proving segmentation to an auditor or insurer and firewall change plans with rollback.

How OT segmentation differs from IT segmentation

The idea is the same as in IT: group what belongs together and allow only the traffic each boundary needs. Four things change in OT.

• Availability comes first. A blocked flow can stop a production line or trip a safety function. Rules are changed in planned windows, with a rollback ready, never by trial and error.
• Many industrial protocols have no authentication. Classic Modbus/TCP, EtherNet/IP and S7comm accept commands from any host that can reach the port. The boundary often is the only control in the path.
• Devices stay in service for decades. Controllers and HMIs often cannot be patched quickly, scanned aggressively, or given an agent. Segmentation protects what cannot protect itself.
• The traffic is predictable. A cell talks to the same few hosts on the same few protocols every day. That makes tight rules possible, and makes a new path stand out.

Step 1: know what is on the network

Segmentation starts with an inventory: which hosts exist, what each one does, and which zone it belongs to. The firewall traffic log is a good source, because it shows each host’s role from what it actually does: a host that answers EtherNet/IP on port 44818 is likely a controller or an I/O adapter, and a host that polls many controllers is usually an HMI, a SCADA server or a historian.

NIST CSF 2.0 asks for this as ID.AM-01 (“Inventories of hardware managed by the organization are maintained”), and IEC 62443-3-3 as SR 7.8, control system component inventory.

Step 2: draw the zones

A zone is a group of assets that share the same security requirements. Most sites draw zones along Purdue model levels: business (L4), the industrial DMZ (L3.5), operations (L3), supervisory (L2), basic control (L1) and the process (L0). The Purdue model is a reference, not a requirement, and IEC 62443 does not depend on it, but it gives everyone the same words for where a zone sits.

Inside OT, split further where the risk differs: one zone per production cell or line is common, so a problem in one cell stays in that cell. The IEC 62443 guide covers how IEC 62443-3-2 asks the asset owner to partition the system and set a target security level for each zone.

Step 3: define the conduits

A conduit is the set of communication channels between two zones. For each pair of zones that must talk, write down the flows the process needs: which hosts, which protocols, which direction. Everything else on that boundary is denied.

NIST CSF 2.0 calls this map ID.AM-03 (“Representations of the organization’s authorized network communication and internal and external network data flows are maintained”). A traffic log from a normal production week is the most reliable way to build it, because it shows the flows that actually run, including the ones nobody remembered.

Step 4: write the firewall rules

Turn each conduit into rules. NIST SP 800-82r3 (section 5.2.3.1) gives the baseline for a Purdue-based design:

• Firewall rulesets “should be established to only permit connections between adjacent levels, tiers, or zones.”
• Rules and connection paths should “prevent Level 4 devices from directly communicating with Level 2, 1, or 0 devices.”
• Organizations “should consider making outbound rules as stringent as inbound rules.”

In practice that means:

1. Put an industrial DMZ between IT and OT. Every session from the business side ends on a service in the IDMZ, and a separate session runs from that service into OT. See the IDMZ guide.
2. Name the hosts and the applications. A rule names its source and destination hosts and the protocols the conduit needs. A rule that allows any application, or any host, allows more than the conduit needs; see any-any firewall rules.
3. Keep industrial protocols inside OT. Modbus, EtherNet/IP, S7 and similar protocols belong on the conduits between control, supervisory and operations zones, never on a path from the business network or the internet. See industrial protocols in firewall rules.
4. End remote access on a jump host. Remote users and vendors land on a jump host in the IDMZ, and the jump host reaches only Level 3 hosts, on named applications such as RDP or SSH.
5. End each rule set with a logged deny. Deny by default, with logging on, so the next review can see what tried to cross.

New rules between cells inside OT are safest added with logging first and enforcement later, once the log shows the conduit carries only the flows written down in step 3.

Step 5: monitor and verify

Segmentation drifts. Temporary rules stay, vendors get new paths, and a rule added for one host ends up allowing a whole subnet. Keep traffic logging on at each zone boundary and review the rules against the log on a schedule and after every change.

NIST CSF 2.0 covers this as PR.PS-04 (“Log records are generated and made available for continuous monitoring”) and DE.CM-01 (“Networks and network services are monitored to find potentially adverse events”). IEC 62443-3-3 covers it as SR 6.2, continuous monitoring.

What the frameworks ask of segmentation

Framework	What it asks	Where to read more
IEC 62443-3-2	Partition the system into zones and conduits and set a target security level for each	IEC 62443 guide
IEC 62443-3-3	SR 5.1 network segmentation, SR 5.2 zone boundary protection	IEC 62443 guide
NIST SP 800-82r3	Adjacent-level rules, a DMZ between enterprise and operations, controlled remote access	NIST SP 800-82r3 guide
NIST CSF 2.0	PR.IR-01: “Networks and environments are protected from unauthorized logical access and usage”	This page
Purdue model	A reference for where zones sit; not a requirement	Purdue model guide

A segmented network supports these requirements; it does not certify against any of them. Most also ask for process and documentation evidence that no firewall can show.

How SegAudit reports segmentation

SegAudit reads the firewall rules and the traffic log you collected and reports the paths that cross the zone design: IT reaching straight into OT, internet or VPN sessions landing on control networks, skip-level conduits inside OT, OT calling out, and rules that allow everything. Each finding names the sessions, hosts and allowing rule behind it, and the controls it relates to.

The compliance crosswalk then shows, for each framework the client answers to, which controls the firewall evidence supports, which are partial and which are gaps, and what the change package would close. In the Northline sample (a made-up three-site company that ships with SegAudit), the crosswalk shows 7 gaps of 10 against NIST CSF 2.0 and 7 gaps of 9 against IEC 62443-3-3.

To see what SegAudit catches in one of your own exports, run the free Quick check.

Common questions

Is a VLAN per level enough?

A VLAN separates broadcast traffic, but traffic between VLANs is only controlled where something filters it. If the VLANs are routed by a switch with no access lists, every level can reach every other. The boundary needs a firewall or filtering that enforces the conduit.

Do I need a firewall between every pair of levels?

Not necessarily a separate box, but every boundary needs rules. One firewall with several zones can enforce several boundaries, as long as each pair of zones has its own rules and nothing allows traffic between them by default. Many sites run the IT/OT boundary and the cell boundaries on separate firewalls, so one rule change cannot open both.

Where should I start on an existing flat network?

With the inventory and a traffic log; the flat network guide covers what the firewall can and cannot see there. Put the IDMZ between IT and OT first, because that boundary blocks the most common attack path, then split OT into cells one at a time, starting with logging-only rules.

Does segmentation replace patching and monitoring?

No. Segmentation limits how far a problem can spread once it starts. Monitoring tells you when something tries to cross a boundary it should not, and patching closes the weaknesses that segmentation only contains. Most programs need all three, and the firewall rules are the part a configuration review can check.