Five zone-partitioning mistakes we keep seeing (and what IEC 62443-3-2 actually asks)
Zone and conduit partitioning is where most IEC 62443-3-2 assessments quietly go off course. Not because teams misread the standard, but because the drawing gets made before the risk is understood.
We review a lot of zone and conduit diagrams. The same five mistakes come back, and each one is fixable with a small change in where you draw the line and when. Here they are, each paired with the ZCR step in IEC 62443-3-2 that catches it.
Mistake 1: drawing zones around the network, not the risk
The fastest route to a wrong partition is to trace the VLANs and call each one a zone. Topology is convenient because it is already documented, but it answers the wrong question. The standard asks you to group assets by shared security requirements: what a compromise would cost, and how strong an attacker the group has to withstand. Two devices on the same switch can belong in different zones; two devices in different buildings can belong in the same one.
The remedy. Do ZCR 1 and ZCR 2 before you draw anything. Fix the System under Consideration, run the initial risk assessment, and only then partition in ZCR 3. Let the required security level decide the boundary, not the patch panel.
Group assets by what a compromise would cost, not by what shares a switch.
Mistake 2: keeping the safety system in the control zone
The safety instrumented system and the basic process control system share cabinets, cabling and sometimes a supplier, so they end up in one zone. They should not be. The SIS is the last line before a physical consequence, and it usually needs a higher target security level than the BPCS around it. Folding it in drags the whole zone up to the SIS target, or worse, leaves the SIS sitting at the BPCS target.
The remedy. Give the SIS its own zone with its own SL-T, and treat every path into it as a conduit. This is where IEC 62443 and the functional-safety world of IEC 61511 agree: independence is the point, and the security case should not undo it.
Mistake 3: leaving temporary and vendor paths off the map
The permanent architecture is documented; the temporary one is not. A maintenance laptop, a vendor's remote-access jump host, a cellular router installed for one commissioning weekend and never removed. None of these appear on the zone drawing, so none of them get requirements. An attacker does not care that a connection was meant to be temporary.
The remedy. In ZCR 1, scope the connections, not just the assets. Every remote-access and maintenance path is a conduit in ZCR 3, with requirements of its own, whether it is live for an hour a year or always on.
This is the kind of bookkeeping that spreadsheets lose. In OTRISK the zones, conduits and their target levels live in one model, so a forgotten vendor conduit reads as a gap you can see, rather than a row that quietly got deleted. The point is not the tool, though; it is that the temporary path has to exist on the drawing before it can carry a requirement.
Mistake 4: treating wireless like another cable
A wireless link between two zones often gets drawn as if it were copper: a plain line between two boxes. It is not. Its boundary is physical space, not a connector, and its threat surface includes anyone within range. Rolling it into a wired conduit hides that difference and understates the requirements that should sit on it.
The remedy. Make wireless its own conduit in ZCR 3 and set its requirements against its own threats. The detailed assessment in ZCR 5 should reflect that a wireless conduit and a fibre conduit do not carry the same risk at the same nominal security level.
Mistake 5: naming zones but never their conduits
The diagram has neat zones and clean lines between them, and the lines are never specified. A conduit is where traffic crosses a trust boundary, which makes it the most interesting part of the whole picture. A zone boundary that no conduit enforces is a label, not a control.
The remedy. Treat every line on the drawing as a conduit with a target security level and a set of requirements of its own, defined in ZCR 3 and carried into the detailed assessment in ZCR 5. If you cannot say what a conduit allows, blocks and logs, the partition is not finished.
The pattern behind all five
None of these five need a tool to fix. They need the partition to come after the risk work, and every line on the drawing to mean something. Group by consequence, keep the safety case independent, put the temporary paths on the map, respect what wireless is, and specify the conduits. The standard already asks for all of it. The work is in doing ZCR 1 through ZCR 3 in that order, and letting ZCR 5 do the arithmetic on the target levels.
The ZCR steps referenced here are defined in IEC 62443-3-2. Access the standard through your own licensed copy for the exact requirement text.
ISA-certified IEC 62443 trainer and subject-matter expert; CISSP and CISM. Member of NEC 65 and IEC TC65 WG10, the committees where IEC 62443 is written, after 25+ years in software architecture and OT security.
Keep reading
The Cyberbeveiligingswet countdown.
Cbw and Wwke take effect on 15 August 2026. The three duties, who is accountable, and what to have ready.
Read the field note → Incident analysisThe Polish CHP breach ran on connections nobody drew.
Mistake three at operator scale: an exposed VPN, an open APN and default passwords stopped a plant that heats 50,000 homes.
Read the field note →From standard to signed-off.
Bring one installation in mind. In thirty minutes we show you which parts of OTRISK fit your situation and how the way of working looks. You leave with concrete next steps and pricing.
Thirty minutes with an OT security expert, no slideware, no SDR relay.