IEC 62443 explained: zones, conduits and security levels

IEC 62443 is the principal international standard for industrial automation and control system security - and it is built around an idea IT frameworks largely lack: you cannot secure every device, so you segment the environment and defend the boundaries. That single premise makes it workable in plants full of equipment that cannot be patched.

It addresses three roles, not one

Unlike most standards, 62443 assigns obligations across the supply chain:

• Asset owners - operators running the plant. Responsible for the security programme, risk assessment and operating the system securely.
• System integrators - who design and commission the solution. Responsible for secure design and integration practices.
• Product suppliers - who build the components. Responsible for secure development and product capability.

This matters commercially: if you supply components or integration into industrial environments, your customers will increasingly ask which parts of 62443 you meet, and product certification is becoming a differentiator.

Zones and conduits

The core architectural concept:

• A zone groups assets with shared security requirements - a process cell, a safety system, the plant DMZ, the enterprise network.
• A conduit is the controlled communication path between zones, where you enforce and monitor.
• Each zone gets a target security level based on risk. Grouping by requirement means legacy equipment can sit in a tightly controlled zone rather than being individually hardened.

This is the practical answer to unpatchable equipment. You are not pretending the device is secure - you are containing what an attacker can reach if it is compromised, and evidencing that containment.

Security levels

Levels are graded by the capability of the adversary you intend to withstand, running roughly from protection against casual or accidental misuse, through intentional attacks with simple means and modest resources, up to sophisticated attacks with extended resources and specific ICS knowledge.

Three distinctions are used in practice: the target level you need for a zone, the capability level a component can support, and the achieved level in the deployed system. Gaps between target and achieved are where your compensating controls and residual risk live.

The foundational requirements

Technical requirements group under a set of foundational themes that recur throughout the series: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.

Note the ordering emphasis compared with IT standards - availability and integrity carry more weight than confidentiality, because in a process environment an unavailable or manipulated control system is a safety issue, not merely an outage.

How to start

1. Build the asset inventory passively. Active scanning can disrupt live control systems; use passive discovery and vendor documentation.
2. Define zones and conduits based on function and required security, then document the flows between them.
3. Run a risk assessment per zone, including safety consequences - engage process engineering, not just IT.
4. Set target security levels per zone and compare against what your components can actually support.
5. Close the gap with compensating controls where equipment cannot meet the target, and document the residual risk.
6. Control remote access for vendors - brokered, time-limited, monitored. This is the single most exploited path.
7. Build an OT-aware incident response plan with operations in the room.

Key takeaways

• Obligations span asset owners, integrators and product suppliers.
• Zones and conduits let you contain equipment you cannot patch.
• Distinguish target, capability and achieved security levels - the gap is your risk.
• Availability and integrity outrank confidentiality in industrial contexts.