IEC 62443 zones and conduits, explained for plant managers

Most plant managers meet IEC 62443 as a line in a tender or a finding in an audit: the control system shall be partitioned into zones and conduits. It sounds like paperwork. To me it is the most useful part of the whole series.

A zone is a group of assets that deserve the same protection

IEC 62443 defines a zone as a grouping of logical or physical assets that share common security requirements. In plain terms, a zone is a set of devices that would suffer the same consequences if attacked, and that you can defend as one unit. The controllers and HMI of one process line can be a zone. The safety instrumented system is almost always a zone of its own. The historian and the servers that exchange data with the office network belong to yet another zone.

A zone often lines up with a VLAN, a room or a level of the Purdue model, but it is something else: a decision about risk. Everything inside the zone is trusted to the same degree, and everything inside it must meet the same target security level.

A conduit is every path between two zones

A conduit groups the communication channels that connect zones and share the same security requirements. The cable between the control zone and the DMZ is a conduit. So is the vendor's remote-access session, the engineer's laptop that is plugged in during commissioning, the USB stick used to move a recipe from the office, and the serial or radio link to a remote station. If data or commands can cross from one zone to another, there is a conduit, whether or not anyone drew it.

The standard asks three things of every conduit: that you know it exists, that you decide what may cross it, and that you enforce that decision with something real. That can be a firewall whose rules are written for the industrial protocol, a data diode where data only needs to leave the plant, or a jump server with individual accounts for remote access.

Security levels: how much each zone must withstand

Each zone and conduit gets a target security level, from SL 1 to SL 4. SL 1 protects against casual or accidental misuse. SL 2 protects against an intentional attack with simple means and general skills. SL 3 protects against a sophisticated attacker with knowledge of industrial control systems and moderate resources. SL 4 covers the same attacker with extended resources, which in practice means a state.

IEC 62443-3-2 describes how to set the target level from a risk assessment. IEC 62443-3-3 lists the system requirements a system must meet at each level, grouped under seven foundational requirements: identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Zones and conduits are where restricted data flow becomes concrete.

What this means for a plant manager: not every zone needs SL 3. A packaging line and a turbine controller do not deserve the same budget, and zones are how you spend the money where the consequences are.

How to draw them on a real plant

Start from the inventory, not from the network drawing

The network drawing shows how the plant was meant to be built. The inventory shows what is actually there. In the risk assessments I run, the first deliverable is a complete map of the controllers, stations, servers, switches, firewalls and diodes, built with tools that query the devices themselves. At ICL's power stations that inventory became the basis of the report submitted to the regulator. Zones drawn without it miss the forgotten modem and the second network card in the historian.

Group by consequence and function

For each group of assets, ask what happens if an attacker controls it. Keep the assets of one process unit together, separate safety from control, and separate anything that touches the business network. Ownership matters too. Equipment maintained by a vendor under contract often deserves its own zone, because someone else's laptop will be connected to it.

List every flow, then name the conduits

For each pair of zones, write down what must pass between them: which protocol, in which direction, between which hosts, and how often. Everything that is not on the list is blocked. This step finds most of the surprises, such as an office PC that writes directly to a controller because someone found it convenient years ago.

Set target levels and compare them with reality

Give each zone and conduit a target security level from the risk assessment, then compare it with what the installed equipment can actually achieve. The difference is your project list, ordered by consequence rather than by what is easiest to buy.

Write it down in two pages

A good result is one diagram and one table. The diagram shows the zones and the conduits between them. The table lists, for each zone, its assets and target level, and for each conduit, the permitted flows and the device that enforces them. If the operations team cannot read it, nobody will maintain it.

Common mistakes

• One big OT zone. Putting the whole plant behind one firewall separates IT from OT, which is a good start. Once an attacker is inside, though, everything is within reach.
• Zones copied from the IP plan. VLANs were laid out for traffic and convenience, not for consequence. Use them to implement zones, not to define them.
• Forgotten conduits. Remote access, vendor laptops, removable media, wireless links and the path to the historian are conduits too, and attackers favour exactly the ones nobody drew.
• Conduits on paper only. A firewall between two zones with an any-to-any rule is a drawing, not a control.
• Safety inside the control zone. The safety instrumented system protects people and equipment when control fails. It needs its own zone and the tightest conduit on the site.
• A diagram that is never updated. Plants change at every shutdown. The zone model has to be part of change management, or it soon describes a plant that no longer exists.

Where to start

You do not need a full IEC 62443 programme to get value from zones and conduits. Ask three questions. Do we have a current inventory of every device on the control network? Can we list every path into the control network, including remote access and removable media? Is the safety system separated from everything else? If any of the answers is no, that is your first project.

In the ICS security course this is a whiteboard exercise: segmenting a plant network by hand, before anyone touches a firewall. It is the same exercise I run with clients, on their own plant, as the start of an OT cyber-security architecture.