The IEC 62443 series of standards, developed jointly by the International Electrotechnical Commission (IEC) and the International Society of Automation (ISA), represents the definitive global framework for securing Industrial Automation and Control Systems (IACS). Originally developed by the ISA-99 committee and adopted as IEC 62443, these standards address the unique cybersecurity challenges of operational technology (OT) environments where safety, availability, and real-time performance are paramount. This article provides a comprehensive technical analysis of the IEC 62443 framework, its security level model, the Zones and Conduits approach, recent 2024 updates, and alignment with regulatory frameworks such as NIS2 and NERC CIP.
Scope and Organization of IEC 62443
The IEC 62443 standard series is organized into five main parts, each targeting a different stakeholder group within the IACS lifecycle:
| Part | Title | Target Audience | Status (2025) |
|---|---|---|---|
| IEC 62443-1-1 | Terminology, Concepts and Models | All stakeholders | Published (Ed. 2) |
| IEC 62443-2-1 | Requirements for IACS Security Management System | Asset Owners | Published 2024 (Ed. 2) |
| IEC 62443-2-4 | Security Program Requirements for IACS Service Providers | System Integrators, MSPs | Published |
| IEC 62443-3-2 | Security Risk Assessment for System Design | System Designers | Published |
| IEC 62443-3-3 | System Security Requirements and Security Levels | System Designers | Published |
| IEC 62443-4-1 | Secure Product Development Lifecycle Requirements | Product Suppliers | Published |
| IEC 62443-4-2 | Technical Security Requirements for IACS Components | Product Suppliers | Published |
Security Levels: SL-T, SL-C, and SL-A
A key innovation of IEC 62443 is the distinction between three types of Security Levels (SL), which disambiguates the desired target from the current capability and the achieved result:
SL-T (Target Security Level)
The desired security level determined through risk assessment. The asset owner defines SL-T based on the consequences of a successful cyberattack and the likelihood of such an attack. Higher SL-T is required when the consequence includes loss of life, significant environmental damage, or economic impact exceeding defined thresholds.
SL-C (Capability Security Level)
The security level that a component or system is capable of providing when properly configured. SL-C is determined by testing products against the requirements in IEC 62443-4-2 (components) or IEC 62443-3-3 (systems). Product vendors certify their products to specific SL-C levels.
SL-A (Achieved Security Level)
The actual security level realized after deployment, considering the system design, configuration, and operational environment. SL-A may be lower than SL-C if the system is improperly configured or deployed in an environment with compensating risks. The goal of the security design process is to make SL-A meet or exceed SL-T.
Security Level Requirements Summary
| Level | SL Capability Required | Threat Scenario | Typical Applications |
|---|---|---|---|
| SL 1 | Protection against casual or coincidental violation | Unintentional breaches, untargeted malware, human error | Non-critical manufacturing, building automation |
| SL 2 | Protection against intentional violation using simple means | Low-skill attackers, commodity malware, basic scanning | Discrete manufacturing, food and beverage, warehouses |
| SL 3 | Protection against intentional violation using sophisticated means | Skilled attackers, targeted attacks, advanced malware | Critical infrastructure: power, water, oil and gas, chemicals |
| SL 4 | Protection against intentional violation using sophisticated means with extended resources | Nation-state actors, advanced persistent threats (APTs), zero-day exploits | Nuclear power, defense systems, critical national infrastructure |
Foundational Requirements (FRs)
Each security level is evaluated against seven Foundational Requirements. Every FR is further decomposed into System Requirements (SRs) and Requirement Enhancements (REs):
| FR | Foundational Requirement | SR Count | Key Topics |
|---|---|---|---|
| FR 1 | Identification and Authentication Control | 6 SRs | User identification, device identification, password management, multifactor authentication |
| FR 2 | Use Control | 9 SRs | Authorization enforcement, least privilege, session lock, remote session control |
| FR 3 | System Integrity | 8 SRs | Data integrity, software integrity, malware protection, integrity monitoring |
| FR 4 | Data Confidentiality | 4 SRs | Encryption of data in transit and at rest, key management |
| FR 5 | Restricted Data Flow | 7 SRs | Network segmentation, zone isolation, application firewalling |
| FR 6 | Timely Response to Events | 5 SRs | Audit logging, event detection, incident reporting |
| FR 7 | Resource Availability | 7 SRs | Denial of service protection, resource management, backup and recovery |
Zones and Conduits Model
The Zones and Conduits model is the architectural foundation of IEC 62443-3-2 and IEC 62443-3-3. It provides a systematic method for network segmentation and security control placement:
Zones
A Zone is a logical grouping of assets (controllers, servers, workstations, network devices) that share common security requirements. Zones are defined based on:
- Criticality — Assets whose failure causes safety or production impact are grouped separately.
- Function — All components serving a common function (e.g., all boiler controls) belong to the same zone.
- Physical Location — Assets in the same physical area may share a zone for practical cabling and maintenance reasons.
- Security Requirements — Assets requiring SL 3 belong to a higher-security zone than SL 1 assets.
Conduits
A Conduit is the communication path connecting two or more zones. Conduits are not merely network links — they are secured communication channels that implement:
- Access Control — Only permitted protocols and devices may traverse the conduit.
- Traffic Filtering — Deep packet inspection (DPI) for industrial protocols (Modbus, DNP3, OPC UA) to reject malformed or malicious commands.
- Encryption — TLS or IPsec encryption for data in transit between zones.
- Monitoring — All conduit traffic is logged and analyzed for anomalies.
IEC 62443-2-1:2024 — The New Security Management Standard
The 2024 edition of IEC 62443-2-1 represents a significant update to the IACS security management requirements. Key changes include:
- Expanded Scope — The new edition explicitly covers operational technology (OT) environments beyond traditional IACS, including building management systems, physical access control, and industrial IoT devices.
- Risk Management Integration — Requires integration of OT cybersecurity risk management with enterprise risk management frameworks (ISO 31000, NIST CSF).
- Supply Chain Security — New requirements for managing cybersecurity risks throughout the IACS supply chain, including software bill of materials (SBOM) requirements and vendor security assessments.
- Continuous Improvement — Mandates periodic security reviews and updates to the IACS security program, with defined KPIs and management review cycles.
- Incident Response — Detailed requirements for OT-specific incident response planning, including coordination with national CERTs/CSIRTs and regulatory reporting.
- Personnel Competency — New requirements for ensuring cybersecurity competency of IACS personnel, including role-based training and awareness programs.
Alignment with Regulatory Frameworks
NIS2 Directive (EU)
The EU Network and Information Security Directive 2 (NIS2), effective October 2024, requires essential and important entities to implement risk management measures. IEC 62443 is explicitly recognized as a harmonized standard for demonstrating compliance with NIS2 Article 21 (Cybersecurity Risk Management Measures). Organizations adopting IEC 62443 can streamline NIS2 compliance through:
- Risk analysis (NIS2 Art. 21.2.a) mapped to IEC 62443-3-2 risk assessment methodology
- Incident handling (NIS2 Art. 21.2.c) meeting IEC 62443-2-1 incident response requirements
- Supply chain security (NIS2 Art. 21.2.d) aligned with IEC 62443-2-4 service provider requirements
- Access control (NIS2 Art. 21.2.f) implemented per IEC 62443-3-3 FR1/FR2 requirements
NERC CIP (North America)
The North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) standards mandate cybersecurity for bulk electric systems. While NERC CIP is sector-specific, IEC 62443 provides a complementary framework for non-bulk electric IACS assets and for implementing NERC CIP requirements in design. Many utility operators use IEC 62443 SL-3 as the target security level for cyber-critical assets, which aligns well with NERC CIP Medium and High impact categories.
Compensating Countermeasures
When an IACS component or system cannot meet the required SL-T (e.g., a legacy PLC with no native encryption support), IEC 62443-3-2 permits the use of compensating countermeasures. These are security controls applied outside the component to raise SL-A to the required level. Examples include:
- Network-Level Encryption — If a PLC does not support encrypted Modbus, deploy a Modbus TCP encrypting proxy that wraps plaintext traffic in TLS.
- Application Whitelisting — For legacy HMI workstations that cannot be patched, deploy application whitelisting to prevent unauthorized code execution.
- Micro-Segmentation — Isolate an unpatchable legacy device in its own L2 micro-segment with ACLs blocking all but required protocols.
- Anomaly Detection — Deploy an OT NDR (Network Detection and Response) sensor on the conduit serving legacy devices to detect exploit attempts.
Each compensating countermeasure must be documented with its security contribution, and the asset owner must accept the residual risk.
Purdue Model Reference
IEC 62443 uses the Purdue model (ISA-95 functional hierarchy) as the reference architecture for zone definition. The standard does not mandate a specific number of layers but provides guidance on how the Purdue levels map to security zones:
- Levels 4-5 (Enterprise IT) — Should be a separate zone or zones from OT. Typically SL-T 1-2. DMZ required at Level 3.5 boundary.
- Level 3 (Operations Management) — Core SCADA zone. SL-T 3-4 for critical infrastructure. Contains historian, SCADA servers, batch management.
- Level 2 (Supervisory Control) — HMI and engineering zones. SL-T 2-3. May be same zone as Level 3 or separated based on criticality.
- Levels 0-1 (Control and Field) — Highest security zones. SL-T 3-4. Safety systems should be in a separate zone from non-safety control systems.
ASP OTOMASYON A.Ş. and its subsidiaries OPCTurkey and ASP Dijital provide end-to-end industrial engineering solutions for process automation, data operations and AI.
References & Further Reading
- IEC 62443 Series — Industrial Communication Network and System Security — International standard series covering all aspects of IACS cybersecurity: management systems (62443-2-1), risk assessment (62443-3-2), system requirements (62443-3-3), and secure development lifecycle (62443-4-1).
- ISA-99 / IEC 62443 — ISA Standards Committee on IACS Security — Official ISA-99 committee page with technical reports, whitepapers, and implementation guidance for the IEC 62443 framework.
- NIST SP 800-82 Rev.2 — Guide to Industrial Control System (ICS) Security — NIST guide complementing IEC 62443 with practical implementation guidance for ICS cybersecurity, including threat modelling and risk assessment methodologies.
- NERC CIP — Critical Infrastructure Protection Standards — North American reliability standards for bulk electric system cybersecurity, aligned with IEC 62443 security levels for critical infrastructure protection.
- EU NIS2 Directive — Network and Information Security — European Union directive for cybersecurity risk management across critical sectors, recognising IEC 62443 as a harmonised standard for demonstrating compliance.