Zone and conduit modeling is the structural heart of IEC 62443. It provides the framework for organizing an Industrial Automation and Control System (IACS) into logical security segments and defining how data flows between them. Done correctly, it translates abstract risk requirements into concrete network architecture decisions.
What Are Zones and Conduits?
Zones are logical groupings of assets that share the same security requirements. Assets in a zone should have similar:
- Criticality (consequence of compromise)
- Threat exposure
- Required security controls
Conduits are the controlled communication paths between zones. Every data flow between zones must pass through a conduit, and the conduit defines what traffic is permitted, how it's inspected, and what compensating controls exist.
Step 1: Asset Inventory
You cannot define zones without knowing what assets you have. Start with a comprehensive asset inventory covering:
- PLCs, DCS controllers, RTUs
- Engineering workstations and HMI servers
- Historian servers
- Network infrastructure (switches, firewalls, routers)
- Third-party remote access points
For each asset, capture: function, communication protocols, network connectivity, criticality, and the consequence of its compromise.
Step 2: Define Zone Boundaries
Group assets into zones based on their security requirements and operational function, not just their network location. Key questions:
- Consequence of compromise — What happens if this asset is taken offline or manipulated? Safety incident? Production loss? Environmental harm?
- Required availability — Can this asset tolerate security controls that add latency or require maintenance windows?
- Trust level — Do the users and systems that access this asset require the same authentication and authorization as others in the candidate zone?
Practical zone examples for a process manufacturing site:
- Safety Instrumented System (SIS) zone: SIL-rated safety controllers. Very high SL-T (typically SL 3–4). Air-gapped or strictly one-way data flows only.
- Process Control zone: DCS, PLCs, HMIs. SL-T 2–3 depending on consequence.
- Supervisory zone: Historian, reporting servers, advanced process control. SL-T 1–2.
- DMZ: Data diodes or proxy servers bridging OT to IT/enterprise.
- Enterprise zone: Business systems, ERP. Governed by IT security policy.
Step 3: Assign SL-T Per Zone
For each zone, conduct a risk assessment per IEC 62443-3-2 to determine the required Security Level Target (SL-T).
SL-T is driven by consequence, not likelihood alone. A zone controlling a safety-critical process may require SL-T 3 even if the likelihood of attack seems low, because the impact of a successful attack is unacceptable.
| SL Level | Typical Profile | |----------|-----------------| | SL 1 | Casual or unintentional violations. Basic controls. | | SL 2 | Intentional violation using simple means. Standard defense-in-depth. | | SL 3 | Sophisticated attack using IACS-specific skills. Strong authentication, monitoring, integrity checks. | | SL 4 | State-sponsored, highly sophisticated attack. Rarely required outside critical national infrastructure. |
Step 4: Define Conduits
For each communication path between zones, define a conduit that specifies:
- Source zone and destination zone
- Permitted protocols (e.g., Modbus/TCP, OPC-UA, ICMP)
- Direction (unidirectional? bidirectional? asymmetric?)
- Security controls (firewall rules, deep packet inspection, authentication)
- Conduit SL-T — the conduit must meet the higher of the two connected zones' SL-T
Conduit implementation options:
- Firewalls with application-layer inspection for OT protocols
- Data diodes for unidirectional flows (e.g., historian reads from process control zone)
- DMZ with proxy for bidirectional flows requiring protocol break
- Jump servers / bastion hosts for administrative access conduits
Step 5: Validate Against the Seven Foundational Requirements
Each zone-conduit model must be validated against IEC 62443's seven Foundational Requirements (FRs). At each SL level, specific requirements within each FR must be met:
- Identification and Authentication Control (IAC) — Are users and devices authenticated before accessing zone assets?
- Use Control (UC) — Is access limited to authorized functions?
- System Integrity (SI) — Are assets protected from unauthorized modification?
- Data Confidentiality (DC) — Is sensitive process data encrypted in transit through conduits?
- Restricted Data Flow (RDF) — Does the conduit enforce the principle of least privilege for network flows?
- Timely Response to Events (TRE) — Is the zone monitored and can incidents be detected and responded to?
- Resource Availability (RA) — Are assets resilient to DoS and can the zone continue operating under stress?
Common Mistakes to Avoid
Defining zones by IP subnet instead of security requirement. Network topology is a starting point, not the answer. A subnet may contain assets with very different risk profiles.
Treating the IT/OT boundary as the only conduit. Modern IACS have many data flows — remote access, historian feeds, cloud connectivity, OEM vendor access. Each needs a defined conduit.
Setting SL-T too low to avoid cost. SL-T reflects what you need, not what you can afford. If the risk demands SL 3, document it. Compensating measures and risk acceptance must be explicit and formal, not hidden in an artificially low SL-T.
Ignoring legacy assets. Legacy PLCs and instruments may not support modern authentication. That doesn't mean they don't belong in the model — it means their zone needs compensating controls and a clear path to remediation.
The Zone-Conduit Model Is Living Documentation
Your zone-conduit model should be updated whenever:
- New assets are added
- Network connectivity changes
- A new vendor connection is established
- A risk assessment review is conducted
IEC 62443-3-2 requires periodic reassessment. In practice, quarterly reviews and update-on-change are the minimum for sites with active modification programs.
Need help building or reviewing your zone-conduit model? Contact the Alsensio team for a structured assessment.
