TL;DR:

  • IEC 62443 is the international standard family for Industrial Automation and Control System (IACS) cybersecurity — used by asset owners, system integrators, and component manufacturers across OT and IIoT
  • Its core model divides systems into security zones and conduits, with target Security Levels (SL 1–4) describing the strength of protection required
  • Unlike IT security standards, IEC 62443 treats operational continuity as a primary concern alongside confidentiality — recognising that patching and updates cannot disrupt production
  • Compliance is increasingly demanded in procurement by asset owners across energy, manufacturing, water, and critical infrastructure sectors

Ask ten OT security engineers which standard actually governs their work and most will say IEC 62443. Ask ten IoT device manufacturers which security framework their industrial customers reference in procurement and the answer is the same. It’s the de facto reference framework for industrial cybersecurity, and its relevance has grown as industrial control systems connect to IP networks and as IIoT deployments expand the attack surface at the operational technology edge.

Understanding IEC 62443 properly requires getting past the title (“Cybersecurity for Industrial Automation and Control Systems”) and into the specific concepts it introduces, because those concepts — zones, conduits, security levels, foundational requirements — have become the shared vocabulary of the field.

The Standard Structure

IEC 62443 is a family of documents rather than a single standard. The series is organised into four groups, each addressing a different audience:

Series 1 — General: Defines terminology, concepts, use cases, and the overall framework. This is where you start if you want to understand the architecture of the standard. IEC 62443-1-1 establishes core concepts; IEC 62443-1-3 defines security metrics.

Series 2 — Policies and Procedures: Addresses security management requirements for asset owners (IEC 62443-2-1) and supplier security practices for service providers and integrators (IEC 62443-2-4). This is the “how should you run your OT security programme” section.

Series 3 — System Requirements: Defines requirements at the system level — specifically how IACS should be designed and decomposed into zones and conduits (IEC 62443-3-2) and the security requirements for the overall system (IEC 62443-3-3). This is the most widely referenced section for system architects.

Series 4 — Component Requirements: Sets security requirements at the device and component level (IEC 62443-4-2) and secure product development lifecycle requirements for component suppliers (IEC 62443-4-1). If you build industrial hardware or embedded software, this is your primary reference.

Most practitioners encounter IEC 62443-3-3 (system security requirements) and IEC 62443-4-2 (component requirements) most frequently. These define what security properties a system or device must have at each security level.

Zones and Conduits: The Core Architectural Concept

The most immediately useful concept in IEC 62443 is the zone and conduit model. Rather than applying a uniform set of security controls across the entire IACS, the standard asks you to:

  1. Partition the system into security zones — groups of assets (devices, networks, applications) that share common security requirements, that are logically and/or physically separated, and that are managed as a unit with respect to access control and security policy.

  2. Define conduits between zones — the controlled paths through which communication is permitted between zones, each of which has its own security requirements governing what traverses them and how.

This is not a new idea — it maps onto the Purdue Model (ISA-95) that has been used in industrial networking for decades. What IEC 62443 adds is a formal requirement to document the zones, specify the target Security Level for each zone, and design conduits to enforce those levels.

Practical zone decomposition

A simple industrial environment might have zones structured as:

  • Enterprise zone: Business IT systems, ERP, remote access servers — SL 1 target
  • DMZ / demilitarised zone: Historian, data exchange servers, remote access gateway — SL 2 target
  • Control zone: HMI, SCADA, engineering workstations — SL 2 or SL 3 target
  • Field device zone: PLCs, RTUs, sensors, actuators — SL 2 target, with critical safety loops at SL 3

Each conduit between zones (firewall, data diode, industrial DMZ) enforces what traffic is permitted and how it’s authenticated and filtered. Traffic flows are documented explicitly rather than left to convention.

Security Levels

IEC 62443 uses four Security Levels (SL) to describe the strength of protection required:

SL 1: Protection against casual or unintentional misuse. Basic authentication, access controls, logging. Sufficient for zones where compromise has limited operational impact and the threat model doesn’t include intentional adversaries.

SL 2: Protection against intentional violation using simple means. Adds account management, session controls, communication integrity checking, and audit capability. This is the baseline for most operational OT environments where deliberate attack is a realistic concern.

SL 3: Protection against intentional violation using sophisticated means — which includes state-sponsored actors, organised crime, and determined adversaries with significant resources. Adds encryption in transit, stronger authentication mechanisms (MFA where feasible), more granular access control, and stronger anomaly detection. Required for critical infrastructure zones.

SL 4: Protection against violation using state-of-the-art means with significant resources. The requirement for nuclear, military, and national-critical infrastructure. Involves hardware security modules, formal verification of critical components, and extensive defence in depth. Very few commercial implementations target SL 4 across their entire system.

Security Levels have three variants: the target SL (what you’re designing for), the achieved SL (what an assessment shows you’ve actually implemented), and the capability SL (what the component is capable of supporting). A device might be capable of SL 3 but deployed in a zone with only SL 2 requirements.

Foundational Requirements (FRs)

IEC 62443-3-3 defines seven Foundational Requirements that structure the specific security controls:

FR 1 — Identification and Authentication Control (IAC): Every user, device, and process that accesses the IACS must be identified and authenticated before access is granted. At SL 2 and above, password management requirements, lockout policies, and account management processes apply.

FR 2 — Use Control (UC): Authenticated users and devices are authorised only for what they need. Least privilege, role-based access, physical access control, and approval workflows for privileged operations.

FR 3 — System Integrity (SI): The IACS maintains its integrity — software hasn’t been tampered with, unauthorised changes aren’t possible, communications aren’t spoofed. Covers code signing, patch management, host-based detection, and input validation.

FR 4 — Data Confidentiality (DC): Sensitive data — configuration, process values, operator credentials — is protected in transit and at rest. At SL 2+, this typically means encrypted communication channels; at SL 3+, encryption of stored configuration data.

FR 5 — Restricted Data Flow (RDF): Data flows between zones are controlled by conduits that permit only necessary traffic. Firewall rules, protocol whitelisting, and segmentation are the implementation mechanisms.

FR 6 — Timely Response to Events (TRE): The system detects, reports, and responds to security events. Centralised logging, alerting, and defined incident response procedures. Also covers audit trail integrity — logs must be tamper-evident.

FR 7 — Resource Availability (RA): The IACS remains available to authorised users during and after attacks. Resilience against denial of service, redundancy for critical functions, backup and recovery capability. This is the FR that most directly reflects OT’s priority of operational continuity.

Each FR has System Requirements (SRs) defined at each Security Level. The SRs become more stringent as the SL increases, and some SRs only apply at SL 3 or SL 4.

What It Means for Device Manufacturers (IEC 62443-4-2)

IEC 62443-4-2 translates the system-level FRs into requirements at the component level. If you build an IIoT gateway, an industrial router, a PLC, or embedded sensor hardware, this is the section that governs what security capabilities your device must provide.

Key component security requirements include:

  • Unique credentials per device at factory default — no shared default passwords across a product family
  • Secure boot or firmware integrity verification — devices must be able to verify the authenticity of their firmware
  • TLS 1.2 minimum for any networked communications (TLS 1.3 recommended, and increasingly expected in recent procurement requirements)
  • Role-based access control with at minimum an admin role distinct from operator roles
  • Audit logging of authentication events, configuration changes, and security events, with tamper-resistant log storage
  • Software update mechanism with integrity verification — updates must be authenticated before application
  • Session management — idle session timeout, maximum concurrent session limits
  • Interface restriction — ability to disable network interfaces and services that aren’t needed

At SL 2 (the most common procurement target for edge devices in industrial environments), devices need to meet the Component Requirement (CR) set for each FR at SL 2. Certification against IEC 62443-4-2 at a specified SL means an accredited lab has verified these requirements are met.

Certification: ISASecure

The ISASecure certification programme, operated by the ISA Security Compliance Institute, provides third-party certification against IEC 62443. There are three main certification schemes:

  • EDSA (Embedded Device Security Assurance) — for components and embedded devices, aligned with IEC 62443-4-1 and 4-2
  • SDLA (Security Development Lifecycle Assurance) — for supplier development processes, aligned with IEC 62443-4-1
  • SSA (System Security Assurance) — for integrated systems, aligned with IEC 62443-3-3

ISASecure certification is increasingly required in procurement by critical infrastructure operators in energy, water, and manufacturing. Some European regulatory frameworks (including alignment with the EU NIS2 Directive for critical entities) reference IEC 62443 as the applicable standard.

IEC 62443 vs Other Security Frameworks

NIST Cybersecurity Framework (CSF): CSF is a high-level risk management framework for any organisation, not OT-specific. Many asset owners use CSF as their governance framework and IEC 62443 as the technical standard underneath it. They’re complementary rather than competing.

NIST SP 800-82: NIST’s Guide to OT Security is a US-centric document that provides extensive guidance on securing industrial control systems. It’s widely used in US critical infrastructure. IEC 62443 is the international equivalent and is more prescriptive in its security level requirements and zone model.

EU NIS2 Directive: NIS2 requires “essential entities” and “important entities” in critical sectors to implement appropriate cybersecurity measures. For OT-heavy sectors (energy, water, transport, manufacturing), IEC 62443 is the natural technical reference for demonstrating compliance with NIS2’s requirement to manage cybersecurity risk in supply chains and operational systems.

IEC 62443 vs ISO 27001: ISO 27001 is an IT-focused information security management system standard. It doesn’t account for OT-specific constraints like the primacy of availability, the difficulty of patching operational systems, or the safety implications of security incidents. IEC 62443 was designed from the ground up for the operational environment.

Getting Started with IEC 62443 Compliance

For asset owners approaching this for the first time:

  1. Scope the IACS: Define which systems, networks, and equipment are in scope. This is more specific than it sounds — you need clear boundaries before you can do zone design.

  2. Identify your target Security Levels: Not every zone needs SL 3. Work with operations and safety teams to identify which zones contain equipment whose compromise would have safety, environmental, or severe operational consequences — those are your SL 3 candidates.

  3. Document current zone and conduit architecture: Map the actual network topology, identify all conduits that cross zone boundaries, and note what controls currently exist at each conduit.

  4. Gap analysis against target SLs: For each zone, compare the current security controls against the FR/SR requirements at your target SL. This generates your remediation roadmap.

  5. Supplier requirements: For any new equipment purchases, include IEC 62443-4-2 capability at your required SL as a procurement requirement. Ask for supplier security documentation aligned with IEC 62443-4-1 (development lifecycle).

The gap analysis and documentation work is substantial. Organisations typically engage OT security specialists or industrial system integrators with IEC 62443 experience. The ISA also offers training and professional certification (ISA/IEC 62443 Cybersecurity Certificate Programme) for practitioners building this expertise internally.

References