Official intent
Strictly segment OT networks so a business-network compromise cannot reach production. The official source remains authoritative.
Read the official campaign ↗Why it matters
Most OT incidents start in IT and cross a flat connection into production. A hard, well-defined boundary is what stops that pivot — and what keeps ransomware on the business side from halting operations. Zoning also limits how far any single OT compromise can spread once inside.
Introducing segmentation, firewalls, or new boundary rules can disrupt real-time OT traffic and safety functions. Design with the process owner, validate against production timing requirements, stage changes in maintenance windows, and keep a tested rollback. A control that improves security but risks a safety trip is not an improvement.
Minimum / Strong / Advanced
The OT network is separated from the business network, with a controlled, documented boundary between them.
An IT/OT DMZ brokers all cross-boundary traffic under default-deny, and OT is divided into zones with conduits between them.
Zones and conduits follow a recognized model (e.g., IEC 62443), cross-boundary traffic is monitored, and remote/vendor access lands only in controlled zones.
Implementation timeline
- Map every connection between the business and OT networks
- Flag any direct, unfiltered IT-to-OT paths
- Define OT zones and the boundary architecture with the process owner
- Close or broker the riskiest direct connections in a window
- Stand up or harden an IT/OT DMZ under default-deny
- Route vendor and remote access into controlled zones only
- Add zones/conduits within OT for critical lines
- Monitor and log all cross-boundary traffic
Implementation steps
- Map all connections between the business and OT networks, including forgotten and vendor links.
- Define zones (by line, cell, or criticality) and the conduits allowed between them, with the process owner.
- Establish a controlled IT/OT boundary — ideally a DMZ — that brokers all cross-boundary traffic under default-deny.
- Direct remote and vendor access into controlled zones rather than straight onto the OT network.
- Monitor and log traffic crossing the boundary and between zones so unexpected flows are visible.
Validation
- From a business-network host, attempt to reach an OT controller directly — it must be blocked.
- Confirm no undocumented direct path bypasses the IT/OT boundary.
- Verify vendor/remote access terminates in a controlled zone, not the production network.
Evidence to retain
OT segmentation architecture and zone/conduit policy
Boundary/DMZ and firewall rule exports enforcing default-deny
Logs of cross-boundary traffic and investigated anomalies
Segmentation test results showing blocked IT-to-OT access
Common failure modes
A firewall between IT and OT with an any-any rule, a forgotten engineering laptop bridging both networks, and vendor access that lands directly on the plant floor. A boundary with a hole in it is not segmentation.
Framework mappings
Independent mappings are aids, not authoritative equivalence or compliance determinations.