IEC 62443 Zones, Conduits and Security Levels

Most organizations "aligning with IEC 62443" have a network diagram with colored boxes. Far fewer can explain why each box exists, what security level it must reach, and which requirements follow. This article walks through the part of the standard that turns a plant into a defensible design: zones and conduits, the three kinds of security level, and the path from the IEC 62443-3-2 risk assessment to the IEC 62443-3-3 system requirements.

The problem in real environments

In brownfield plants, utilities and building portfolios, the control system grew one project at a time: a historian here, remote support there, a vendor gateway with its own cellular modem. The result often behaves like a flat network: VLANs exist, yet the firewall between them allows "any" from engineering workstations to controllers, and nobody can say which traffic is required.

When these organizations adopt IEC 62443, the common first move is to draw the Purdue model on top of what exists and call each level a zone. That produces a picture, not a design. Purdue levels describe function, while 62443 zones describe shared security requirements. Two Level 1 controller groups can belong in different zones if one drives a safety-relevant process and the other runs conveyors.

Zones and conduits, defined properly

A zone is a grouping of logical or physical assets that share common security requirements. A conduit is a logical grouping of communication channels that connects two or more zones and shares common security requirements of its own. The important word in both definitions is requirements. A zone is not a VLAN, a subnet or a cabinet, although it is usually implemented with them.

Practical criteria for drawing zone boundaries:

Consequence of compromise: assets whose misuse could cause a safety, environmental or major production event should not share a zone with assets whose worst outcome is a lost report.
Function and criticality: basic process control, safety instrumented systems, supervisory systems, and plant-wide services such as historians and patch servers usually separate naturally.
Technology and ownership: a vendor-maintained package unit with its own update path, accounts and remote access is often best treated as its own zone, even if it is physically small.
Physical location: remote substations, pump stations or rooftop plant rooms have different physical exposure from a staffed control room.
Trust: wireless segments, contractor laptops and temporary maintenance connections deserve less trust than fixed, managed assets.

Keep the safety instrumented system (SIS) in its own zone, separate from the basic process control system, and treat any link between them as a documented conduit. IEC 62443-3-2 explicitly calls for separating safety-related assets.

Conduits are where most engineering effort goes. For each one, document the zones it joins, allowed protocols and directions, who initiates sessions, the enforcing boundary devices, and how it is monitored. A conduit that cannot be described in a few lines is usually two or three conduits hiding inside one firewall rule set.

Three security levels, three different questions

IEC 62443 defines four security levels, from SL 1 (protection against casual or coincidental violation) to SL 4 (protection against intentional violation using sophisticated means, extended resources, IACS-specific skills and high motivation). SL 2 and SL 3 sit between those, distinguished mainly by the attacker's means, resources, skills and motivation. What causes confusion is that the same scale is used to answer three different questions:

Term	Question it answers	Who usually owns it
SL-T (target)	What level of protection does this zone or conduit need, given its risk?	Asset owner, with the risk assessment team
SL-C (capability)	What level can this component or system reach when properly configured?	Product supplier (component capability per 62443-4-2) and system integrator (system capability per 62443-3-3)
SL-A (achieved)	What level does the zone actually reach as built, configured and operated today?	Asset owner and integrator, verified by assessment

The relationship is simple to state: choose the SL-T from risk, select components and design countermeasures whose SL-C can meet it, then verify that the SL-A matches. If SL-A falls below SL-T, the gap must be closed with compensating countermeasures or explicitly accepted by the asset owner.

A product certificate is not proof of a secure zone. A controller certified at SL-C 2 only tells you what it can do. With shared accounts, logging disabled and the engineering port reachable from the corporate network, the zone's achieved level may be well below 2.

Security levels are vectors, not single numbers

Each security level is expressed against the seven foundational requirements (FRs): FR 1 identification and authentication control, FR 2 use control, FR 3 system integrity, FR 4 data confidentiality, FR 5 restricted data flow, FR 6 timely response to events, and FR 7 resource availability. A zone's target can therefore be written as a vector, for example SL-T = {3, 3, 3, 1, 3, 2, 3}.

This matters in OT. Many control zones need strong integrity, authentication and availability protection but modest confidentiality, since process values are rarely secret. A conduit crossing a third-party network may need the opposite emphasis. Collapsing everything into one number hides these trade-offs.

How 62443-3-2 feeds 62443-3-3

IEC 62443-3-2 defines the risk assessment workflow for system design as a set of zone and conduit requirements (ZCRs). In outline, the sequence is:

ZCR 1, identify the system under consideration (SUC): define its boundary, assets and access points, including remote access, removable media and vendor links.
ZCR 2, initial cyber risk assessment: a high-level view of worst-case unmitigated risk, often using existing process hazard analyses.
ZCR 3, partition into zones and conduits: group assets using the criteria above, and separate safety, wireless and externally connected assets.
ZCR 4, compare initial risk to tolerable risk: if a zone's initial risk is already tolerable, a detailed assessment may not be needed.
ZCR 5, detailed cyber risk assessment: for each zone and conduit, identify threats, vulnerabilities, consequences and likelihood, determine unmitigated risk, set the SL-T, apply countermeasures and evaluate residual risk.
ZCR 6, document cybersecurity requirements, assumptions and constraints: captured in a cybersecurity requirements specification (CRS) per zone and conduit, including the SL-T.
ZCR 7, asset owner approval: the owner formally accepts the results, including residual risk.

The CRS is the handoff point. IEC 62443-3-3 lists system requirements (SRs) and requirement enhancements (REs) for each FR, and each SR or RE is associated with the security levels at which it applies. Once a zone has an SL-T vector, the applicable SRs and REs follow from the standard rather than from opinion.

A few examples of how the SL-T shapes the requirements:

SR 1.1, human user identification and authentication: at the lower levels, users must be identified and authenticated; at higher levels, enhancements add unique identification of every user and multifactor authentication, first for untrusted networks and then for all networks.
SR 5.1, network segmentation: at the base level, control system networks are logically segmented from non-control networks; enhancements add physical segmentation, then independence from non-control system networks, and at SL 4 logical and physical isolation of critical networks.
SR 5.2, zone boundary protection: the base requirement monitors and controls communication at zone boundaries; enhancements add deny-by-default, allow-by-exception policies, and the ability to isolate the zone when needed.
SR 1.13, access via untrusted networks: remote access must be monitored and controlled, with explicit access request approval added at higher levels.
SR 7.3, control system backup: backups are required at all levels, with verification of backup reliability and automation added as the level rises.

Confirm the exact SR-to-SL mapping in the edition you work from; the text above summarizes intent, not normative wording. The point is that the SL-T turns a vague ambition into a testable checklist per zone and conduit.

Why common approaches fail

One SL-T for the whole site: declaring "we are SL 2" everywhere either over-engineers low-risk zones or under-protects the few that matter.
Zones drawn before consequences are known: partitioning by topology alone relabels the existing weaknesses.
Conduits left implicit: the zone boundaries are documented but the communication between them is not, so firewall rules drift back to broad permits within a year.
Treating SL-C as SL-A: buying certified components without verifying configuration, accounts, logging and operational procedures.
No owner sign-off: without ZCR 7, residual risk is never accepted and nobody owns the gaps.

A recommended approach

Start from consequences, not from the network. Pull the worst credible outcomes for each process area from the existing HAZOP or process hazard analysis, and ask which of those could be caused or worsened by loss of view, loss of control or manipulation of control. That gives the initial risk picture for ZCR 2 and immediately suggests where boundaries belong.

Partition conservatively: a modest number of well-understood zones is easier to operate than dozens of micro-zones that nobody maintains. Use conduits to express the minimum required communication, and prefer designs where data flows outward from more critical zones to less critical ones, with the supervisory or DMZ layer brokering anything that needs to go the other way.

Set SL-T as a vector per zone and conduit, document the reasoning in the CRS, and map it to the 62443-3-3 SRs. Then assess SL-A honestly, list the gaps, and decide for each gap whether to fix it technically, compensate with a procedural or detective control, or formally accept it.

Implementation checklist

Define the SUC boundary and inventory its assets and every external access point.
Collect consequence data from existing safety and process studies.
Draft zones using consequence, function, ownership, location and trust as criteria; isolate SIS, wireless and vendor-managed packages.
Document each conduit: zones joined, protocols, direction, initiator, enforcing device and monitoring.
Run the detailed assessment per zone and conduit, and record an SL-T vector for each.
Map SL-T to applicable 62443-3-3 SRs and REs and build the CRS.
Check SL-C of proposed components and systems against the CRS before procurement.
Assess SL-A after commissioning and after major changes; track gaps with owners and dates.
Obtain formal asset owner approval of residual risk and schedule periodic review.

Common mistakes to avoid

Placing the historian, domain controllers and remote access servers in the same zone as controllers "for convenience".
Ignoring removable media and transient laptops as access points to a zone.
Writing an SL-T without recording the threat assumptions behind it, which makes future review impossible.

Where to start

Pick one process area with real safety or production consequences and take it through ZCR 1 to ZCR 7 end to end. The first pass will expose missing asset data, undocumented conduits and unclear ownership, and those findings are often more valuable than the final SL-T numbers. Then extend it site-wide and tie it to procurement, so every new system arrives with a declared SL-C and a place in the zone model.