IEC 62443 Zones and Conduits Explained: A Practical OT Segmentation Guide

01Key takeaways

1. 01

   IEC 62443 is the ISA/IEC series for industrial automation and control system security.

2. 02

   A zone groups assets with shared security requirements; a conduit is the defined connection between zones.

3. 03

   Security levels express the strength of protection a zone or conduit is required to provide.

4. 04

   Designing well means mapping real data flows to conduits, then choosing controls that fit each conduit.

5. 05

   Firewalls, data diodes and disconnection are complementary tools for enforcing different kinds of conduit.

02What IEC 62443 is

IEC 62443, developed with ISA, is a series of standards addressing the security of industrial automation and control systems. It spans people, process and technology, covering everything from program management to technical requirements for systems and components.

For network architecture, its most influential contribution is the zone-and-conduit model, which gives teams a structured way to reason about segmentation instead of treating an OT network as one flat space.

The core idea: group assets into zones by security need, and allow them to communicate only through defined conduits.

03Zones and conduits defined

Zone

A grouping of assets that share common security requirements, based on function, risk and consequence. Everything in a zone is treated at a similar trust level.

Conduit

A defined communication path between zones. All traffic crossing a zone boundary should pass through a conduit, where it can be controlled.

Trust boundary

The edge of a zone, where the difference in trust between two zones is enforced by the controls on the conduit.

The discipline the model imposes is that there should be no unmanaged crossing between zones. If traffic moves between zones, it does so through a conduit you have deliberately designed.

04Security levels and what they mean

IEC 62443 uses security levels to express how strong protection needs to be. Rather than a vague sense of importance, a zone or conduit is assigned a target security level based on the threat it must resist.

The levels scale from protection against casual or accidental exposure up to protection against sophisticated, well-resourced and determined attackers. A target security level for a zone drives the requirements for the conduits that touch it: a high-consequence zone justifies stronger conduit controls.

The practical use is comparison. By assigning target levels, a team can see where the current design falls short and prioritize the conduits that protect the most consequential zones.

05Mapping data flows to conduits

Good segmentation starts from real data flows, not from a diagram of ideal networks. For each flow that crosses a zone boundary, the design should state what moves, in which direction, and why.

• Identify every flow that crosses a zone boundary and the business reason for it.
• State the required direction: two-way exchange, or publication in one direction only.
• Assign the conduit a requirement based on the target security level of the zones it connects.
• Remove flows that exist only out of habit; the best conduit is often the one you do not need.
• Document the conduit so its purpose and direction can be reviewed over time.

06Where firewalls, diodes and disconnection fit

Different conduits call for different controls. The model does not prescribe a single technology; it asks you to enforce each conduit appropriately for the flow and the trust difference.

Firewall conduit

For governed two-way or directional traffic that needs policy, inspection and logging between zones.

Data diode conduit

For publication-only flows where a higher-trust zone sends data outward and no traffic should return through that path.

Disconnected-by-default conduit

For flows that are needed only intermittently, where the conduit is physically open only during approved windows.

For conduits that should be one-way or offline by default, an AIRGAPNET controlled connectivity pattern can be considered alongside firewalls and data diodes, so the control matches the conduit rather than forcing every boundary into the same mold.

07Common mistakes

• Drawing zones on paper but leaving unmanaged crossings in the real network.
• Treating every conduit as a firewall problem when some flows are one-way or intermittent.
• Assigning security levels once and never revisiting them as the system changes.
• Letting conduits accumulate flows over time until they no longer reflect the documented design.
• Forgetting that the conduit's controls have their own management planes to protect.

The model is only as good as the discipline behind it. Zones and conduits succeed when the documented design and the running network stay the same thing.

08Closing thought

Zones and conduits give OT teams a shared language for segmentation: group by trust, connect through defined paths, and size the controls to the consequence. It turns an abstract goal into a concrete, reviewable design.

Start from the flows, assign honest security levels, and choose the control that fits each conduit. The result is an architecture you can explain, defend and prove.

FAQFrequently asked questions

SRCSources of record