ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
If you are trying to work out where to start with industrial cybersecurity, IEC 62443 zones and conduits is the concept that has to land first, because almost every other requirement in the standard resolves back to it. Get the partitioning right and the rest of the programme has a spine. Get it wrong and you end up with a diagram that renames your existing flat network and protects nothing.
This guide covers what a zone actually is, how a conduit differs from a network link, how to draw the boundaries, and the eight questions that expose a weak model before an assessor does.
A zone is a grouping of assets that share common security requirements. A conduit is a grouping of the communications between zones, and it is the only permitted route from one zone to another.
The definition matters more than it looks. A zone is not defined by network topology, by vendor, or by which room the cabinet sits in. Those often coincide with security requirements, and when they do, life is easy. When they do not, security requirements win.
The partitioning methodology itself lives in IEC 62443-3-2, which covers defining the system under consideration, partitioning it into zones and conduits, assessing risk and establishing target security levels. This is worth knowing because IEC 62443-2-1, the asset owner standard, states plainly that it does not define this methodology — it points you at 3-2.
Grouping assets into zones achieves nothing on its own. It is a labelling exercise until the traffic between those zones is constrained to defined conduits and controlled at that boundary.
This is the single most common failure. Plants draw a beautiful zone diagram, implement none of the conduit enforcement, and believe they have segmentation. Anything that is not a defined conduit should be denied, and anything discovered later that does not correspond to a conduit is an anomaly to investigate, not a conduit to quietly add.
Edition 2.0 of IEC 62443-2-1, published in August 2024, is specific here. Its requirement NET 1.2 asks for a maintained baseline of all IACS zones and network zone interconnections or conduits, the security risks associated with each, and their designation as trusted or untrusted.
That is three things, not one. A register listing your zones satisfies a third of the requirement. Most registers in the field stop there.
The trusted/untrusted designation is not decoration either. It is what tells you where access controls are needed, and untrusted interconnections are expected to carry a higher degree of protection.
The sequence for drawing IEC 62443 zones and conduits matters, and running it out of order is why so many models have no defensible basis.
That second point is worth dwelling on. Legacy equipment is a reason to draw a zone boundary, not a reason to give up. Putting unsupported equipment in its own tightly conduited zone is the standard compensating measure, and it is a far better answer than pretending the requirement does not apply.
Before you approve any set of IEC 62443 zones and conduits, run the draft against these. Each has caught a real defect in a real plant.
| Question | What a bad answer sounds like |
|---|---|
| If this zone is fully compromised, what is reachable? | “Everything” — or a safety function |
| Does any conduit let a lower-trust zone initiate inbound to a higher-trust one? | Yes, and it is not brokered |
| Can an essential function be lost through a single conduit failure? | Yes, with no fallback |
| Does any asset sit in two zones? | Yes — a dual-homed engineering workstation |
| Does any communication bypass a conduit? | Yes — wireless, a modem, or a serial link |
| Can operators still operate under this model during an upset? | No, or nobody asked them |
| Does emergency response still work? | Not tested |
| Is any zone so large it provides no containment? | A single zone holding levels 1 to 3 |
The last one is the commonest outcome of a first attempt: a model that renames the existing flat network as “the IACS zone”. If that is your honest starting position, record it as the current state and treat the target model as a roadmap item with compensating measures until it is delivered. That is a managed position. Quietly drawing the ideal diagram and filing it is not.
A register of IEC 62443 zones and conduits records what the model is. It cannot record why, and “why” is the first thing an assessor asks.
The commonest finding is not a missing zone model. It is a zone model nobody can explain, which is the same evidence problem that sinks audits across every framework — see our guide to NIS2 Directive compliance for how documentation is assessed in practice. For each zone, you want a short record of what is in it, which grouping criterion put those assets together, the consequence of its full compromise expressed in process terms, its assigned target security level and why, and what would cause it to be redrawn.
For each conduit, the important question is the one people skip: why does this communication need to exist at all? A material proportion of cross-zone traffic in a typical plant exists because it was easier than the alternative at the time. Eliminating a conduit is worth more than controlling one well.
Where the model requires a separation you have not implemented yet, record the separation, why it is deferred, the compensating measures in force meanwhile, the residual risk and the target date. A deferred separation with both a reason and a date is a plan. Without them it is simply a gap, and it will be found as one.
Once the model exists, it becomes the reference for most of the programme. Target security levels are assigned per zone and conduit rather than per plant, so IEC 62443 zones and conduits become the unit of measurement for the whole programme. Firewall rules should each map to a defined conduit — a rule with no conduit reference is unauthorised access nobody can justify, and that single check finds more stale permissions than any other review. Monitoring is placed at the boundaries of your IEC 62443 zones and conduits. Risk assessments are performed per zone.
If you are working toward NIS2 compliance, this is also the work that evidences the network security and segmentation measures in Article 21. Whether the Directive applies to you at all is covered in who NIS2 applies to. The relationship between the two is worth understanding properly, and our comparison of NIS2 and ISO 27001 covers where an information security management system does and does not reach into a plant.
No, and treating them as identical is a common mistake. Levels describe function; zones are defined by shared security requirements and derived from risk. They frequently cut across levels. Two correct outcomes a level-equals-zone approach would miss: a high-criticality area at level 1 placed in its own zone away from other level 1 equipment, and a safety system placed in its own zone regardless of which level it appears at.
There is no target number. Too few and you get no containment; too many and the conduit management becomes unworkable. The test is functional rather than numerical: if a full compromise of any single zone would reach an essential function or a safety system, you need another boundary.
Review it on any change to the system boundary, a plant modification, a new external connection, a new remote access requirement, a significant incident, a change in assessed threat, and at least annually. A change to the model also changes the target security levels and the risk assessment to that extent — re-run and re-approve them rather than amending the drawing alone.
Record it honestly as a deferred separation with compensating measures, a residual risk assessment and a date. Interim measures that genuinely help include access control lists at layer 3 boundaries, private VLANs, port security and disabling unused switch ports. What does not help is an approved diagram that describes a network you do not have.
The partitioning work produces a specific set of artefacts: a zone and conduit register carrying risks and trust designations, a design rationale report, a segmentation standard, and the cybersecurity requirements specification that carries the model into procurement and engineering.
Our IEC 62443 Toolkit includes all of them, along with the asset inventory and risk assessment templates the partitioning depends on — 117 editable documents covering all 87 requirements of IEC 62443-2-1:2024. If you would rather build them yourself, the list above is the set to build.
Either way, the order is the thing to get right. Inventory, boundary, risk, zones, conduits, security levels, rationale. Working IEC 62443 zones and conduits out in that sequence is what makes the model defensible when somebody asks you to explain it.
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026