IEC 62443

IEC 62443 is the standards family for cybersecurity of industrial automation and control systems (IACS). ISA’s ISA99 committee (formed 2002) develops the documents jointly with IEC Technical Committee 65, Working Group 10, and the ISA and IEC editions of each part are identical texts released in parallel. The series covers building automation, electric power, medical devices, transportation, and process industries — IEC recognized it as a horizontal standard in 2021, meaning it applies across industry verticals rather than one sector. Requirements are split among four stakeholder groups — asset owners, product suppliers, integrators, and service suppliers — on the premise that automation cybersecurity is shared responsibility across the whole lifecycle. ¹

Structure of the series

The parts divide into four families:

• 1-x, general — ISA-62443-1-1 (2007) defines the terminology, concepts, and models everything else builds on.
• 2-x, security programs — 2-1 (2024) sets program requirements for asset owners; 2-3 (2015) covers patch management in the IACS environment; 2-4 (2018) sets program requirements for service providers.
• 3-x, system — 3-2 (2020) defines security risk assessment for system design; 3-3 (2013) defines system security requirements and security levels.
• 4-x, components — 4-1 (2018) sets secure product development lifecycle requirements for suppliers; 4-2 (2018) sets technical security requirements for IACS components.

The ISASecure certification schemes (CSA for components, ICSA for IoT components, SSA for systems, plus SDLA for supplier development processes) certify conformance against these requirements. ²

Zones, conduits, and security levels

A zone groups logical or physical assets that share common security requirements; a conduit carries the communication between zones. The network segmentation into zones and conduits is a core output of the 3-2 risk analysis, which then assigns each zone a target security level. IEC 62443 defines four security levels (SL-1 through SL-4, protection against violations of increasing attacker sophistication) and distinguishes four contextual values: SL-C (what a component can deliver), SL-T (the risk-assessment target), SL-I (implemented — superseding the older SL-A), and SL-O (operational). Where one number is too coarse, Annex A of 3-3 allows an SL vector with one level per foundational requirement: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. ³

The standard is vaguer about conduits than about zones, and Jaatun et al. (2026) argue this matters in practice. Their proposal: define a conduit as the data flows traversing a set of network devices that route and restrict them by configuration, and push the device management interfaces into a separate conduit configuration zone — a control-plane zone distinct from the data-plane conduit, managed by the OT security team, carrying the SL of the highest zone it protects. A conduit should connect exactly two zones (per their operational-practice findings), and conduits between zones of the same SL still need restriction: an unrestricted link devolves two zones into one unmanageable zone. In their case (oil and gas), safety-instrumented systems must be insulated from process control even at equal SLs. ⁴

Open problems in applying the series

The same paper collects the practical frictions: the definitions of “zone” and “conduit” drift across the series’ parts; no prescribed method exists for establishing SL-T (companies lean on their own risk matrices — see risk-matrices for why those rankings wobble); the withdrawn 62443-1-3 draft’s quantitative metrics were rejected; security protection rating collapses maturity level 3 and 4 into one bucket, removing the incentive to improve past “repeatable”; and scale hurts — 30–50 zones per installation is routine, a vendor design guide cites 400, and per-zone threat lists are judged economically infeasible. A related design trap: assigning high SLs to embedded devices at the bottom of the Purdue model pushes suppliers toward general-purpose architectures whose patching and anti-malware expectations conflict with the availability and integrity demands of control systems — the segmentation above should carry the protection instead. ⁵

Related

• opc-ua-security — protocol-level security for the industrial data flows these zones and conduits carry
• threat-modeling — the analysis practice feeding 3-2 zone-and-conduit risk assessment
• risk-matrices — SL-T allocation usually runs through one, with the problems that implies
• adversary-software-supply-chain-bans — procurement-side control on the product suppliers 4-1 and 4-2 regulate

Sources

• International Society of Automation — ISA/IEC 62443 Series of Standards
• Martin Gilje Jaatun, Mary Ann Lundteigen, Christoph Thieme, Lars Halvdan Flå, Karin Bernsmed, Roald Lygre, Fredrik Gratte 2026 — Security Aspects of Zones and Conduits in IEC 62443

Footnotes

1. International Society of Automation — ISA/IEC 62443 Series of Standards ↩

2. International Society of Automation — ISA/IEC 62443 Series of Standards ↩

3. Martin Gilje Jaatun, Mary Ann Lundteigen, Christoph Thieme, Lars Halvdan Flå, Karin Bernsmed, Roald Lygre, Fredrik Gratte 2026 — Security Aspects of Zones and Conduits in IEC 62443 ↩

4. Martin Gilje Jaatun, Mary Ann Lundteigen, Christoph Thieme, Lars Halvdan Flå, Karin Bernsmed, Roald Lygre, Fredrik Gratte 2026 — Security Aspects of Zones and Conduits in IEC 62443 ↩

5. Martin Gilje Jaatun, Mary Ann Lundteigen, Christoph Thieme, Lars Halvdan Flå, Karin Bernsmed, Roald Lygre, Fredrik Gratte 2026 — Security Aspects of Zones and Conduits in IEC 62443 ↩