🏭 IEC 62443: Securing Industrial Automation and Control Systems (OT)

What IEC 62443 actually is

IEC 62443 is the leading international standard for the cybersecurity of Industrial Automation and Control Systems (IACS) — the controllers, SCADA, DCS, PLCs, safety systems and supporting networks that run physical processes. It began life as ISA-99, developed by the International Society of Automation, and was later adopted and renumbered by the IEC. The two names refer to the same body of work; you will still see "ISA/IEC 62443" used interchangeably.

The standard exists because Operational Technology (OT) is not IT. In OT, availability and safety outranks confidentiality, equipment lifecycles run 15–30 years, patching may require a plant shutdown, and a security failure can injure people or damage physical assets. IEC 62443 is built around those realities rather than retrofitting office-IT assumptions onto a control system.

Who it is for

A defining feature of IEC 62443 is that it assigns responsibility to three distinct roles, because no single party can secure an OT system alone:

• Asset owners — the operator who runs the plant and owns the risk. They define the security program, perform risk assessment, and set target security levels.
• System integrators (service providers) — who design, commission and maintain the automation solution for a specific site.
• Product suppliers — who build the components and systems (PLCs, HMIs, firmware) with security capabilities baked in.

How it differs from IT-centric standards

Compared with frameworks like ISO 27001 or NIST 800-53, IEC 62443 is purpose-built for control systems. It prioritises availability and integrity over confidentiality, models the network as physical zones rather than abstract assets, and ties security capability to the device itself through a certifiable scheme (ISASecure, IECEE CB). It is also process-aware: it expects that a security control must never compromise the safe operation of the process.

The structure of the standard

IEC 62443 is not a single document but a family of standards and technical reports, organised into four groups. The numbering (62443-x-y) tells you which group and topic a part belongs to.

• Group 1 — General: concepts, terminology and models that the rest of the series builds on (e.g. 62443-1-1).
• Group 2 — Policies & Procedures: the security program — what asset owners and service providers must do organisationally. Notably 62443-2-1 (establishing an IACS security program) and 62443-2-4 (requirements for service providers).
• Group 3 — System: security at the level of the system-under-consideration. 62443-3-2 covers risk assessment and zone/conduit design; 62443-3-3 defines the system security requirements and security levels.
• Group 4 — Component: requirements for the individual products. 62443-4-1 covers the secure development lifecycle a supplier must follow; 62443-4-2 defines the technical security requirements for components.

Read together, the parts map cleanly onto the three roles: 2-x is mostly asset-owner and integrator, 3-x is system design, and 4-x is the product supplier. This lets a procurement team demand 62443-4-2 capabilities from a vendor while the operator builds its own 62443-2-1 program.

Zones and Conduits: the segmentation model

The architectural heart of IEC 62443 is the concept of zones and conduits, defined in 62443-3-2.

• A zone is a grouping of logical or physical assets that share common security requirements — for example, a "safety zone", a "process control zone", or a "DMZ". Assets are grouped by the risk they carry, not just by network topology.
• A conduit is the controlled communication path between zones. All traffic crossing a zone boundary must flow through a conduit, where it can be inspected, filtered and restricted.

The discipline is simple but powerful: by drawing zones and conduits, you decompose a sprawling plant network into manageable units, each with its own target security level. A breach in one zone is contained because the conduits limit lateral movement. This is the practical mechanism that delivers defense-in-depth rather than a single hard perimeter.

The seven Foundational Requirements

Every technical requirement in IEC 62443 rolls up into one of seven Foundational Requirements (FRs). They are the categories against which a zone's security is measured:

• FR1 — Identification & Authentication Control (IAC): uniquely identify and authenticate all users, devices and software before granting access.
• FR2 — Use Control (UC): enforce assigned privileges — what an authenticated entity is actually allowed to do (least privilege, role-based access).
• FR3 — System Integrity (SI): protect the integrity of the control system against unauthorised modification, including firmware, configuration and communications.
• FR4 — Data Confidentiality (DC): protect information (at rest and in transit) from unauthorised disclosure — typically the lowest OT priority.
• FR5 — Restricted Data Flow (RDF): segment the system and control information flow — this is where zones and conduits are enforced.
• FR6 — Timely Response to Events (TRE): detect security events, log them, and respond, so violations are noticed and acted upon.
• FR7 — Resource Availability (RA): ensure the system stays available and resilient against denial-of-service and resource exhaustion — the paramount OT concern.

Security Levels: target, capability and achieved

IEC 62443 expresses "how secure" as a Security Level (SL) on a scale of SL 1 to SL 4. Crucially, the level is defined by the strength of the attacker it can resist, not by a feature checklist:

Level	Resists
SL 1	Casual or coincidental violation
SL 2	Intentional attack with simple means, low resources, generic skills
SL 3	Intentional attack with sophisticated means, moderate resources, IACS-specific skills
SL 4	Intentional attack with sophisticated means, extended resources and IACS-specific skills

A single SL value is also broken into the seven FRs as an SL vector, e.g. SL-T = { 3 3 2 1 3 2 3 }, so you can demand strong authentication without over-engineering confidentiality. Three flavours of SL are used together:

• SL-T (Target): the level a zone needs, derived from risk assessment. Set by the asset owner.
• SL-C (Capability): the level a component or system can achieve when configured correctly. A property of the product (62443-4-2 / 3-3).
• SL-A (Achieved): the level actually realised in the deployed installation. The goal is SL-A ≥ SL-T for every zone.

Maturity Levels

Security Levels measure technical robustness, but they say nothing about whether your processes are repeatable. For that, IEC 62443 (in 62443-2-4 and 4-1) borrows a Maturity Level scale, adapted from CMMI:

• ML 1 — Initial: done ad hoc, undocumented.
• ML 2 — Managed: a documented process exists and is followed.
• ML 3 — Defined (Practiced): the process is standard across the organisation and demonstrably practiced.
• ML 4 — Improving: the process is measured with metrics and continuously improved.

This separates "the product is capable" (SL) from "the organisation reliably does the right thing" (ML) — both matter for genuine security.

Relationship to the Purdue model, defense-in-depth and NIST CSF

The Purdue Enterprise Reference Architecture divides a plant into hierarchical levels — Level 0 (field devices) up through Level 3 (site operations) and Levels 4–5 (enterprise IT), usually with a DMZ between OT and IT. IEC 62443 does not replace Purdue; it uses Purdue levels as a natural starting point for drawing zones, then refines them based on actual risk. The Purdue DMZ is, in 62443 terms, simply a zone connected to other zones by tightly controlled conduits.

The zones-and-conduits approach is the standard's expression of defense-in-depth: multiple independent layers so that defeating one control does not compromise the whole system.

IEC 62443 also complements the NIST Cybersecurity Framework (CSF) rather than competing with it. NIST CSF gives you the high-level outcome categories (Identify, Protect, Detect, Respond, Recover); IEC 62443 supplies the OT-specific technical detail and prescriptive requirements to actually satisfy them. Many programs use CSF for governance and 62443 for the engineering substance.

Practical adoption for an asset owner

A pragmatic 62443 rollout follows the logic of 62443-3-2:

• 1. Identify the System under Consideration (SuC). Inventory the assets, networks and data flows. You cannot protect what you have not catalogued.
• 2. Perform an initial high-level risk assessment. Identify the worst-case consequences (safety, environmental, production loss) to understand what is at stake.
• 3. Partition into zones and conduits. Group assets by shared security needs; safety-instrumented systems almost always get their own zone. Define every conduit between zones.
• 4. Run a detailed risk assessment per zone and assign each zone an SL-Target vector across the seven FRs.
• 5. Compare SL-T against component SL-C to find gaps, then select countermeasures (network segmentation, firewalls, authentication, monitoring) to close them.
• 6. Implement segmentation and controls, verifying that the achieved level (SL-A) meets or exceeds the target for each zone.
• 7. Operate, monitor and improve. Continuous monitoring (FR6), patch and change management, periodic reassessment, and raising process Maturity Levels over time.

The result is a defensible, risk-prioritised architecture in which spending is directed where consequence is highest — not a uniform, unaffordable "harden everything" approach.