IEC 62443: Zones, Conduits, and Security Levels
- ICS cyber security, ics security, iec 62443, iec 62443-3-2, ot cybersecurity risk assessment, Security Level, SLT, zone and conduit
OT Cybersecurity Fundamentals — Estimated reading time: 8 minutes
Introduction
We have built the foundation step by step starting from the first article titled “Why OT Cybersecurity Is Not IT Cybersecurity: Where Cyber Risk Meets the Physical World”, the second article titled “Inside the Purdue Model: Mapping the OT Architecture”, the third article titled “NIST Cybersecurity Framework (CSF) 2.0 Applied to OT”, and previous article titled “NIST SP 800-82 Rev. 3: The OT Security Playbook”. Now we move to another important reference:
ISA/IEC 62443 Standard Series
While NIST provides valuable guidance for understanding and managing OT cybersecurity, ISA/IEC 62443 takes us deeper into the industrial automation and control system (IACS) lifecycle, system design, roles, and security requirements.
The ISA/IEC 62443 series was developed specifically for industrial automation and control systems and addresses cybersecurity throughout the lifecycle of those systems. It also emphasizes that cybersecurity is a shared responsibility between asset owners, system integrators, product suppliers, and other service providers.
One of its most useful architectural concepts is the combination of:
Zones + Conduits + Security Levels
Understanding these three concepts is essential before we start discussing detailed ISA/IEC 62443 risk assessment and security requirements.
What is ISA/IEC 62443?
ISA/IEC 62443 or in a shorter version we just call it IEC 62443, is a family of standards and technical reports for the security of Industrial Automation and Control Systems (IACS).
It is not a single document.
The family addresses cybersecurity from different perspectives, including:
- General concepts and terminology
- Security programs and policies
- System design and security requirements
- Component and product security
- Lifecycle activities
- Risk assessment
- Security levels
The series is broadly organized into four groups:
| Series | Primary focus |
| IEC 62443-1-x | General concepts, terminology, and models |
| IEC 62443-2-x | Security programs, policies, and operational processes |
| IEC 62443-3-x | System-level security and risk assessment |
| IEC 62443-4-x | Component and product security |
This structure is important because cybersecurity responsibilities exist at different levels.
A plant owner has different responsibilities from a system integrator.
A system integrator has different responsibilities from a product supplier.
And a product supplier has different responsibilities from the organization operating the facility.
IEC 62443 provides a framework for connecting these responsibilities across the lifecycle.
Why Do We Need Zones and Conduits?
Let’s return to the architecture discussion from the previous Article titled “Inside the Purdue Model: Mapping the OT Architecture”.
Imagine an industrial facility containing:
- PLCs
- HMIs
- Engineering workstations
- Safety systems
- Historians
- OT servers
- Enterprise systems
- Vendor remote access
A simple network diagram might show all of these systems connected.
But from a cybersecurity perspective, simply knowing that systems are connected is not enough.
We need to ask:
Which systems should have similar security requirements?
And:
How should communication between those groups be controlled?
This is where zones and conduits become useful.
What Is a Zone?
In IEC 62443 terminology, a zone is a grouping of logical or physical assets that share common security requirements.
The important phrase is:
Common security requirements.
A zone is therefore not simply:
“Everything connected to the same switch.”
It is a security-oriented grouping.
For example, a facility might conceptually have:
Zone A — Basic Control (PLCs and related control assets)
Zone B — Supervisory Control (HMIs and operator systems)
Zone C — Safety (Safety-related systems with specific security requirements)
Zone D — OT Operations (Historians and operational servers)
Zone E — Industrial DMZ (Systems that provide controlled communication between OT and enterprise environments)
The exact architecture depends on the facility.
There is no universal requirement that every plant must use exactly these zones.
The purpose is to group assets according to their security requirements and risk context.
What is a Conduit?
If a zone is a group of assets with common security requirements, a conduit is the controlled communication path between zones.
IEC 62443-3-2 defines a conduit as a logical grouping of communication channels that share common security requirements and connect two or more zones.
Think of it this way:
Zone → Conduit → Zone
For example:
Control Zone
⬇️
Controlled Conduit
⬇️
Operations Zone
The conduit may include security mechanisms such as:
- Firewalls
- Access control
- Network filtering
- Monitoring
- Secure communication mechanisms
- Authentication mechanisms
The specific controls depend on the risk and security requirements.
The key idea is that communication between zones should not be treated as an uncontrolled pathway.
Zones and Conduits in a Simple Example
Consider a simplified production environment:
ENTERPRISE
│
│
┌───────▼───────┐
│ Industrial DMZ │
│ Zone │
└───────┬───────┘
│
Conduit
│
┌───────▼───────┐
│ OT Operations │
│ Zone │
└───────┬───────┘
│
Conduit
│
┌───────▼───────┐
│ Control Zone │
│ PLC / DCS │
└───────────────┘
The important question is not simply:
“Are these systems connected?”
Instead:
“What security requirements apply to each zone, and what security requirements should govern the communication between them?”
That is a much more useful cybersecurity question.
The Seven Foundational Requirements
IEC 62443 also introduces a set of Foundational Requirements (FRs) that provide a structure for system security requirements.
The seven Foundational Requirements are:
| FR | Foundational Requirement |
| FR 1 | Identification and Authentication Control |
| FR 2 | Use Control |
| FR 3 | System Integrity |
| FR 4 | Data Confidentiality |
| FR 5 | Restricted Data Flow |
| FR 6 | Timely Response to Events |
| FR 7 | Resource Availability |
These requirements provide a common structure for evaluating what a secure IACS should be capable of achieving.
Notice something interesting.
Resource Availability is explicitly included.
That reflects the reality we discussed in Article titled “Why OT Cybersecurity Is Not IT Cybersecurity: Where Cyber Risk Meets the Physical World”.
In OT, cybersecurity cannot be separated completely from operational requirements.
A system that is highly secure but unable to perform its required control function is not necessarily a successful OT security solution.
Similarly, restricted data flow is particularly relevant to the zones-and-conduits concept.
If communication between zones is supposed to be controlled, the architecture needs mechanisms that enforce those restrictions.
What Are Security Levels?
IEC 62443 uses Security Levels (SLs) to describe the level of security capability or protection required in relation to threats.
There are four levels:
| Security Level | General concept |
| SL 1 | Protection against casual or coincidental violations |
| SL 2 | Protection against intentional violation using simple means and limited resources |
| SL 3 | Protection against intentional violation using sophisticated means and moderate resources |
| SL 4 | Protection against intentional violation using sophisticated means and extensive resources |
These levels are associated with different assumptions about the capabilities, resources, skills, and motivation of potential threat actors.
But there is an important point:
Security Level is not simply a rating of how “good” a system is.
It is connected to the security requirements and risk context of the zone or conduit.
Therefore:
A higher number is not automatically the right answer for every system.
The appropriate target depends on the risk assessment.
Target Security Level: SL-T
This brings us to an important concept:
SL-T — Target Security Level
SL-T represents the desired security level for a particular zone or conduit.
IEC 62443-3-2 uses the risk assessment process to establish target security levels for zones and conduits and document the resulting security requirements.
For example:
Imagine a facility has identified two zones:
Zone A — Production Control
Target: SL-T 2
Zone B — Critical Safety-Related Function
Target: SL-T 3
This does not mean one system is “good” and the other is “bad.”
It means the risk assessment determined that the zones have different security requirements.
That difference can then influence the security architecture and the controls required.
SL-T is not the Same as SL-A
This distinction is extremely important.
SL-T = Target Security Level
What security level is required or desired based on the risk assessment.
SL-A = Achieved Security Level
What level the implemented system actually achieves.
These are not the same thing.
For example:
Risk assessment → determines SL-T 3
Then the organization designs and implements security measures.
After implementation and validation, the actual security capability is assessed.
The result might be:
SL-A 2
In that situation:
SL-T 3 ≠ SL-A 2
There is a gap.
That gap needs to be understood and addressed.
The organization may need additional security measures, compensating controls, process improvements, or other risk treatment.
The ISA/IEC 62443 ecosystem distinguishes SL-T, SL-A, and also SL-C (Capability Security Level), which relates to the security capability a system or component can provide when properly integrated and configured.
This is also why we should be careful with statements such as:
“This product is SL-3 certified, therefore the whole system is SL-3.”
That conclusion is not automatically valid.
A product’s capability is only one part of the overall security picture.
The System under Consideration (SuC)
Now we can introduce one of the most important concepts in IEC 62443-3-2:
System under Consideration (SuC).
Before performing the system-level security risk assessment, the organization needs to define what system is actually being assessed.
That is the SuC.
It establishes the scope of the assessment.
For example, instead of saying:
“Assess the cybersecurity of the entire factory.”
the organization might define:
“The production unit control system, including its PLCs, HMIs, engineering workstations, OT servers, network infrastructure, and defined external communication interfaces.”
That becomes the boundary for the assessment.
IEC 62443-3-2 specifically establishes requirements for defining the SUC, partitioning it into zones and conduits, assessing risk, establishing SL-T, and documenting security requirements.
This is where our earlier articles begin to connect.
Article “Inside the Purdue Model: Mapping the OT Architecture” — Purdue Model: Helps us understand architecture.
Article “NIST Cybersecurity Framework (CSF) 2.0 Applied to OT” — NIST CSF: Helps us understand cybersecurity risk and provides a common language.
Article “NIST SP 800-82 Rev. 3: The OT Security Playbook” — NIST SP 800-82: Helps us understand OT-specific security considerations.
While ISA/IEC 62443-3-2: Provides a structured system-design risk assessment process around the SuC, zones, conduits, and target security levels.
A Simplified IEC 62443-3-2 Flow
At a high level, the process can be understood as:
1. Define the SUC
⬇️
2. Identify Assets and System Boundaries
⬇️
3. Partition the SuC into Zones and Conduits
⬇️
4. Identify Threats, Vulnerabilities, and Consequences
⬇️
5. Assess the Risk
⬇️
6. Determine SL-T for Zones and Conduits
⬇️
7. Define Cybersecurity Requirements (CRS)
⬇️
8. Design and Implement Security Measures
⬇️
9. Evaluate Achieved Security
This is a simplified conceptual representation rather than a replacement for the requirements and methodology of the standard.
The key idea is that security requirements should emerge from understanding the system and its risk.
Why Roles Matter
Another important characteristic of IEC 62443 is its emphasis on shared responsibility.
An IACS does not exist because of one organization alone.
There may be:
- Asset Owners
- System Integrators
- Product Suppliers
- Service Providers
- Maintenance Organizations
- Engineering Contractors
Each may control different parts of the lifecycle.
ISA describes the asset owner, automation product supplier, integrator, and service supplier as important stakeholder groups in the shared-responsibility model.
Asset Owner
The asset owner operates the system and remains accountable for the IACS and its associated cybersecurity risks throughout its lifecycle.
The asset owner understands:
- The business objectives
- The operational process
- The consequences of failure
- Risk tolerance
- Site requirements
- Operational constraints
The asset owner therefore plays a central role in defining what security is required.
System Integrator
The system integrator turns requirements into an actual system design and implementation.
This can include:
- System architecture
- Network design
- Security mechanisms
- Integration
- Configuration
- Commissioning
- Validation
The integrator therefore needs to understand both the technical requirements and the asset owner’s operational context.
Product Supplier
The product supplier develops and maintains the products that become part of the IACS.
This may include:
- PLCs
- Controllers
- HMIs
- Network devices
- Software
- Engineering tools
- Security components
Product security therefore becomes part of the overall system security lifecycle.
ISA/IEC 62443-4-1 addresses secure product development lifecycle requirements, while ISA/IEC 62443-4-2 addresses technical security requirements for IACS components.
Why Responsibility Boundaries Matter
Consider a simple situation.
A facility requires secure remote access to a PLC environment.
Who is responsible?
The answer may involve several parties.
Asset Owner: Defines why remote access is required and what risk is acceptable.
System Integrator: Designs how remote access is implemented within the architecture.
Product Supplier: Provides the capabilities of the relevant products.
Service Provider: May perform remote maintenance under defined procedures.
If these responsibilities are unclear, security gaps can appear between organizations.
For example:
The supplier assumes the integrator configured the security correctly.
The integrator assumes the asset owner defined the required security level.
The asset owner assumes the product already provides the necessary protection.
The system may therefore have capabilities, but no one has clearly established whether the overall security requirement has actually been achieved.
IEC 62443’s shared-responsibility approach helps make these boundaries explicit.
IEC 62443 Is a Lifecycle Framework
Another important point is that IEC 62443 is not only about network segmentation.
Zones and conduits are highly visible concepts, but they are only part of the larger framework.
The series addresses cybersecurity across the lifecycle:
Design → Development → Integration → Commissioning → Operation → Maintenance → Retirement (Decommissioning)
Different stakeholders contribute during different phases.
This means cybersecurity should not be added only after the control system has already been designed.
It should be considered throughout the lifecycle.
For example:
During design: Security requirements can influence architecture.
During procurement: Security requirements can influence product and supplier selection.
During integration: Security requirements can be implemented and validated.
During operation: Security processes, monitoring, maintenance, and change management become important.
During maintenance: Patching, configuration changes, vulnerability management, and lifecycle decisions become important.
This lifecycle perspective is one of the reasons IEC 62443 is particularly relevant to industrial environments.
How IEC 62443 Complements NIST
At this point in the series, we have introduced three major references.
They should not be viewed as competitors.
They answer different questions.
| Reference | Primary value |
| NIST CSF 2.0 | Organizes cybersecurity risk and provides a common language |
| NIST SP 800-82 Rev. 3 | Provides OT-specific security guidance and control considerations |
| IEC 62443 | Provides an IACS-focused lifecycle, engineering, system, and component security framework |
A useful mental model is:
CSF 2.0 – What cybersecurity outcomes should we manage?
SP 800-82 – How do those cybersecurity considerations apply to OT?
IEC 62443 – How can we structure security requirements and responsibilities within an IACS lifecycle and system architecture?
They can work together.
A Practical Example
Let’s bring the concepts together.
Imagine a production facility with:
- PLCs controlling a process
- HMIs used by operators
- An engineering workstation
- A historian
- An industrial DMZ
- Enterprise reporting
Step 1 — Understand the architecture
The Purdue Model helps identify where these systems sit and how they communicate.
Step 2 — Identify cybersecurity outcomes
NIST CSF 2.0 helps organize what needs to be governed, identified, protected, detected, responded to, and recovered.
Step 3 — Apply OT-specific guidance
NIST SP 800-82 helps the team consider OT-specific threats, vulnerabilities, architectures, and safeguards.
Step 4 — Define the IACS scope
IEC 62443-3-2 helps define the SUC.
Step 5 — Create zones and conduits
The system is partitioned based on common security requirements.
Step 6 — Assess risk
The team evaluates threats, vulnerabilities, likelihood, and consequences.
Step 7 — Determine SL-T
Target security levels are established for the relevant zones and conduits.
Step 8 — Define security requirements
The required security measures are documented.
Step 9 — Implement and validate
The system is designed, implemented, tested, and evaluated.
Step 10 — Compare achieved security with the target
The organization evaluates whether the implemented system achieves the required security level.
This is much more structured than simply saying:
“Let’s put a firewall between IT and OT.”
The firewall may be part of the solution.
But the architecture and risk assessment determine where it belongs, what it should protect, what traffic should cross it, and what security requirements apply.
Don’t Confuse Zones with Purdue Levels
This is another important distinction.
The Purdue Model and IEC 62443 zones are related concepts, but they are not interchangeable.
The Purdue Model provides a way to describe architectural levels.
IEC 62443 zones are based on common security requirements.
Therefore:
One Purdue level does not automatically equal to one IEC 62443 zone.
A single Purdue level may contain multiple zones.
Likewise, a zone may contain systems that span different architectural levels depending on the actual system design and security requirements.
This distinction becomes particularly important when performing a real security risk assessment.
“Architecture provides the starting context, while Risk determines the security partitioning.”
A Common Mistake: Treating SL as a Label
Another common misunderstanding is treating security levels like a simple label:
“This is an SL-3 system.”
In practice, the terminology needs more precision.
You should ask:
SL-T?
The target security level determined from risk assessment.
SL-C?
The capability a component or system can provide when properly integrated and configured.
SL-A?
The achieved security level of the implemented system or zone/conduit.
These represent different concepts.
This distinction also helps avoid unsupported certification claims.
A certified product, where applicable, does not automatically mean the entire IACS installation has achieved the same security level.
The overall security posture depends on architecture, integration, configuration, policies, procedures, people, and operational practices.
ISA’s certification guidance explicitly distinguishes capability security levels from achieved security levels and notes that product certification alone does not establish the achieved security level of the overall automation solution.
Key Takeaway
IEC 62443 gives OT cybersecurity teams a structured way to move from risk understanding toward security requirements and system design.
Its most important concepts for this stage of the journey are:
🧩 Zones: Group assets that share common security requirements.
🔗 Conduits: Control communication paths between zones.
🎯 SL-T: Define the target security level based on risk.
📊 SL-A: Evaluate the security actually achieved.
👥 Shared Responsibility: Clearly define the roles of asset owners, integrators, suppliers, and service providers.
🔄 Lifecycle: Treat cybersecurity as something that must be managed throughout design, implementation, operation, maintenance, and retirement.
And perhaps the most important lesson:
IEC 62443 does not tell every facility to build the same architecture. It provides a structured way to determine security requirements based on the system, its risks, and the responsibilities of the organizations involved.
Next in the Series
So far, we have looked at three important references:
NIST CSF 2.0
A common language for cybersecurity risk management.
NIST SP 800-82 Rev. 3
OT-specific guidance for applying cybersecurity practices in operational environments.
IEC 62443
An IACS-focused framework for lifecycle, system architecture, roles, risk assessment, and security requirements.
The next challenge is avoiding a common mistake:
Treating these standards as competing alternatives.
They are not.
The next article will bring them together into one coherent OT cybersecurity operating model.
We will look at how an organization can use:
NIST CSF 2.0 → NIST SP 800-82 → IEC 62443
as complementary layers rather than isolated frameworks.
That is where the discussion moves from:
“What does each standard say?”
to:
“How do we actually use them together?”
References
- ISA/IEC 62443 Series of Standards — ISA, overview of the series, lifecycle, stakeholders, and security concepts.
- ISA/IEC 62443-3-2-2020, Security Risk Assessment for System Design.
- ISA/IEC 62443-3-3, System Security Requirements and Security Levels.
- ISA/IEC 62443-2-1, Security Program Requirements for IACS Asset Owners.
- ISA/IEC 62443-4-1, Product Security Development Lifecycle.
- ISA/IEC 62443-4-2, Technical Security Requirements for IACS Components.
