IEC 62443 is the international standard for industrial cybersecurity. At its core is the concept of zones and conduits — a network segmentation model that helps OT engineers protect critical systems from cyber threats. Unlike perimeter-only security models, zones and conduits create defence-in-depth by segmenting assets based on security requirements and controlling every communication path between segments.

What Are Zones?

A zone is a grouping of logical or physical assets that share common security requirements. Assets within the same zone have similar criticality, similar access needs, and can be protected by the same security policies. Zones are not necessarily physical — they can span multiple physical locations if the assets have equivalent security profiles.

IEC 62443-3-2 defines the process for identifying zones:

  1. Identify all assets in scope (controllers, HMIs, engineering workstations, historians, network infrastructure)
  2. Group assets by function and security requirement. Assets that must communicate freely with each other belong in the same zone.
  3. Assess the consequence of compromise for each group. Higher-consequence assets need higher Target Security Levels (SL-T).
  4. Define zone boundaries and document them in a zone diagram.

Typical zones in a process plant include a Safety Zone (SIS controllers and I/O), a Process Control Zone (BPCS controllers, DCS servers), a Supervisory Zone (SCADA, historian, operator stations), an Operations Zone (MES, batch management, performance monitoring), a DMZ (data exchange servers), and a Corporate Zone (enterprise IT).

What Are Conduits?

A conduit is any communication path between zones. Every interface between zones is a conduit, and every conduit must have an explicit security policy that controls what traffic is allowed, in which direction, and using which protocols.

Conduits take two forms:

  • Network conduits: Firewalls, data diodes, unidirectional security gateways, or managed switches with ACLs that control IP traffic between zones. A firewall between the Process Control Zone and the Supervisory Zone is a network conduit.
  • Communication conduits: Specific application-layer data flows — for example, an OPC UA connection from a SCADA server (Supervisory Zone) to a DCS controller (Process Control Zone). The conduit policy specifies which source IP can connect to which destination IP on which port, using which protocol.

Security Levels: The Quantitative Framework

IEC 62443 assigns Security Levels (SL 1 through SL 4) to zones based on the threat actors they need to withstand:

  • SL 1: Protection against unintentional or casual violations. Basic hygiene — password policies, network segmentation, patching. Most plant support systems are SL 1.
  • SL 2: Protection against intentional violation using simple means with low resources and skills (motivated individual without specific ICS knowledge). Adds authentication, audit logging, and intrusion detection. Most process control zones should target SL 2.
  • SL 3: Protection against sophisticated attack using moderate resources (skilled attacker with ICS knowledge, such as a nation-state contractor). Adds multi-factor authentication, advanced monitoring, and hardware security modules. High-criticality zones (SIS, primary SCADA) often target SL 3.
  • SL 4: Protection against state-sponsored attackers with extensive resources and ICS expertise. Requires near-military-grade controls. Rarely specified in commercial process plants.

Each zone has a Target Security Level (SL-T) based on risk assessment. The Achieved Security Level (SL-A) is what the installed controls actually deliver. The gap between SL-T and SL-A is the remediation backlog.

Practical Zone Design: Common Mistakes

  • Flat networks presented as segmented: Many plants claim to have zones but connect them with unmanaged switches or misconfigured firewalls that permit any traffic. A zone boundary with no enforcement is not a conduit — it is an open network. Every conduit must be tested to verify it enforces its policy.
  • Safety Zone connected to BPCS Zone without isolation: The SIS (Safety Zone) must be isolated from the BPCS (Process Control Zone). Data sharing between SIS and BPCS should pass through a unidirectional gateway or read-only OPC UA connection, never a bidirectional network connection that could allow a compromised BPCS to write to SIS logic.
  • Remote access bypassing zones: Vendor VPNs that terminate directly on the Process Control Network bypass all conduit controls. Remote access should terminate in the DMZ on a jump server, and the vendor connects to the target asset through the enforced conduit between the DMZ and the PCN.
  • Undocumented conduits: Every communication path between zones must be documented. Undocumented conduits (rogue wireless access points, unmanaged switches bridging two zones, USB transfers from corporate laptops to engineering workstations) are the most common vector for lateral movement after initial compromise.

Implementing the IEC 62443 Zone Model Step by Step

  1. Asset inventory: Build a complete inventory of all OT assets — every controller, workstation, switch, router, historian, and field device with network connectivity. You cannot segment what you have not inventoried.
  2. Risk assessment: For each group of assets, assess the consequence of a successful cyberattack (safety impact, production loss, environmental release, regulatory penalty) and the likelihood of attack. This drives the SL-T assignment.
  3. Zone diagram: Create a network diagram showing all zones, their SL-T, all conduits between zones, and the security controls on each conduit (firewall, data diode, jump server). This document is the cornerstone of the cybersecurity design.
  4. Conduit policy definition: For each conduit, write explicit allow rules: “SCADA Server (10.10.2.5) may connect to DCS Historian (10.10.1.20) on TCP 4840 (OPC UA). All other traffic between these zones is denied.” Default-deny policies are essential.
  5. Implementation and testing: Deploy the controls. Test each conduit by attempting both allowed and disallowed traffic. Document test results. Remediate gaps.
  6. Ongoing monitoring: Deploy network monitoring (IDS/IPS, SIEM, or OT-specific tools like Claroty, Nozomi Networks, or Dragos) that can detect anomalous traffic crossing conduits. Periodic conduit audits (annually at minimum) verify that policy drift has not created unauthorised paths.

IEC 62443 vs the Purdue Model

The Purdue Model defines a layered hierarchy that maps well to zones. However, IEC 62443 is more flexible — it does not require a strict five-level hierarchy. A cloud-connected historian can be its own zone with conduits to both the Operations Zone and a cloud provider, without forcing all traffic through every Purdue level. IEC 62443 is the design standard; Purdue is a useful conceptual map for communicating with operations teams who are already familiar with it.