Skip to content

Compliance

IEC 62443 zones and conduits: how to apply it to a real plant without a year of consulting

IEC 62443 is often seen as out of reach for SMEs. Yet zones and conduits are practical tools you can apply to real plants, starting from visibility and reaching formal segmentation step by step.

5 min read

Why IEC 62443 scares SMEs

IEC 62443 is the international reference standard for the security of industrial control systems and OT networks. It is structured as a series of technical documents (the parts of the 62443 series) that address different aspects: risk management, system requirements, component requirements, and the secure product development process.

Looking at the full structure of the standard, the typical reaction in a manufacturing SME is discouragement: dozens of normative documents, hundreds of requirements, security levels (SL) to verify on every component. The result is often paralysis: the standard is perceived as something for large organizations with a dedicated team of security engineers, not for those running a plant with limited resources.

This perception is wrong, or at least incomplete. Two fundamental IEC 62443 concepts, security zones and conduits, are practical tools that can be applied even in mid-sized plants. They do not require implementing the entire framework: they require thinking about the structure of the OT network with a different logic.

Security zones: grouping by risk level

The concept of a security zone in IEC 62443 is simple in essence: group the assets that share the same risk level and the same security requirements, and treat them as a homogeneous unit.

Two assets belong to the same zone if they:

  • Have similar functions within the industrial process
  • Require the same level of protection
  • Share the same access requirements (who can enter, how, when)
  • Are subject to the same operational constraints in the event of an incident

In a typical manufacturing plant, you can identify zones such as:

Field Zone: sensors, actuators, intelligent field devices that interact directly with the physical process. These devices often have limited security capabilities (no authentication, no encryption), communicate over simple protocols (Profibus, HART), and their life cycle is measured in decades. They require robust perimeter protection because they cannot protect themselves.

Control Zone: PLCs, RTUs, DCS that run the control logic. This is the level where the decisions that affect the physical process are made. Access to this zone must be tightly controlled: anyone who can modify the logic of a PLC must be identifiable and authorized.

Supervisory Zone: HMIs, SCADA, operator workstations. This is the level where human operators interact with the system. It often contains Windows-based workstations running commercial SCADA software.

Storage and historization zone: historians, process databases, reporting systems. These systems aggregate data from the process and make it available to corporate IT or to analytics systems.

OT DMZ: a buffer zone between the OT network and the IT/enterprise network. It hosts the systems that need to communicate in both directions: data servers, integration systems, proxies.

Dividing the network into zones does not need to be complex to be useful. Even an organization starting from scratch can make a reasonable first grouping based on the function of the assets and their level of risk exposure.

Conduits: the authorized communications between zones

A conduit is the authorized communication channel between two zones. It is not just a physical network connection: it is an explicit definition of what can pass between zones, in which direction, with which protocol and with which controls.

For each conduit you must define:

  • The two zones it connects
  • Which protocols are authorized (and which are explicitly blocked)
  • The flow direction (unidirectional or bidirectional)
  • Who is authorized to use it (specific systems, not entire subnets)
  • How the traffic passing through it is monitored and logged

A concrete example: between the SCADA supervisory zone and the historian zone, the conduit might authorize only OPC-DA or OPC-UA traffic outbound from the SCADA zone to the historian (writing process data), blocking any connection in the opposite direction. SMB, RDP, and HTTP traffic to or from the historian toward SCADA is not needed for the operational function and should be blocked.

Defining the conduits means making explicit what is implicit or unconscious today. In most undocumented plants, the communication flows between zones already exist, but they have never been formalized: everything is authorized by default because no one has ever defined what is not.

How to start from scratch: visibility before segmentation

The pragmatic approach for those who have no documentation of their OT network follows three phases in sequence.

Phase 1: visibility

Before drawing zones and conduits, you need to know what is on the network. Passive OT traffic monitoring lets you build an asset inventory (with IP addresses, protocols used, communication behavior) without interfering with the production process. This phase answers the fundamental questions: how many devices there are, of what type, with whom they communicate, on which protocols.

Without this baseline, any design of zones and conduits is theoretical and potentially wrong.

Phase 2: identifying the zones

With the inventory in hand, you can make a first grouping of the assets into candidate zones. It does not need to be perfect on the first attempt: it is a living document that is refined over time. The goal of the first iteration is to have a basic structure that reflects the reality of the plant, not an ideal theoretical model.

Surprises often emerge in this phase: assets believed to be in a separate zone that instead communicate freely with adjacent zones, legacy systems talking to unexpected destinations, forgotten devices that no one knows exactly what they do.

Phase 3: defining and implementing the conduits

With the zones identified, you define the conduits: which traffic is necessary between which zones. You start from the critical conduits (vendor remote access, IT-OT connections, SCADA access) and build the list of authorized flows. All traffic not on the list is a candidate to be blocked or at least monitored carefully.

The technical implementation of the conduits translates into firewall rules (or segmentation via VLANs and routers) that reflect the defined policy. Passive OT monitoring verifies that the conduits behave as expected and detects deviations.

From zones and conduits to formal IEC 62443 rules

Once the zones and conduits are defined and implemented, you have a foundation on which to build formal IEC 62443 compliance.

The standard defines four security levels (SL 1-4) for zones: from SL 1 (basic protection against unintentional attacks) to SL 4 (protection against state-level attacks with sophisticated resources). Most manufacturing plants aim for SL 2 for critical control zones, which requires protection against deliberate attacks with moderate resources and motivation.

The technical requirements associated with each IEC 62443 security level become much more manageable when you work zone by zone, rather than trying to apply the standard to the entire network as a single block. For each zone you verify which technical requirements apply based on the target level: access authentication, encryption of communications between zones, configuration integrity.

This approach lets you start building IEC 62443 compliance incrementally: first the most critical zones (control, supervisory), then those with less stringent requirements (field, historian). It is a measurable path with verifiable results at every step, not a monolithic project that takes years before producing value.

The difference between a haphazard OT plant and one structured according to IEC 62443 zones and conduits is not only formal compliance. It lies in the ability to answer precise questions: "if an attacker compromises the operator workstation, which systems can they reach?" With well-defined zones and conduits, the answer is known and controllable. Without them, the answer is "we don't know."

The MON5 angle

Visibility before segmentation: the three-phase sequence described in this article is the same one MON5 is built on. The DISCOVER phase derives the asset inventory and network topology from passively observed traffic, without interfering with production, and shows who really communicates with whom: the foundation for designing realistic zones instead of theoretical models.

In the ANALYZE phase, IEC 62443 zones and conduits become objects managed by the platform: continuous monitoring verifies that the conduits behave as defined and flags out-of-policy flows. To build the first zone map of your plant, start with an OT assessment.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.

Related articles

Audit document with technical evidence and OT system logs on screen

Compliance

How to Prove NIS2 Compliance in an Audit: The Technical Evidence That Really Counts

NIS2 is not proven with policies: it is proven with technical evidence. What auditors look for in an OT audit, how to prepare evidence before they arrive, and the role of continuous monitoring as documentary proof.

6 min read

Do you have visibility into your OT network?

MON5 maps assets, vulnerabilities and anomalies in real time — without stopping production.

Learn more about the regulation: IEC 62443

MON5.EU

OT (Operational Technology) cybersecurity for manufacturing plants. Map, identify, monitor and protect your industrial network.

🇮🇹MON5 S.R.L. · Italy
Bologna · Via Paolo Nanni Costa 20
Faenza · Corso Aurelio Saffi 21
VAT IT02725300392
🇱🇺AARG S.à.r.l. · Luxembourg
49, Boulevard Royal
L-2449 Luxembourg
VAT LU35998569
© 2026 MON5 · All rights reserved
Get certifications
Coesione Italia 21-27 Emilia-Romagna · Co-funded by the European Union · Ministero delle Imprese · Regione Emilia-Romagna