IEC 62443 in Practice: Mapping Security Levels to Real-World OT Environments
Introduction
IEC 62443 is the primary international standard for securing Industrial Automation and Control Systems (IACS). Unlike IT-focused standards that bolt security onto existing systems, IEC 62443 was designed from the ground up for the OT environment — acknowledging constraints like long system lifecycles, safety requirements, and the need for continuous availability.
Understanding IEC 62443 is essential for anyone working in OT/ICS security, whether in a technical, compliance, or research capacity.
Structure of the Standard
IEC 62443 is organised into four tiers, each addressing a different stakeholder:
General (62443-1-x) — Concepts, models, and terminology
Policies & Procedures (62443-2-x) — Requirements for asset owners operating ICS environments
System (62443-3-x) — Security requirements for system integrators designing OT solutions
Component (62443-4-x) — Security requirements for product vendors building ICS devices
This multi-stakeholder approach recognises that OT security is a shared responsibility across the supply chain — a concept the IT world has been slower to adopt.
Zones and Conduits: The Core Model
The most practically useful concept in IEC 62443 is the zone and conduit model:
- A zone is a grouping of assets with the same security requirements (similar to a network segment, but defined by risk, not just topology)
- A conduit is the communication path between zones, with defined security controls
This maps naturally to the Purdue Model but provides more formal structure for defining security requirements at each boundary.
Security Levels
IEC 62443 defines four Security Levels (SL) that represent increasing protection against increasingly capable threat actors:
| SL | Threat Actor | Description |
|---|---|---|
| SL 1 | Casual / unintentional | Protection against accidental violations |
| SL 2 | Simple means, low resources | Protection against intentional attacks with basic skills |
| SL 3 | Sophisticated means, moderate resources | Protection against organised, targeted attacks |
| SL 4 | State-level resources | Protection against nation-state actors with extensive resources |
For each zone, the asset owner determines a Target Security Level based on risk assessment, and then system integrators and product vendors must demonstrate they can meet that level.
Practical Application
I applied the IEC 62443 zone and conduit model to the water treatment SCADA system from my threat modelling project:
- Process Control Zone (SL 2): PLCs and local I/O — protected against basic intentional attacks
- Supervisory Zone (SL 2): HMI and SCADA servers — same protection level
- Safety Zone (SL 3): Safety Instrumented System — higher protection given the direct safety implications
- DMZ (SL 3): Historian and remote access — higher protection as the boundary between IT and OT
- Enterprise Zone (SL 1): Standard IT security controls
Each conduit between zones has defined security requirements: what traffic is permitted, how it’s authenticated, and how it’s monitored.
Comparison with Other Frameworks
| Aspect | IEC 62443 | NIST CSF | ISO 27001 |
|---|---|---|---|
| OT-specific | Yes | No (IT-focused, OT guidance exists) | No |
| Prescriptive controls | Yes (detailed foundational requirements) | No (outcome-based) | Partially |
| Supply chain coverage | Yes (vendor, integrator, operator) | Limited | Limited |
| Safety integration | Yes | No | No |
| Certification scheme | Yes (ISASecure) | No | Yes |
Research Interest
I’m interested in how the IEC 62443 security level framework could be extended or adapted to better address emerging challenges like cloud-connected ICS, IIoT devices that don’t fit neatly into the Purdue Model, and the increasing use of machine learning in control systems that may introduce new attack surfaces.
Replace with your actual analysis, zone/conduit diagrams, and specific examples from your work.