Network Segmentation – Zonen & Conduits (IEC 62443)
What Are Zones and Conduits?
Zones and conduits are the foundational security model of IEC 62443 — the international standard for securing industrial automation and control systems (IACS). They define how a production network is divided into protected areas and how communication between those areas is controlled.
The core principle: not every system is allowed to communicate with every other system. Only connections that are operationally necessary are explicitly permitted — everything else is blocked by default.
What Is a Zone?
A zone is a logical or physical grouping of systems and components that share similar security requirements — the same criticality, the same availability demands, or comparable threat exposure.
Within a zone, a shared trust level applies. Everything outside is treated as potentially untrusted and subject to strict access rules.
Typical Zones in Industrial Production
| Zone | Contents |
|---|---|
| Cell/Area Zone (Level 2) | PLCs, HMIs, I/O devices, drives |
| Site Operations Zone (Level 3) | MES, historian, central OT services |
| Enterprise Zone (Level 4) | ERP, IT services, cloud connectivity |
| Remote Access Zone | Jump hosts, remote maintenance — isolated and tightly controlled |
What Is a Conduit?
A conduit is the controlled communication path between two or more zones. It is not a single cable or device — it is the complete set of technical controls that govern that communication channel: firewall rules, proxies, protocol brokers, VPN connections, and intrusion detection systems.
Rule of thumb: Zone = protection area. Conduit = controlled crossing.
Why Zones and Conduits Matter Operationally
Zones and conduits implement least-privilege networking — only the connections that are genuinely required exist. The practical outcomes are concrete: the attack surface shrinks because lateral movement across the network is blocked by design. Failures stay localized — a compromised production cell doesn't take down the entire plant. And integrations become auditable: it's always documented who can talk to whom, and why.
For cloud MES integrations specifically, the zone model defines the exact handoff point — typically via an Industrial DMZ — where production data becomes available to higher-level systems without exposing the OT core network.
Typical Architecture Examples
Production line ↔ MES: Two zones (Cell/Area and Site Operations) connected by a conduit that allows only defined data flows — production status upward, order data downward — through controlled relay points, not open routes.
OT ↔ IT via Industrial DMZ: Three zones (OT Core, DMZ, IT Enterprise) with two separate conduits. IT-side processes like updates, cloud connectivity, or BI tools have no direct path into the production network.
Remote access: A dedicated Remote Access Zone with a jump host as the sole entry point. The conduit allows time-limited, approved sessions into defined target zones — with full logging. Vendor VPNs that terminate directly inside the OT subnet do not meet this model.
How to Build Zones and Conduits: 4 Practical Steps
Step 1 — Define the System Under Consideration (SUC). Establish which plants, networks, and services are in scope. Without a clear boundary, no consistent zone model is possible.
Step 2 — Cut zones by security requirement, not org chart. Base the boundaries on availability, integrity, and consequence requirements — not on who owns the system. Output: an initial zone diagram.
Step 3 — Model communication needs as conduits. For each zone-to-zone connection, document: who initiates, which protocols and ports, data direction, frequency (real-time, periodic, on-demand), and which security controls apply (allowlisting, authentication, logging).
Step 4 — Derive security levels and select controls. IEC 62443 uses risk-based Security Levels (SL) to define which technical controls each zone and conduit must enforce.
Common Implementation Mistakes
Treating VLANs as sufficient segmentation. VLANs without hard policy enforcement and monitoring are organizational tidiness, not a security barrier.
Defining zones by device name instead of protection need. Grouping a PLC, HMI, engineering workstation, and file server into one zone because they're "in the same area" leads to either unmanageable rule sets or dangerously broad permissions.
Building conduits without a defined communication list. "We'll put a firewall in between" without explicit flows almost always collapses into any-any rules the moment operational pressure mounts.
No ownership for rule maintenance. Without clear accountability for reviews and change management, the rule set degrades within months.
FAQ
What's the difference between a zone and a network segment? A network segment (e.g., a VLAN) is a technical subdivision. A zone under IEC 62443 is a security-oriented construct tied to a full set of access controls and requirements. Segments can be part of a zone but don't replace one.
Does every machine need its own zone? No. Machines with identical security requirements can be grouped into the same zone. Over-segmentation creates unnecessary complexity without a proportional security gain.
How does the zone model apply to cloud MES integration? The cloud MES connection is modeled as a conduit between the Site Operations Zone (or DMZ) and the Enterprise/Cloud Zone. Data access happens at validated relay points — never directly at the OT level.

