How to verify IT/OT segmentation in operational networks
(updated )
Almost no OT network starts out flat on purpose. It gets that way one connection at a time: a historian that has to feed a corporate reporting dashboard, a remote-access tool a vendor asked for during commissioning and nobody removed, an engineering workstation that’s easier to leave dual-homed than to lock down. Each connection made sense when it was made. Together they add up to a path from the corporate network into the control system that nobody approved as a single decision.
A firewall shows a boundary exists
Most operators can point to a firewall between IT and OT. That proves a boundary exists. It doesn’t prove the boundary matches the design, and the two lists, what the firewall allows and what actually has to cross, tend to drift apart once someone compares them. Verifying segmentation means making that comparison with evidence from the network itself.
A boundary that matches the design also protects the OT side from the IT side’s own tools. If the firewall only permits the defined paths, the corporate side’s routine vulnerability scans can’t reach a controller, even when someone sets a scan range too wide. The exception is a host a path does permit, such as a jump host: a scanner running from there still reaches OT. Passive vs. active vulnerability scanning in OT covers both sides of this: why that protection matters, and why protocol-aware probes carry less risk than a generic scan.
Purdue for the picture, zones and conduits for the design
The Purdue model is the diagram most OT conversations start from, and it’s good at the job it was built for. It gives everyone a shared way to say where a system sits. Originally coming from manufacturing integration rather than security, the model sorts systems by function. The Purdue model describes a network well, but it gives no concrete guidance on securing one.
IEC 62443 provides much of the guidance that the Purdue model lacks. Part 3-2 has you assess risk, divide the system into zones, and define the conduits between them. A zone is a group of assets with the same security requirements, and a conduit is a defined path between zones. Part 3-3 sets what the boundary has to do, with requirements for network segmentation (SR 5.1) and for monitoring and controlling communications at zone boundaries (SR 5.2). The Purdue levels make a reasonable first sketch of the zones, but a zone follows shared requirements, not a level number. Safety is the standard example. Part 3-2 requires safety-related assets to be separated from non-safety assets (ZCR 3.3), or the whole zone to be treated as safety related, so a safety system and a process controller can both sit at Level 1 and still be in different zones.
Figure 1. The same plant as Purdue levels and as zones. The Safety zone sits at the same levels as Control but is its own zone, because its requirements differ.
Pipeline operators will know the layout from API Standard 1164, which describes a DMZ between two firewalls. The corporate side connects to the DMZ, the OT side connects to the DMZ, and the two never connect to each other. Purdue diagrams label that DMZ Level 3.5, a level added later by security practice. Figure 2, further down, shows this layout with the three checks applied.
Purdue is the way to explain a network to someone. Design and test against zones and conduits. The rest of this post covers testing a design built that way.
Where the gap usually shows up
The historian is a common finding, and I’ve seen both versions of it in operating networks. It sits on the OT network because that’s where the data originates, and its data has to reach corporate reporting because that’s where the reports are read. Built correctly, that’s a narrow conduit: the historian feeds a replica in the DMZ that corporate reporting reads, and connections start only from the OT side. Built under time pressure, it’s a dual-homed server with broader access than the export needs, because that was faster than defining the narrow path and testing it.
Vendor remote access is another. A jump host from a commissioning project or an always-on VPN installed so a vendor could support their equipment both do what they were built to do. The gap opens when the access outlives or outgrows its original justification, which is how a conduit stops matching the design without anyone deciding it should. The access side of this is covered in access control for local and remote critical cyber systems.
Checking the design against the network
A well-structured review starts with an asset inventory and a data flow map, not the network diagram someone drew when the system was built. The diagram shows intent, and the traffic shows what’s happening. After a few years of vendor visits and one-off exceptions they rarely match. The base review is three passive checks, all using evidence that doesn’t put the control system at risk.
The first check compares firewall rules with the conduits. Every rule at the IT/OT boundary and between OT zones gets measured against the conduits the design defines. Anything broader than its conduit needs gets flagged: an “any” port where one protocol would do, or a source range covering a whole subnet when a single historian is the only host that has to get through.
The second is passive capture at the conduits. It shows what actually crosses each boundary, including flows nobody documented and connections that only appear during a shift change or a vendor visit. The capture window has to span a full operating cycle, including maintenance windows and month-end, or those flows won’t show up. Adding a SPAN port or tap is itself a change on an OT switch and goes through change control.
The third looks for paths around the firewalls. A dual-homed workstation, a cellular modem or radio at a remote site, a vendor’s always-on connection, or a route added during an outage and never taken back out will all bypass the rules the first check just reviewed. Passive evidence finds them in host network configs and route tables, in switch MAC and ARP tables, and in the same host appearing on both sides of a capture.
Figure 2. The three checks on a network with a DMZ between two firewalls. Check 3 finds the paths the first two can’t.
The assessment produces a prioritized gap list, not a single pass or fail. Some gaps are a configuration change and others are a project.
When passive evidence isn’t enough
Operators who want proof that a block really blocks can add a separate, optional step, a protocol-compliant probe. It sends a read-only request in the device’s own protocol, such as a Modbus read, from the corporate side toward a conduit and records whether the boundary drops it. That confirms a rule works in a way the three passive checks can’t. They show what is permitted and what has been seen. None shows what happens when something new tries to cross. A probe on the OT network also reaches what passive capture can miss. It finds quiet devices that sent no traffic during the capture window. Where the protocol defines an identification request, as Modbus does, it returns software or firmware revisions that never crossed the wire, and those can be matched against known vulnerabilities.
The probe carries a risk the passive checks don’t: if the boundary is open, it reaches a live controller. A probe is reasonable only with offline testing first, requests defined in advance, a target the operator has chosen, and approval through change control. Where possible, aim the first test at a listener host the operator places in the OT zone instead of a live controller. The firewall’s policy-match or packet-trace tool can also confirm a rule without sending any traffic. In an engagement, the base assessment stays passive, and a probe like this is scoped as a separate step, up front or added later.
Where the TSA pipeline directives require it
For pipeline operators under TSA’s directives, this is also a compliance task. SD Pipeline-2021-02G (Section III.G.2.b) requires the Cybersecurity Assessment Plan for Critical Cyber Systems to include a cybersecurity architecture design review at least once every two years, including verification and validation of network traffic and system log review and analysis to identify vulnerabilities in network design, configuration and interconnectivity to internal and external systems. A segmentation review covers the network design and interconnectivity part of that requirement and produces evidence for it. The log review and vulnerability analysis the requirement also names are part of the same assessment. The TSA pipeline cybersecurity requirements guide covers the wider requirement set.
Designing from scratch, or checking someone else’s design
Some operators are planning a segmentation project and want a target zone-and-conduit architecture and a rollout order. Others already have an integrator’s proposed design and want an independent check before they build it, from someone who isn’t also bidding on the build. Both come down to the same question, answered against the network as it operates.
For a target architecture laid out end to end, see the IT/OT segmentation reference architecture. For what a review looks like as an engagement, see IT/OT segmentation design and review. It usually sits inside the broader ICS and OT security assessment.
Sources: ANSI/ISA-62443-3-2-2020 (security risk assessment and system design, ZCR 3.1 to 3.3) and ANSI/ISA-62443-3-3-2013 (system security requirements and security levels, SR 5.1 and SR 5.2), available from ISA. API Standard 1164. TSA Security Directive Pipeline-2021-02G, Sections III.G.2.b and VII.D. Directive and standards references last checked against the signed directive and the standards text on 2026-11-10.