IEC 62443 is the primary international standard series governing the cybersecurity of industrial automation and control systems (IACS). It covers the full ecosystem: product suppliers (those who build control system components), system integrators (those who assemble and deploy IACS), and asset owners (those who operate the systems). The standard is referenced in NIS2, DORA’s operational resilience framework for critical infrastructure, and national cybersecurity frameworks across Europe, North America, and Asia-Pacific.
Despite widespread recognition, IEC 62443 remains poorly understood in practice. OT security teams encounter it most often in the context of compliance requirements or procurement criteria, but the underlying architecture model — zones, conduits, and security levels — is a genuinely useful framework for designing and evaluating OT network security. This guide covers what practitioners need to know to work with the standard.
The Standard Series Structure
IEC 62443 is not a single document. It is a multi-part series organised across four levels:
| Part | Scope |
|---|---|
| IEC 62443-1 (General) | Terminology, concepts, security lifecycle |
| IEC 62443-2 (Policies and Procedures) | Asset owner security management requirements |
| IEC 62443-3 (System Level) | Security requirements for IACS systems, including the zone-conduit model |
| IEC 62443-4 (Component Level) | Security requirements for IACS products and software development |
For OT security practitioners, IEC 62443-3-3 (System Security Requirements and Security Levels) and IEC 62443-3-2 (Security Risk Assessment for System Design) are the most operationally relevant. IEC 62443-2-1 (Security Management System Requirements) is the asset owner governance reference.
Security Levels: The Risk Classification Framework
Security Levels (SL) are the central quantification concept in IEC 62443. They define a hierarchy of protection against intentional attack:
| Security Level | Protection Against |
|---|---|
| SL 0 | No specific requirements |
| SL 1 | Casual or coincidental violation; opportunistic attacker with generic tools |
| SL 2 | Intentional violation using simple means; motivated attacker with low resources |
| SL 3 | Intentional violation using sophisticated means; skilled attacker with resources and IACS knowledge |
| SL 4 | Intentional violation using state-of-the-art means; nation-state capability, extended motivation |
Target Security Level (SL-T) is what you assess is required based on the risk analysis of the system. Capability Security Level (SL-C) is what the controls actually provide. Achieved Security Level (SL-A) is what has been verified in the deployed system.
Most OT environments should target SL-2 as a baseline, with SL-3 for critical systems in high-consequence sectors (power generation, water treatment, rail signalling, oil and gas). SL-4 is rarely specified outside of the most sensitive national security IACS applications.
What SL-2 requires in practice:
- Identification and authentication for all users, including read-only access to HMIs and historian systems (not just operator consoles)
- Use control — roles and permissions defining what each user type can do within the IACS
- System integrity — control system software integrity verification (not just OS-level, but application and configuration integrity)
- Availability — resistance to denial-of-service attack on IACS components and communications
- Confidentiality — protection of IACS data at rest and in transit to the extent operationally feasible
- Restricted data flow — zone and conduit implementation limiting where data can flow
What SL-3 adds:
- Authentication mechanisms resistant to replay attacks and credential theft at scale
- Separation of untrusted sources — robust segmentation preventing any untrusted connection from reaching SL-3 zones
- Audit log integrity — tamper-evident logs that cannot be modified by a compromised workstation
- Security function verification — active verification that security controls are functioning, not just deployed
- Physical security controls on IACS components proportionate to the consequence of physical access
The Zone-Conduit Model
The zone-conduit model in IEC 62443-3-2 is the network architecture framework for IACS segmentation. Understanding it allows OT security teams to evaluate network designs against a documented standard rather than informal best-practice guidance.
Zones
A zone is a grouping of assets with common security requirements. Zones are defined by:
- Functional purpose (process control, safety, engineering, business)
- Required security level
- Trust relationship (assets within a zone trust each other; assets between zones do not)
Zones are not equivalent to VLANs or firewall segments, though those are often the technical implementations. A zone is a logical concept: a set of assets that share a security boundary and a common SL-T.
Common zone definitions in an industrial environment:
| Zone | Typical Assets | SL-T |
|---|---|---|
| Safety Instrumented System (SIS) | Emergency shutdown systems, safety PLCs, safety sensors | SL-3 |
| Process Control | DCS/SCADA controllers, field devices, PLC loops | SL-2 |
| Supervisory Control | HMIs, process historians, alarm management servers | SL-2 |
| Engineering / Maintenance | Engineering workstations, programming terminals | SL-2 |
| Industrial DMZ | Historian proxy, remote access gateway, data diode source | SL-2 |
| Enterprise | Business systems, ERP, PIMS | SL-1 or standard IT |
The SIS zone deserves special attention: Safety Instrumented Systems should be segmented from the Process Control zone with the strictest available controls, not just a firewall rule. The Triton/TRISIS malware attack against a petrochemical facility’s SIS in 2017 demonstrated the consequence of insufficient separation between the SIS and the process control network.
Conduits
A conduit is a communication path between two zones that has defined security properties. Every communication between zones must pass through a conduit; there are no direct zone-to-zone connections without a conduit definition.
A conduit definition includes:
- The two zones it connects
- The permitted communication flows (source, destination, protocol, direction)
- The security controls protecting the conduit (firewall, data diode, unidirectional gateway, encrypted tunnel)
- The SL of the conduit itself
Conduit types and their security properties:
Firewall-based conduits are bidirectional communications paths through stateful inspection with defined ruleset. Appropriate between the Enterprise zone and the Industrial DMZ, and between the DMZ and Supervisory Control for historian replication. Not appropriate between any zone and the SIS or where one-way data flow is required.
Data diodes / unidirectional security gateways allow data to flow in one direction only — physically enforced by the hardware architecture. Appropriate for historian replication from the Process Control zone to the Industrial DMZ, and from the DMZ to the Enterprise zone. Prevents any inbound traffic from reaching the control zone regardless of firewall rule misconfiguration.
Air gaps are sometimes implemented but create operational challenges for patching, monitoring, and remote support. A managed air gap with strictly controlled transfer mechanisms (USB with malware scanning in a separate kiosk, removable media with cryptographic hash verification) provides a high SL but requires process discipline to maintain.
Encrypted tunnels (IPSec/TLS) protect the confidentiality and integrity of communications across conduits that traverse untrusted networks (WAN links, cellular backhaul). They do not by themselves limit what traffic flows through the conduit — a firewall or protocol filter is still needed for that.
Implementing Zone-Conduit Architecture: A Practical Sequence
Step 1: Asset inventory and zone assignment
Before zones can be defined, the asset inventory must exist. This is frequently the blocking step: many OT environments have incomplete visibility of what devices are in the network. Passive network discovery tools (Claroty, Nozomi Networks, Dragos Platform, Claroty xDome) are the standard approach for initial OT asset discovery without disrupting process operations.
Once the inventory exists, group assets by function and required security level. The SIS should be identifiable immediately. Process control assets (PLCs, DCS controllers, field instruments with network interfaces) form the process control zone. Engineering workstations and historian servers belong to their respective zones.
Step 2: Current-state conduit mapping
Map every existing communication path between the zones you’ve defined. Network traffic analysis (using Zeek, an OT-aware PCAP analysis, or an IDS platform with ICS protocol support) reveals actual communication flows. Compare this against documented system architecture — the gaps between documented and actual communications are typically where the most risk lies.
Step 3: Conduit security level assessment
For each conduit, assess whether the current controls achieve the required SL. An enterprise-to-SCADA firewall with no inbound restrictions, default-allow rules, or legacy protocols passing unchallenged through it is not providing SL-2 conduit security regardless of what the architecture diagram shows.
Step 4: Remediation prioritisation
Address the highest-risk conduit gaps first:
- Any conduit providing bidirectional access between the Enterprise zone and the Process Control zone without an intermediate DMZ
- Any conduit providing access to the SIS from any lower-security zone without enforced one-way flow
- Remote access conduits without MFA, session recording, and least-privilege access controls
Step 5: Ongoing validation
IEC 62443 requires periodic assessment of the achieved security level, not just initial implementation. Annual penetration testing of conduit controls, continuous monitoring for conduit policy violations (traffic that should not be crossing a zone boundary appearing in network flow data), and change management that requires zone-conduit impact assessment for any OT network change are the operational processes that maintain the achieved SL.
IEC 62443 and NIS2
For operators covered by NIS2 (the EU Network and Information Security directive), IEC 62443 compliance is increasingly accepted as evidence of the “appropriate and proportionate technical and organisational measures” required by Article 21. National supervisory authorities in Germany, Netherlands, France, and Sweden have specifically referenced IEC 62443 in NIS2 implementation guidance.
The NIS2 risk management measures (Article 21) that IEC 62443 addresses most directly:
- Network segmentation (IEC 62443-3-2 zone-conduit model)
- Incident detection (IEC 62443-2-1 security monitoring requirements)
- Supply chain security (IEC 62443-2-4 supplier requirements, IEC 62443-4-1 product development lifecycle)
- Vulnerability handling (IEC 62443-2-3 patch management)
For OT operators navigating NIS2 obligations while managing operational constraints, framing the compliance programme around IEC 62443 implementation provides a technically grounded structure that national supervisory authorities recognise.
Practical Starting Point
For OT environments that are beginning IEC 62443 implementation, the minimum viable starting point is:
- Complete the asset inventory and define your zones (even informally, before writing documentation)
- Map your SIS boundary and verify it is enforced by hardware-based separation or a validated firewall with no inbound exceptions from lower-security zones
- Implement remote access through a single managed conduit with MFA, session recording, and time-limited access — eliminating direct RDP/VNC to process control systems
- Verify that your engineering workstations are in a defined zone with controlled conduits rather than connected to both the corporate network and process control systems simultaneously
These four controls address the most commonly exploited vulnerabilities in OT environments and establish the baseline for a more complete IEC 62443 implementation programme.