Ask an OT team about network security and you usually get a product answer — a firewall model, a diode, a monitoring appliance. IEC 62443-3-2 asks a different question first, and the products only make sense once it is answered: which assets belong together, and what is allowed to cross between the groups?
Two definitions that carry the method
- A zone is a grouping of assets that share security requirements. It carries its own target security level. It can be physical or logical.
- A conduit is the logical grouping of communication channels between zones. It crosses zone boundaries and carries its own target security level. The firewall or gateway between a control zone and a DMZ is that conduit’s enforcement point.
The consequence people miss: a conduit is a first-class object with its own requirements. “Both zones are SL 2” says nothing about the link between them, and the link is what an attacker traverses.
The separation rules that do the work
Partitioning is not freehand. The standard is specific about what must be broken out into its own zone, and each rule reflects a class of incident:
- Business and IACS assets separated. The single most common finding, and the route by which office compromises reach production.
- Safety-related assets separated. A safety instrumented system sharing a broadcast domain with process control is a design decision nobody would defend once it is written down plainly.
- Temporarily connected devices separated. Engineering laptops and contractor machines — the assets that leave, connect elsewhere, and return.
- Wireless devices separated. The medium changes who can reach the network without physical access.
- Devices reached over external networks separated. Remote support access is the classic case, and it deserves its own zone rather than a hole in someone else’s.
Run those five over an existing plant drawing and the honest zone map usually appears within an afternoon — along with two or three connections nobody could justify out loud.
The workflow, briefly
3-2 is a defined sequence: identify the system under consideration and its perimeter; run an initial high-level risk assessment to gauge worst-case unmitigated risk; partition into zones and conduits using the separation rules; compare that initial risk against your tolerable risk to decide where detail is needed; run the detailed per-zone assessment, where SL-T is assigned; document everything in the Cyber Security Requirements Specification; and have the asset owner approve it.
The step teams skip is the tolerable-risk comparison. Without a stated tolerance, every zone looks like it needs the highest level, the programme becomes unaffordable, and it stalls. Tolerance is a business decision, and it belongs to someone with the authority to make it.
What good looks like on the drawing
- Every asset is in exactly one zone. Anything unassigned is either out of scope with a reason, or a gap.
- Every crossing is a named conduit with its own SL-T and a stated enforcement point.
- Remote access terminates in a DMZ, not in the control zone.
- The drawing matches the cabling. An architecture that is true on paper and false in the cabinet is worse than none, because it is trusted.
Why this beats buying a product first
Most OT protocols have no authentication by design — a well-formed command is obeyed whatever sent it. If the protocol cannot distinguish friend from foe, the network must, and that is a partitioning problem before it is a purchasing one. Segmentation is also usually faster and safer than patching the device: reducing what can reach a vulnerable controller does not require a production outage.
We run the 3-2 workflow with plant teams and produce the zone map, the conduit inventory and the requirements specification that comes out of it — without touching the live process. If your current architecture diagram is older than your last expansion, that is the place to start.