IEC 62443 - Practical Implementation in OT Environments

When the 2021 Colonial Pipeline ransomware attack forced a fuel supply shutdown on the US East Coast, the root cause was not a compromised control system - it was the lack of separation between the business and operational networks. The IEC 62443 standard addresses exactly this problem: it defines how to design security zones, control data flows between them, and require appropriate levels of protection from every supply chain participant - from PLC manufacturers to system integrators.

It is the only set of standards that addresses industrial automation and control system (IACS) security from three perspectives simultaneously: the asset owner, the integrator, and the component manufacturer. This article shows how specific requirements of the standard translate into concrete decisions in real production environments.

Structure of the IEC 62443 Standard Family

The IEC 62443 family comprises four groups of documents. Each addresses a different role in the IACS security ecosystem:

Group	Designation	Audience	Key Documents
General	62443-1-x	All	1-1 (terminology), 1-6 (IIoT - PAS published Dec 2025)
Policies and procedures	62443-2-x	Asset owner	2-1 (security program, 2024 revision), 2-3 (patch management), 2-4 (service provider requirements)
System	62443-3-x	Integrator	3-2 (risk assessment, zones and conduits), 3-3 (system security requirements)
Component	62443-4-x	Manufacturer	4-1 (SDLC - secure development lifecycle), 4-2 (component technical requirements)

NOTE

IEC 62443-2-1:2024 (Edition 2.0) is a fundamental overhaul of the 2010 version. The term CSMS (Cyber Security Management System) has been retired, replaced by Security Program (SP). Requirements have been reorganized into Security Program Elements (SPE), and a new maturity model enables assessment of implementation progress for each element. Harmonization with ISO/IEC 27005 and NIST SP 800-30 simplifies integration with existing ISO 27001-based ISMS.

Security Levels (SL) - Choosing the Right One

IEC 62443 operates with three types of security levels that are important to distinguish:

SL-T (Target) - the target level derived from risk assessment. This is the one you set.
SL-C (Capability) - the technical capability of a system or component. This is the one the manufacturer declares.
SL-A (Achieved) - the level actually achieved in the running system. This is the one you verify.

The four SL levels map to attacker profiles:

Level	Threat Profile	Attacker Resources	Typical Application
SL 1	Unintentional violation, human error	Minimal	Auxiliary systems, BMS
SL 2	Intentional attack with limited resources	Low, general skills	SCADA/DCS systems in manufacturing
SL 3	Sophisticated attack, IACS-specific expertise	Significant, financial motivation	Critical infrastructure (energy, water)
SL 4	Nation-state level attack (APT)	Extensive, long-term	Nuclear, military systems

Practical Method for Selecting SL

SL-T selection is performed for each zone individually (not for the entire plant) per IEC 62443-3-2. Three questions structure the process:

What is the impact of a breach? Is the consequence data loss, production shutdown, or threat to human life?
Who is the realistic attacker? For a chemical plant near a national border, the threat profile will differ from a small wastewater treatment plant.
What are the regulatory requirements? NIS2 requires essential service operators to implement measures proportionate to risk - in practice at least SL 2 for regulated IACS systems.

TIP

You do not need to implement a single SL across the entire plant. An HMI operator station in the control room may require SL 2, the safety system (SIS) should have SL 3, and the BMS - SL 1. Such differentiation is not only permitted but recommended - it concentrates resources where risk is highest.

Zones and Conduits - The Foundation of OT Segmentation

The zones and conduits concept from IEC 62443-3-2 is the most important mechanism for practical standard implementation. A zone groups assets with a similar security profile. A conduit is a controlled communication channel between zones, with clearly defined data flow rules.

Typical Zone Architecture

[Corporate Zone - SL 1]
  ERP, email, internet
        |
  [DMZ - SL 2]
  Historian mirror, proxy, jump server
        |
[Supervisory Zone - SL 2]
  SCADA/HMI, historian, MES
        |
[Control Zone - SL 3]
  PLC/DCS, safety controllers (SIS)
        |
[Field Zone - SL 2]
  Sensors, actuators, I/O

Example: Pharmaceutical Plant with Cleanroom System

In a pharmaceutical plant with a production line and cleanroom-class HVAC system, zone partitioning considers both function and breach consequences:

Zone	Assets	SL-T	Rationale
Building management	BMS, office HVAC	SL 1	Impact limited to comfort
Cleanroom HVAC	Cleanroom HVAC controllers, particle monitoring	SL 2	Loss of parameter control = production batch hold
Production - packaging	PLC Siemens S7-1500, HMI	SL 2	Intentional attack could alter labeling
Production - reactor	DCS, SIS	SL 3	Threat to life from reaction parameter manipulation
Corporate	SAP, workstations	SL 1	Business data, no process impact

Conduits between zones require:

Industrial firewall with rules based on OT protocols (e.g., permit only Modbus TCP port 502 from specific IP addresses)
Unidirectional data gateway (data diode) between the reactor control zone and DMZ - process data flows out, nothing flows in
Jump server with multi-factor authentication as the only remote access point to the supervisory zone

More on practical OT network segmentation in the article OT Network Segmentation - from theory to implementation.

From SL 1 to SL 3 - What Changes in the Architecture

Each successive security level adds requirements that directly affect network architecture and required components.

SL 1 - Protection Against Unintentional Violation (37 FR requirements)

At SL 1, the organization implements basic controls:

Password authentication for users (including wireless)
User account creation and management
Network segmentation into zones (VLANs) with firewalls at boundaries
Audit log generation
Data-in-transit integrity protection
Malware detection
Restricting unnecessary ports, protocols and services
Ability to operate in degraded mode during DoS attacks

SL 2 - Protection Against Intentional Attack (additional 23 requirements)

SL 2 introduces a significant qualitative shift:

Software process authentication - not just humans, but also applications communicating with the control system
Certificates instead of passwords for wireless networks - CA verification instead of PSK
Network intrusion detection system (IDS) - malicious code protection at all entry points
Event server as a centralized log repository
VPN on firewall for remote access through untrusted networks
Physical separation of the control network from non-critical networks

In practice, SL 2 requires adding to the architecture: an account management server, Certificate Authority, backup server, event server, and IDS.

SL 3 - Protection Against Sophisticated Attack (additional 30 requirements)

At SL 3, some requirements must be implemented in hardware - meaning software added at SL 2 is not sufficient. Device replacement or redesign may be necessary.

Key differences:

Hardware security modules (HSM) for cryptographic key protection
Multi-factor authentication for interfaces from untrusted networks
Unique identification of every device and process - not just users
Unauthorized wireless device detection
SIEM instead of event server - centralized log management with event correlation
Exclusively secure communication protocols with cryptographic mechanisms
GPS time source for log synchronization

WARNING

Moving from SL 2 to SL 3 is rarely achievable as a software upgrade. PLC manufacturers who lack IEC 62443-4-2 certification at SL 3 will not supply components meeting these requirements. Plan hardware replacements well in advance.

Component and Development Process Certification

IEC 62443-4-1 - Secure Development Lifecycle (SDLC)

IEC 62443-4-1 defines requirements for the software development process of OT component manufacturers. From December 2027, the Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to provide SBOM and maintain a vulnerability management process. Manufacturers who have implemented IEC 62443-4-1 have a direct path to CRA compliance - the standard’s requirements map to CRA obligations for secure design and vulnerability handling.

SDLC Checklist per IEC 62443-4-1

Threat modeling for every new product - identifies attack vectors at the design stage, before they become vulnerabilities in production
Security code review with emphasis on CWE Top 25 - eliminates the most commonly exploited classes of bugs
Fuzz testing of communication protocols - detects parsing errors that lead to remote code execution
PSIRT (Product Security Incident Response Team) process - ensures coordinated response to vulnerability reports
SBOM (Software Bill of Materials) delivered with every release - enables tracking dependencies with new CVEs
Secure firmware update procedure with integrity verification - protects against software tampering in the supply chain

IEC 62443-4-2 - Component Technical Requirements

IEC 62443-4-2 specifies security requirements that an individual component (PLC, switch, HMI) must meet at a given SL-C level. The ISASecure certification program offers three paths:

Certification	Applies to	Base Standard	Examples of Certified Products
SDLA	Manufacturer development process	IEC 62443-4-1	Siemens (7 R&D centers), Honeywell
SSA	Automation system	IEC 62443-3-3	Siemens - system integration certification
CSA/EDSA	Component	IEC 62443-4-2	Honeywell Experion C300, Yokogawa CENTUM VP, ABB DCS Controller, Schneider Electric Triconex, Siemens SCALANCE XC-200

TIP

When selecting OT components, ask the vendor for an ISASecure or TUV SUD certificate confirming compliance with IEC 62443-4-2 at a specific SL-C level. A manufacturer declaration without external certification is insufficient - particularly for critical infrastructure where SL 3 is required.

Patch Management in OT Environments

IEC 62443-2-3 defines patch management requirements, which in OT environments represents one of the greatest challenges. Systems have maintenance windows measured in hours per year, and a patch requiring a PLC restart means stopping the process.

Step-by-Step Process

Step	Action	Tools / Sources
1. Identification	Monitor CVEs for all IACS components	Tenable OT Security, CISA KEV, vendor advisories
2. Risk assessment	Is the vulnerability actively exploited? What is the zone context?	CISA KEV, EPSS score, network accessibility analysis
3. Testing	Test the patch in a test environment or on a simulator	PLC configuration backup before testing
4. Deployment	Schedule maintenance window, prepare rollback procedure	Management of Change (MOC)
5. Verification	Confirm correct process operation after update	FAT/SAT tests, anomaly monitoring for 24-48h

TIP

Not every vulnerability requires an immediate patch. If the system is in an SL 3 zone with micro-segmentation and no external network access, the risk of exploiting a CVE with CVSS 7.0 may be acceptable. Document the risk acceptance decision per IEC 62443-2-1 and include it in the security program (SP).

2024 Revision - Key Changes

The IEC 62443-2-1:2024 update is not a cosmetic change but a foundation overhaul:

New requirement structure - instead of a checklist, requirements are organized into Security Program Elements (SPE) defining the security capabilities required for safe IACS operation
Maturity model - each SPE is assessed on a maturity scale, enabling measurement of implementation progress instead of binary “meets / does not meet”
Elimination of ISMS duplication - requirements overlapping with information security management systems (e.g., ISO 27001) have been removed or harmonized
Risk assessment harmonization - unified approach with ISO/IEC 27005 and NIST SP 800-30, simplifying integration for organizations already using ISO 27001
Expanded “asset owner” definition - the term now also covers IACS operators, emphasizing shared responsibility

New Document: IEC PAS 62443-1-6:2025

In December 2025, IEC PAS 62443-1-6:2025 was published, introducing guidelines for Security Protection Schemes for IIoT communications. The document addresses scenarios where IoT devices communicate directly with the cloud, bypassing traditional zone-based architecture - an increasingly common situation in plants deploying predictive maintenance or energy monitoring.

Relationship with Other Regulations

IEC 62443 operates within a broader regulatory ecosystem. For organizations subject to multiple regulations simultaneously, the standard simplifies compliance because many requirements overlap:

Regulation	Relationship with IEC 62443
NIS2	Requires measures proportionate to risk - IEC 62443 provides the methodology
Cyber Resilience Act (from Dec 2027)	IEC 62443-4-1 and 4-2 map directly to CRA requirements for secure development and vulnerability management
ISO 27001	IEC 62443-2-1:2024 harmonized with ISO/IEC 27005 - supplements ISMS with OT requirements
Machinery Directive 2023/1230	References IEC 62443 for machinery cybersecurity

Getting Started - Five Steps

An organization looking to implement IEC 62443 does not need to do everything at once. A proven phased approach:

IACS asset inventory - you cannot protect what you cannot see. Use passive network scanning to identify all devices (details in the asset inventory article)
Define zones and conduits - group assets by function and required security level
Risk assessment for each zone - assign SL-T based on breach impact and threat profile
Gap analysis - compare current state against target SL requirements. This is where the scale of work becomes apparent.
Implementation plan - prioritize actions by risk, not by implementation ease

TIP

Start with the highest-risk zone - typically where breach consequences affect human safety or the environment. Then expand to additional zones. A phased approach allows demonstrating results and gaining management support before the next budget cycle.

Defense in Depth as an Implementation Framework

IEC 62443 formalizes the Defense in Depth approach across six protection layers, applied simultaneously:

Security plan - asset inventory, configuration assessment, vulnerability identification
Network separation - division into corporate, production, control and field zones
Conduit protection - firewalls, data diodes, VPN at zone boundaries
Internal segmentation - further division of zones into smaller sub-segments (micro-segmentation)
Device hardening - disabling unnecessary services, changing default passwords, restricting privileges
Monitoring and updates - continuous network traffic monitoring, regular patching

A detailed discussion of Defense in Depth in the context of DCS systems can be found in the article Defense in Depth in Distributed Control Systems.

Sources

ISA/IEC 62443 Series of Standards - official ISA page with full standards catalog
ISA: Update to ISA/IEC 62443-2-1 (January 2025) - 2024 revision announcement
IEC PAS 62443-1-6:2025 - new IIoT guidelines in IEC Webstore
ISASecure - certification program - database of certified products and processes
Dragos: Understanding ISA/IEC 62443 for OT Security Teams - practical Dragos guide
InstruNexus: IEC 62443 Zones and Conduits - Practical Approach - practical zones and conduits approach
Exida: How IEC 62443 Can Help Achieve CRA Compliance - IEC 62443 to Cyber Resilience Act mapping
ISA: UL Solutions Full ISASecure Accreditation (2025) - expanded certification availability