In IEC 62443, a zone is a group of assets that share the same security requirements, and a conduit is the controlled communication path between zones. IEC 62443-3-2 describes how to define the system under consideration, partition it into zones and conduits, assess the risk for each and assign a target security level (IEC 62443-3-2:2020). Done well, zoning turns a flat factory network, where one infected laptop can reach every PLC, into a set of compartments with known doors.
This guide explains the concepts with a worked example: a mid-sized food packaging plant with three lines. It is the kind of plant we see often in NIS2 gap assessments.
The parts of IEC 62443 you actually need
| Part | Focus | Who uses it |
|---|---|---|
| 62443-3-2 | Risk assessment, zones and conduits, target security levels | Asset owner, integrator |
| 62443-3-3 | System security requirements and security levels | Integrator, asset owner |
| 62443-4-1 | Secure product development lifecycle | Product suppliers, machine builders |
| 62443-4-2 | Technical security requirements for components | Product suppliers |
IEC 62443-3-3 maps its system requirements to seven foundational requirements and defines capability security levels (IEC 62443-3-3:2013). The four security levels, SL 1 to SL 4, rise with the capability and resources of the attacker you want to resist. You set a target level (SL-T) per zone, and the components and countermeasures in that zone must achieve it. The ISA overview of the 62443 series is a useful map of all parts.
How to define IEC 62443 zones and conduits step by step
- Define the system under consideration. Draw the boundary: which lines, buildings and connections are in scope, and where the interface to office IT and the outside world sits.
- Inventory the assets. Every PLC, HMI, drive, switch, router, server and engineering PC. Without this, zoning is guesswork. See our OT asset inventory guide.
- Run an initial risk assessment. What is the worst credible outcome if the system is compromised: safety, quality, downtime, data?
- Group assets into zones. By function, criticality, location and who manages them. Safety systems usually deserve their own zone.
- Define conduits. For each pair of zones that must communicate, list the protocols, directions and endpoints. Everything else is denied.
- Assess each zone and set SL-T. Then compare with what the installed equipment can achieve and close the gap with countermeasures.
Worked example: a three-line packaging plant
| Zone | Contents | Allowed conduits |
|---|---|---|
| Enterprise | ERP, email, office PCs | To OT DMZ only: production orders, reports |
| OT DMZ | Historian replica, patch server, remote access jump host | To enterprise and to supervisory zone |
| Supervisory | SCADA servers, MES client, engineering workstation | To each line zone: OPC UA, S7 communication |
| Line 1, 2, 3 | PLCs, HMIs, drives, vision systems of one line | To supervisory only; no line-to-line traffic |
| Safety | Safety PLCs and safety networks | Read-only status to the line zone |
This follows the layered model with an OT DMZ at level 3.5 that the BSI also uses in its ICS Security Compendium. Nothing in the enterprise zone talks to a PLC directly. Remote access from a machine builder ends at the jump host in the DMZ, not at a router inside the line.
Two choices in this design are worth explaining. Lines are separate zones because a problem on line 2 should not stop lines 1 and 3, and because each line was often supplied by a different machine builder with a different remote service arrangement. And the engineering workstation sits in the supervisory zone, not on the office network, because it can change every PLC in the plant.
ISAGCA Cybersecurity Risk Assessment ANSI/ISA 62443-3-2
International Society of Automation - ISA
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeHow to document a conduit
Every conduit needs a short record that maintenance and IT can both read. We use one line per allowed flow, with these fields:
- Source zone and device, destination zone and device.
- Protocol and port, for example OPC UA on TCP 4840 or S7 communication on TCP 102.
- Direction and whether the flow may write or only read.
- Business reason, such as production orders from MES or recipe downloads.
- Owner, review date and the firewall rule that enforces it.
This list becomes the firewall rule set, the evidence for auditors and the reference for the next machine builder who asks for a port to be opened.
Common mistakes we see
- Zones drawn on paper only. If the switches still forward everything, the zones exist in a slide deck, not in the plant.
- One zone per VLAN, hundreds of VLANs. Over-segmentation that nobody can maintain. Start coarse and refine.
- Forgetting the engineering laptop. The service technician's laptop crosses every zone. Give it a defined path or a dedicated station.
- Ignoring the machine builder's router. Old remote maintenance routers bypass every zone you design. Inventory them first.
- No owner per conduit. Rules without an owner are never reviewed and slowly open up.
Zones and conduits for NIS2 and the Machinery Regulation
For plants covered by NIS2 in Germany, a documented zone and conduit model is one of the most convincing pieces of risk management evidence you can show. For machine builders, the same thinking applies inside the machine: separating the safety network, the machine network and the service access point is a good answer to the Machinery Regulation's requirement that control systems withstand foreseeable malicious attempts.
Wartens designs network zoning and runs gap assessments based on IEC 62443 for manufacturers in Germany, as part of our automation engineering services. Next step: send us your network drawing and asset list, and we will sketch a first zone model with you. Contact us.
