Zones and Conduits: The Core Idea Behind IEC 62443
If you take only one idea from IEC 62443, make it zones and conduits. It is the concept that turns a sprawling control network into something you can reason about, protect and defend. Almost every other part of the standard, from security levels to technical requirements, is applied through it.
The definitions
IEC 62443-3-2, the part of the series that covers security risk assessment, builds everything around two terms.
A zone is a grouping of logical or physical assets that share common security requirements. Assets are grouped based on risk and on criteria such as criticality, operational function, physical or logical location, required access and the organization responsible for them.
A conduit is a logical grouping of communication channels that connect two or more zones and share common security requirements. In plain terms, a conduit is a controlled path that data is allowed to travel between zones.
Each zone and each conduit gets a target security level, and the protections around it are chosen to meet that target. Everything inside a zone is trusted to roughly the same degree. Everything crossing a zone boundary must go through a conduit, where it can be inspected, filtered and logged.
Why the model works
Control networks were traditionally built for reliability and convenience, which often meant one large, flat network where anything could talk to anything. That makes life easy for an attacker: compromise one maintenance laptop or one remote access account and every controller is within reach.
Zones and conduits reverse that. They limit how far a problem can spread, they make it clear which traffic is legitimate, and they let you spend more on protecting the parts of the plant where the consequences are highest. They also give operations, IT and vendors a shared picture to discuss, which is often as valuable as the technical controls themselves.
How to group assets into zones
There is no single correct zone model, but good ones tend to follow the same logic.
Start with function. Group assets that work together to perform a process, such as a compressor station's control system or a water plant's filtration line.
Weigh criticality. Separate assets whose compromise would have very different consequences. Safety systems should never share a zone with business-facing systems.
Respect location. Assets at a remote site and assets in a central control room usually belong in different zones, even if they perform related functions.
Consider access and ownership. Systems maintained by a particular vendor, or accessed by a specific group of people, are often easier to manage as their own zone.
Keep it manageable. Enough zones to contain risk, but not so many that nobody can maintain the rules. Most facilities end up with somewhere between a handful and a few dozen.
Example zones and conduits
A typical industrial site might lay out its zones like this:
Safety instrumented system (SIS) zone. Safety controllers and their programming workstation, with tightly restricted connections and the highest target security level on site.
Basic process control zone. Controllers, HMIs and I/O for the main process. Often split further by process area or unit.
Supervisory zone. SCADA servers, historians collecting from the plant floor and operator workstations.
Industrial DMZ. A buffer between OT and the corporate network that holds replicated historians, patch servers, jump hosts and file transfer services. Nothing should pass directly from corporate to control; everything stops in the DMZ first.
Enterprise zone. Corporate IT, which is outside the OT security boundary but connected through the DMZ.
And the conduits between them:
A plant-to-DMZ conduit carrying historian replication and patch distribution, filtered to specific hosts, ports and directions.
A remote access conduit that brings vendor and staff connections into the DMZ through multifactor authentication, with session approval, recording and time limits before anyone reaches a control zone.
A control-to-SIS conduit limited to the minimum read-only data the process control system genuinely needs.
Common mistakes
Most problems we see are not exotic. They are the same few patterns repeated.
Flat networks. Everything on one subnet or one VLAN with no filtering between levels. Zones exist on a drawing but not on the wire.
One giant zone. Segmenting OT from IT, then treating the entire OT environment as a single trusted zone. A compromise anywhere still reaches everything.
Undocumented conduits. Firewall rules added over the years for a project or a vendor, with nobody sure what they are for. Every conduit should have a stated purpose, an owner and a review date.
Forgotten paths. Wireless links, cellular modems on remote sites, vendor-supplied routers, dual-homed workstations and USB media all create conduits whether or not you planned for them. If data can move between zones, it is a conduit and it needs controls.
Rules that only go one way on paper. A conduit intended to be outbound-only from OT, but configured to allow return sessions initiated from the corporate side.
No verification. Zone models that are never checked against actual traffic. Passive monitoring frequently reveals communications nobody knew existed.
Getting started
Begin with an accurate picture of what is on the network and what is talking to what. Draw your current state honestly, including the messy parts. Then propose a target zone model for your most critical system, define the conduits it needs, and compare the two. The gap between them is your segmentation roadmap, and it can usually be closed in stages without major downtime.
How QBits Networks can help
Our network segmentation reviews compare your actual traffic and firewall rules against a practical zone and conduit model, and identify the paths that matter most. An OT visibility snapshot, captured passively from a SPAN or mirror port, is often the fastest way to find the conduits nobody documented. Tell us what you need through our contact page and we'll scope it with you.