If you have tried to read IEC 62443 directly, you know it is written in standards language: precise, thorough, and almost impenetrable on first read. Here is the zone-and-conduit model explained the way I explain it to engineers on their first day.

If you have tried to read IEC 62443-3-2 directly, you know the feeling. Precise. Thorough. Almost impenetrable on first read. Two days later you are still not sure whether you understand zones correctly, and whether conduits are different from firewalls, and whether your plant has them or not.

This is the zone-and-conduit model the way I explain it to engineers on their first day. No standards-speak.

Zones: groups of things that need the same level of protection

A zone is a grouping of assets, physical or logical, that share security requirements. That is it. If two PLCs need the same level of protection, same policies, same monitoring, same access controls, they belong in the same zone.

Examples in a typical process plant:

• Safety zone.Your SIS and any assets that interact with it. Highest protection.
• Control zone.Your DCS, PLCs, HMIs. Very high protection.
• Supervisory zone.Your SCADA servers, historians, engineering workstations.
• Site IT zone.The business systems local to the site.
• Enterprise zone.Corporate IT, the things in HQ.
• IDMZ zone.The broker zone that sits between OT and IT (see my article on the IDMZ).

How many zones you need depends on your plant. Small sites might have four. Large refineries might have fifteen. There is no magic number.

Conduits: the paths between zones

A conduit is the communication path between two zones, plus the security controls on that path. It is not just a firewall. It is not just a cable. It is the combination of physical media, protocol, traffic rules, monitoring, and the governance that maintains them.

If your control zone talks to your supervisory zone, that is one conduit. If your supervisory zone talks to the IDMZ, that is a different conduit. Each conduit has its own policy.

Security Levels (SL): the four flavours of “how much protection”

IEC 62443 defines four Security Levels:

• SL 1.Protection against casual or coincidental violation. Someone accidentally plugs the wrong cable in.
• SL 2.Protection against intentional violation using simple means with low resources and low motivation. A curious employee, a generic script kiddie.
• SL 3.Protection against intentional violation using sophisticated means with moderate resources and moderate motivation. Organised crime, targeted ransomware.
• SL 4.Protection against intentional violation using sophisticated means with extended resources and high motivation. Nation-state adversaries.

Each zone gets a target SL based on a risk assessment. Your safety zone in a chemical plant might target SL 3 or SL 4. Your site coffee-ordering system might target SL 1.

The conduit between two zones must support the higher of the two zones’ target SLs, usually the OT side’s target.

The Foundational Requirements (FR): what protection actually means

Every Security Level is defined across seven Foundational Requirements:

1. Identification and Authentication Control (IAC).Who is this?
2. Use Control (UC).Are they allowed to do this?
3. System Integrity (SI).Has the system been tampered with?
4. Data Confidentiality (DC).Is the data protected in motion and at rest?
5. Restricted Data Flow (RDF).Does data only flow where it should?
6. Timely Response to Events (TRE).Do we detect and respond quickly?
7. Resource Availability (RA).Can the system resist DoS and stay up?

At SL 1, each FR has a modest requirement. At SL 4, each FR has a heavy requirement: MFA, strong crypto, anomaly detection, tested incident response. Your target SL tells you how heavy each of these must be.

How to use this model in practice

Five steps to apply zone-and-conduit thinking to a real plant:

1. Inventory everything.You cannot draw zones until you know what you have.
2. Draw boundaries.Group assets by shared security requirements. Each group is a candidate zone. Adjust based on physical layout, network topology, and responsibility.
3. List the conduits.Every cross-zone communication path. Modbus from the control zone to the HMI zone? Conduit. Historian pulling data to the IDMZ? Conduit. Patch server pushing updates from IDMZ into OT? Conduit.
4. Do a risk assessment per zone.What are the threats, what are the consequences, what target SL does this zone need?
5. Specify controls per conduit.Given the target SLs of both sides, what authentication, encryption, traffic rules, monitoring, and response controls does this conduit need?

This becomes your Zone and Conduit Diagram, which is the single most useful document in a mature OT security program. Every firewall rule, every monitoring policy, every incident response scenario eventually refers back to it.

What this is not

• Not a replacement for the Purdue Model. Purdue is about how processes flow through layers. Zones and conduits are about how security is applied to those flows. Use both.
• Not a one-time exercise. Your zone diagram changes when you add a new system, when a new regulation changes your required SL, when a new threat actor emerges. Review annually.
• Not academic. Every control in your plant should be traceable back to a zone, a conduit, an SL, and an FR. If you cannot trace it, either the control is unnecessary or your diagram is wrong.

RelyBlue develops Zone and Conduit diagrams and specifications as part of our IEC 62443-aligned design engagements. Request a design review.