IEC 62443 defines 4 security levels, 7 foundational requirement categories, and 2 network-control structures: zones and conduits.
A practical plant model separates enterprise, plant, process, and field zones, then controls every required path with a defined conduit.
What IEC 62443 zones and conduits actually define
An IEC 62443 zone is a collection of physically or functionally united assets that share common security requirements [S1][S4]. The boundary is not drawn around an arbitrary equipment list; it is established through risk analysis so assets with compatible protection needs can be governed as a unit [S1][S3].
A conduit is the controlled connection between zones and may be logical, physical, electronic, or process-based [S2][S4][S7]. ISA/IEC 62443-3-3 also describes it as a grouping of communication channels connecting 2 or more zones with shared security requirements [S2]. An undocumented cable, vendor laptop connection, or temporary maintenance link is not an approved conduit simply because data can pass through it.
The distinction is architectural. A zone groups what must be protected similarly; a conduit defines how protected groups interact [S5]. IEC 62443 supports geographic organization and functional grouping, with functional separation common in process plants [S3].
How the four security levels shape the target
IEC 62443 defines security levels SL 1 through SL 4, and Part 3-3 defines system security requirements and security capability levels [S3][S4]. The risk assessment establishes a security level target, or SL-T, for the applicable zone and conduit [S3][S5].
Part 3-3 translates foundational requirements into system requirements and requirement enhancements for meeting the target security level [S4].
SL-T states the protection required, while SL-A describes the capability actually achieved [S5]. That distinction exposes an important design issue: a conduit intended to reach SL-T cannot be accepted merely because it connects two network segments. The protection must be demonstrated against the applicable requirements.
Plant example: four zones and five controlled paths
Consider a production plant with an enterprise network, a plant operations network, a process-control network, and a field network containing controllers and instruments [S3]. These 4 layers provide an initial segmentation model, not a finished risk assessment.
The enterprise zone contains corporate IT services. The plant operations zone contains engineering workstations, historian services, and maintenance applications. The process zone contains PLCs, safety-related controllers, and process servers. The field zone contains devices connected to actuators, transmitters, and motor starters.
The 5 required communication paths can be defined as controlled conduits: enterprise-to-plant reporting, plant-to-process engineering access, process-to-field control traffic, plant-to-remote maintenance, and process-to-historic data collection. Each conduit needs an owner, approved protocol, permitted direction, authentication method, monitoring point, and defined behavior during loss of communications.
This layout also prevents a common mistake: putting every production asset into one “OT” zone because it is operationally related. A process controller and an Internet-facing engineering service do not automatically share the same protection requirements.
Selecting zone boundaries with risk-based criteria
Initial segmentation should separate assets by major function before the detailed cyber-risk work [S1][S3]. For each candidate zone, document the assets, their security requirements, required communications, consequences of compromise, and responsible operating function.
Geographic separation can support the design, but geography alone does not prove that assets have common protection needs.
Do not force every device into a small zone either. Excessively fine boundaries increase the number of conduits and administration burden, while oversized zones can combine assets with incompatible access and availability requirements [S3][S6]. The practical result should support risk treatment, not merely produce a large network diagram.
Designing conduits for controlled communication
IEC 62443 designates the technical means of communication and control of communication flow between zones as conduits [S7]. A conduit therefore includes more than the media; it includes the logical path and the controls governing that path.
Where communication crosses zones with different security levels, the architecture must make the protection mechanism explicit because IEC 62443 provides limited guidance on exactly how conduit requirements apply [S3].
Physical separation is not required for every conduit, because a conduit can also be logical or process-based [S2][S4]. Engineering controls are still required, including least privilege and layered defense for the communicating systems [S4]. The standard remains framework-based rather than a product checklist, so it does not certify a firewall, switch, or software version as secure by itself [S5].
Zone, conduit, and flat-network comparison
Compared with a flat OT network, IEC 62443 zoning improves control of asset grouping and inter-zone communication, while conduits make each connection visible and governable [S3][S5]. The comparison below evaluates 3 architectures against segmentation, path control, and implementation burden.
The architecture that provides the strongest control is not automatically the cheapest for a small installation. A machine with 1 controller and 1 operator interface may need only a small number of controlled paths, but every path still needs an owner and documented security treatment. The applicable count follows the plant architecture, not a universal standard.
Who should own the zoning work
The asset owner is responsible for risk assessment, zoning, and operation; the system integrator performs secure integration and provides implementation evidence; the product supplier provides secure-development documentation, technical requirements, and patches [S5]. IEC 62443 divides the work by role, and an asset owner cannot transfer its own obligations to a supplier [S5].
This model suits plants with mixed IT and OT ownership, shared responsibility between engineering and operations, and suppliers connected to production assets. It also suits organizations that need to demonstrate control through documentation rather than rely on an informal promise that a network is “segmented.”
It is not a substitute for process hazard analysis, functional safety work, or asset-specific security controls. A zone can contain equipment with different availability and safety consequences, while a conduit can carry data whose safety effect is independent of its cyber exposure. The cyber architecture must therefore remain consistent with the plant’s safety and operating design.
Common implementation failures and corrective checks
The first failure mode is treating every switch port as a conduit boundary. Segmentation by hardware alone does not establish common security requirements, and undocumented physical or logical links can bypass the intended architecture [S3][S5].
The second is confusing separation from control. A firewall can enforce rules, but the project still needs a defined source, destination, purpose, protocol, direction, identity model, and fallback behavior for the path [S3][S7].
The third is applying the same security level mechanically to every zone. IEC 62443 is risk-based, so the SL-T for a zone and its conduits follows the assessed risk and applicable foundational requirements, not a plant-wide label [S3][S4].
Documentation should also capture temporary vendor connections, removable media procedures, and remote-support sessions, since informal links often defeat otherwise sound segmentation [S5].
Track two measurable signals after commissioning: the percentage of live inter-zone paths mapped to approved conduits, and the number of active undocumented paths found during audits. These measures expose whether the architecture exists on paper or in the installed plant.