IEC 62443 explained: zones, conduits, security levels and the Purdue model

What IEC 62443 is

IEC 62443 is a series of standards for the security of industrial automation and control systems (IACS): PLCs, DCS, SCADA, safety systems and the networks that connect them. It is written by the ISA99 committee as ISA-62443 and submitted to the IEC; the ISA and IEC editions of each document are identical and released as close together as possible. In 2021 the IEC recognised the series as a horizontal standard, meaning it applies across many industries rather than to one sector.

The series is not one document but a set, written for several parties at once. That is why a tender line such as "the control system shall comply with IEC 62443" means little until someone says which part, for which party and to which security level.

Four groups of documents, several parties

The parts are numbered in four groups (1-x to 4-x); the main ones are:

The series is written for several parties at once: Dragos names asset owners (the plant), system integrators and component suppliers among its stakeholders. Read by title, part 2-1 is written for the asset owner, part 2-4 for service providers, and parts 4-1 and 4-2 for the makers of products.

The Purdue model: where the levels come from

Most plant network drawings start from the Purdue model — the Purdue Enterprise Reference Architecture, developed in the 1990s by Theodore J. Williams and the Industry-Purdue University consortium. It describes levels 0 to 4: the process itself, the field devices that sense and act on it, the control systems (DCS, HMI, SCADA), manufacturing operations (MES, batch, historians) and business logistics (ERP). ISA-95 uses the same levels.

Rockwell's security design guidelines (SECURE-RM001J) build on these levels in the Converged Plantwide Ethernet (CPwE) architecture and apply ISA/IEC 62443 by grouping them into zones (chapter 3). The equipment named below is a typical example, not a list from the guide:

• Cell/Area Zone, levels 0–2: the process (level 0), controllers (level 1) and area supervisory control such as HMIs (level 2);
• Industrial Zone, level 3 (site operations): for example SCADA servers, historians, engineering stations;
• IDMZ (Industrial Demilitarized Zone), a buffer between the Industrial and Enterprise Zones and the only path between them — often drawn as "level 3.5", although the guide itself does not number it;
• Enterprise Zone, levels 4–5: for example ERP, email and the corporate network.

For the IDMZ, the same guide sets the rules: all traffic terminates in the IDMZ and none passes straight through, and EtherNet/IP control traffic stays within the Industrial Zone (chapter 3, "Industrial Demilitarized Zone").

Documents place equipment slightly differently: CPwE puts controllers at level 1 and HMIs at level 2, while the ISA-95 description in OPC Foundation's OPC 10030 places PLC and DCS at level 2. For security design, what matters is how assets are grouped into zones, not the exact level number.

Zones and conduits

The two ideas that change the network drawing most are the zone and the conduit:

• A zone is a group of assets — physically or functionally related — that share the same security requirements. Every asset of the control system belongs to a zone.
• A conduit is a grouping of the communication channels that connect two or more zones and share the same security requirements.

In practice a zone is drawn around equipment that should be protected to the same level: one production line, the SCADA servers, the safety system. A conduit is the controlled connection between zones — usually a firewall or a managed switch with access lists — together with the written list of flows allowed through it. Two zones with no conduit between them simply do not talk to each other.

The figure is an example, not a rule. What the standard asks for is the method: divide the system into zones and conduits, then give each one a target security level from a risk assessment.

Security levels: SL 1 to SL 4

IEC 62443-3-3 defines security levels in terms of the attacker each level should resist:

The same number is used in three ways:

• SL-T (target): the level the asset owner wants for a zone or conduit, set by the risk assessment and written into the cybersecurity requirements specification.
• SL-C (capability): what a system (part 3-3) or a component (part 4-2) can do natively, without added measures.
• SL-A (achieved): the level actually reached by the installed system, normally assessed once it is in operation.

When the capability of the chosen system is below the target, the gap is closed with compensating countermeasures — added procedures or other technical means that meet the intent of the requirement.

Seven foundational requirements

Part 3-3 groups its system requirements under seven foundational requirements (FR). The right-hand column is a plain-language reading, not the standard's wording:

Risk assessment before design (part 3-2)

Part 3-2 describes how the target levels are reached; the main steps are:

1. Define the scope of the system under consideration and identify its critical assets.
2. Carry out an initial assessment to prioritise, and partition the system into zones and conduits.
3. Carry out a detailed assessment for each zone and conduit: choose how to treat each risk (avoid, transfer, accept or mitigate), set the SL-T and select the countermeasures.

The standard does not impose a particular risk method, so the assessment can follow the plant's existing risk process.

Using IEC 62443 on an upgrade project

• Ask for the target levels. If a specification only says "comply with IEC 62443", raise a clarification: which zones, which SL-T for each zone and conduit, and which party performs the risk assessment.
• List assets and data flows first. The list of flows that must cross between zones becomes the conduit rules on the firewalls; for Rockwell systems, see which ports FactoryTalk and Logix need through a firewall.
• Check component capability. Compare the SL-C stated by each product supplier with the SL-T of the zone it sits in; record compensating measures where it falls short.
• Route remote access through the IDMZ, with approved, time-limited and logged sessions rather than a permanent connection into the control network.
• Plan patching and backups as part of operation, not as an afterthought; part 2-3 is the technical report on patch management.

For hardening the controllers themselves, see OT security for Rockwell PLCs.