IEC 62443 Zones and Conduits Explained: How to Actually Segment an OT Network in 2026

Diagram of an IEC 62443 zone-and-conduit network segmentation model, showing an OT/control zone and an IT/enterprise zone separated by an OT DMZ, with a unidirectional conduit carrying one-way historian data into the DMZ and a filtering conduit brokering bidirectional traffic between the DMZ and the IT zone.

A zone in IEC 62443 is a group of assets that share the same security requirements and the same target Security Level; a conduit is the controlled, defined communication path that connects one zone to another (or to an outside network). Together, zones and conduits are the core segmentation model the standard uses to contain an intrusion to the part of the network where it starts — instead of letting it spread across a flat OT network. The hard part isn't the definition, it's the design sequence: deciding where zone boundaries actually go, and that starts with asset criticality, not with a firewall diagram.

By The Whitepaper Skeptic — mapped zone boundaries and DMZ placement on live production networks

Quick Facts

Question Answer
What is a zone? A group of assets sharing the same security requirements and target Security Level (SL-T)
What is a conduit? A controlled, defined communication path between two zones, or between a zone and an outside network
How many Security Levels are there? Four (SL-1 to SL-4), running from protection against casual/coincidental exposure up to protection against sophisticated, well-resourced attackers
Does this replace the Purdue Model? No — 2026 commentary treats them as complementary: Purdue's layers still describe where zone boundaries sit, with zero-trust identity checks layered inside each zone
What's the actual design sequence? Asset inventory → criticality/risk assessment → SL-T assignment → zone boundaries → conduit and DMZ placement

Zones and Conduits, Defined Properly

IEC 62443 (the ISA/IEC series of standards for industrial automation and control systems security) organizes an OT network into zones — logical or physical groupings of assets, like all the PLCs and HMIs on a single production line — that share a common security posture. Every zone gets assigned a target Security Level, and every asset inside that zone is expected to be protected to that level.

A conduit is the mechanism that lets two zones (or a zone and the outside world) talk to each other at all. Nothing crosses a zone boundary except through a defined conduit, and every conduit is a place where you can inspect, filter, or log traffic. That's the entire point of the model: instead of one flat network where any device can reach any other device, you get a set of contained cells connected by a small number of monitored doorways.

This is the same vocabulary the manufacturing ransomware post-mortems in this cluster use to describe what went wrong — a flat network, or a conduit that wasn't actually filtered — but that piece stops at diagnosis. This one covers how the zones and conduits actually get drawn.

The Actual Design Sequence

Vendor blog posts about zones and conduits tend to jump straight to a network diagram with colored boxes. In a real architecture review, the diagram is the last step, not the first. The sequence looks like this:

  1. Asset inventory. You cannot assign a security level to an asset you don't know exists. This is the input that the OT asset management spoke in this cluster covers in detail — if that inventory is incomplete, everything downstream of it is built on a guess.
  2. Criticality and risk assessment. For each asset (or logical group of assets), estimate the consequence of compromise — safety impact, production downtime, and how exposed the asset already is. This is what determines the target Security Level, not a generic checklist.
  3. Security Level assignment (SL-T). Each candidate zone gets a target Security Level based on the criticality assessment above. A safety-instrumented system controlling a physical process gets a higher SL-T than, say, a historian server that just logs data for reporting.
  4. Zone boundaries. Group assets that share the same SL-T and the same operational function into a zone. In practice this usually follows existing physical or functional lines — a single production cell, a single Purdue level, a single vendor's control system — rather than being drawn arbitrarily.
  5. Conduit and DMZ placement. For every pair of zones that legitimately need to communicate, define a conduit — and put a filtering or monitoring control on it. Where OT needs to exchange data with IT or the internet (an MES pulling production data, a vendor needing remote access), that's where an OT DMZ goes.

The most common design mistake isn't skipping zones — it's skipping steps 1 and 2 and jumping straight to step 4, which produces a segmentation diagram that looks correct but doesn't actually match where the real risk is concentrated.

I've made that jump myself. One review I worked started from the segmentation diagram that already existed, because it was drawn and it looked defensible; when we went back and scored criticality properly at step 2, a single "cell" on that diagram turned out to hold both a safety-related function and a reporting historian — two different SL-T answers inside one boundary, which is a zone that can't be satisfied at either level. The diagram wasn't wrong about where the switches were. It was wrong about what belonged together, and there's no way to see that without doing steps 1 and 2 first.

How to Design an OT DMZ

An OT DMZ is a conduit pattern, not a separate concept: it's a buffer zone that sits between the OT zone and the IT/internet-facing zone, so nothing connects directly from one side to the other. The design pattern that keeps coming up in practice:

  • Nothing in the OT zone initiates a connection to the IT zone or the internet directly.
  • Anything that needs to cross (a historian replicating data upward, a vendor needing remote access, an MES/ERP integration) terminates in the DMZ first.
  • The DMZ hosts jump servers, data replication servers, or patch-management relays — never production control assets.
  • Remote vendor access is brokered through the DMZ with time-limited, logged sessions, not a standing VPN straight into the control network.

This is also the boundary where the 2026 debate about IIoT and cloud-connected analytics is sharpest: as more OT data gets pulled into cloud dashboards and more vendors want remote access for predictive maintenance, the DMZ is the conduit that has to absorb that traffic without becoming a direct tunnel into the control zone. The IEC 62443 series formally extended into this territory with IEC PAS 62443-1-6:2025, "Application of the 62443 series to the Industrial Internet of Things (IIoT)," published December 2025 — it doesn't replace the zones-and-conduits model, but it maps existing IEC 62443 requirements onto IIoT communication patterns and points asset owners to the relevant clauses across the series for cloud-connected and remotely-managed field devices.

IEC 62443 Security Levels (SL-1 to SL-4)

Security Levels are the input that determines how a zone gets protected — they're not decided after the zone boundary is drawn, they're decided first and the boundary follows.

Security Level Protects against
SL-1 Casual or coincidental violation
SL-2 Intentional violation using simple means, with low resources and generic skills
SL-3 Intentional violation using sophisticated means, with moderate resources and IEC 62443-specific skills
SL-4 Intentional violation using sophisticated means, with extended resources, IEC 62443-specific skills, and high motivation

The part-number split is IEC 62443-3-2 for zone and conduit partitioning and risk assessment (the clause structure there — Clause 4, the "zone and conduit requirements" — is what drives asset grouping and SL-T assignment) and IEC 62443-3-3 for system security requirements and security levels, which is where the SL-1 through SL-4 definitions above actually live. In practice, most organizations don't assign SL-4 to anything outside of national-critical infrastructure; the vast majority of industrial zones land at SL-1 through SL-3.

Conduit Types: Filtering vs. Unidirectional

"Filtering conduit" and "unidirectional conduit" aren't defined line-items in the IEC 62443-3-2 normative text itself — the standard's own language stays at the level of "conduit" plus a risk assessment for it. The two-way/one-way split below is descriptive shorthand that shows up consistently in implementation guidance and adjacent technical specs — including CLC/TS 50701, the related European rail-cybersecurity standard, whose informative Annex A ("Handling conduits") names a similar three-way split: a transparent gateway conduit (connecting zones of the same security level), a filtering conduit as a firewall appliance, and a unidirectional conduit as a data diode or network tap — worth knowing as practitioner vocabulary, but don't cite it as a literal IEC 62443 clause term:

Conduit type How it works Typical use
Filtering conduit Firewall or industrial protocol-aware gateway inspects and allows/blocks traffic in both directions Zone-to-zone communication that's genuinely bidirectional (e.g., HMI polling a PLC)
Unidirectional conduit Data diode or network tap physically allows traffic in one direction only One-way data export (e.g., historian data leaving OT for a cloud dashboard) where inbound traffic should be impossible, not just blocked

The unidirectional pattern is the stronger control precisely because it removes the return path entirely — there's no firewall rule to misconfigure because there's no physical path back in.

Purdue Model vs. Zones and Conduits in 2026

These aren't competing frameworks — the Purdue Model (originally a reference architecture for layering enterprise, DMZ, and control-system networks) describes where zone boundaries typically sit, and IEC 62443's zones-and-conduits model is the segmentation and risk-assessment method applied within that layered structure.

Aspect Purdue Model IEC 62443 Zones and Conduits
What it is Reference architecture — layered network levels (enterprise, DMZ, site, cell/area) Standard-based segmentation and risk-assessment method
What it defines Where network layers sit relative to each other How assets within any layer get grouped and protected
2026 relevance debate Criticized for assuming clean layer boundaries that IIoT and cloud/vendor remote access increasingly cross Not in question as a model, but SL-T assignment must account for new IIoT/cloud conduits Purdue didn't originally anticipate

There's active 2026 industry discussion — 4Secure's commentary on the Purdue Model being a specific example — over whether the classic Purdue layering still holds up given how often IIoT devices and vendor remote-access tools now cross its boundaries by design. The emerging position in that discussion isn't "replace Purdue," it's "keep Purdue's layering logic for where zone boundaries sit, and layer zero-trust identity and access verification inside each zone" rather than assuming a device is trustworthy just because it's inside the perimeter.

Segmentation Maturity Is Still Catching Up

Fortinet's 2026 State of Operational Technology and Cybersecurity report, based on a survey of 700+ OT professionals, found that full OT visibility rose from just 5% in 2025 to 14% in 2026, while 23% of respondents still see only about half of their OT environment. The share of respondents rating their own security maturity at the top tier actually dropped, from 49% to 17% — which Fortinet reads as more honest self-assessment catching up with reality rather than an actual regression. Segmentation is described in the same report as an increasingly baseline control, tied to lower business disruption when incidents do occur.

That visibility gap is exactly why the design sequence above starts with asset inventory rather than a network diagram — you cannot draw a zone boundary around assets you can't see, which is the same gap the OT asset management spoke walks through in more depth.

FAQ

Q: What are zones and conduits in IEC 62443?
A: A zone is a group of assets that share the same security requirements and target Security Level; a conduit is the defined, controlled communication path connecting one zone to another (or to an outside network). Together they're the core segmentation model IEC 62443 uses to contain intrusions.

Q: Is the Purdue Model still relevant compared to IEC 62443 zones and conduits?
A: They're not competing models. Purdue describes where network layers and zone boundaries typically sit; IEC 62443's zones-and-conduits model is how you assess risk and group assets within that structure. 2026 industry commentary treats the two as complementary — Purdue's layering logic stays, with zero-trust identity verification added inside each zone to cover IIoT and vendor remote-access paths that cross Purdue's original boundaries.

Q: What are IEC 62443 security levels (SL-1 to SL-4)?
A: They're a four-tier scale describing the sophistication of attacker an asset or zone needs to be protected against — from SL-1 (casual or coincidental violation) up to SL-4 (a well-resourced, highly motivated attacker with specialized skills). The target Security Level for a zone is what determines how strictly it needs to be protected, and it's assigned before the zone boundary is drawn, not after.

Q: How do you design an OT DMZ?
A: An OT DMZ is a buffer zone between OT and IT/internet-facing networks — nothing connects directly across it. Anything that needs to cross (data replication, vendor remote access, MES/ERP integration) terminates in the DMZ first, on dedicated jump servers or replication servers, never on production control assets.

Q: What's the difference between a filtering conduit and a unidirectional conduit?
A: A filtering conduit (typically a firewall or protocol-aware gateway) inspects and allows or blocks traffic in both directions. A unidirectional conduit (a data diode or network tap) physically permits traffic in only one direction, so there's no return path to misconfigure — it's the stronger control for one-way data flows like historian exports to a cloud dashboard.

Sources

Author Bio

The Whitepaper Skeptic has direct experience with OT cybersecurity in industrial and smart-factory environments, including customer-facing security architecture reviews that involved mapping zone boundaries and conduit/DMZ placement across live production networks — using asset criticality inputs from the kind of ICS inventory work covered in the asset-management spoke below, and running into the same flat-network gaps that show up repeatedly in the ransomware case studies spoke.

Related Posts

Tags

IEC 62443, OT network segmentation, zones and conduits, ICS security, OT cybersecurity

Comments

Post a Comment

Popular posts from this blog

OT Security Vendor Comparison 2026: Dragos vs. Claroty vs. Nozomi Networks for Industrial Environments

Image
Dragos, Claroty, and Nozomi Networks were all named Leaders in the 2026 Gartner Magic Quadrant for CPS Protection Platforms — so "which one is best" isn't the right question, because Gartner didn't rank a single winner among them. The real decision driver is environment fit: Dragos leans strongest on ICS-specific threat intelligence and managed detection for concentrated, high-criticality sites; Claroty covers the broadest scope across OT, IoT, building systems, and medical devices; and Nozomi Networks offers the most flexible deployment options for large, multi-site, geographically distributed operations. This guide builds a vendor-neutral decision matrix around those differences instead of repeating any vendor's self-reported ranking. Quick Facts Question Answer Are all three Gartner Leaders? Yes — Dragos, Claroty, and Nozomi Networks were three of only four vendors named Leaders in the 2026 Gartner Magic Quadrant for CPS Protection Platforms, out o...
Read more

HBM Burn-In Testing Explained: Why Known-Good-Die Screening Now Happens Before Stacking (2026)

Image
HBM burn-in and known-good-die (KGD) testing means every individual memory die is electrically stressed and screened at the wafer level — before it's thinned, singulated, or stacked — instead of waiting to find defects only after a finished HBM stack fails final test. The reason this matters is economic, not just technical: a single bad die inside an 8-to-16-high HBM stack can force the entire stack to be scrapped, and HBM now accounts for roughly half the total cost of an AI accelerator package. That's why HBM makers and test-equipment vendors have visibly shifted testing "left" — earlier in the manufacturing flow — rather than relying on final test alone to catch problems. By The Whitepaper Skeptic — yield-economics work on an advanced-packaging project, plus HBM test-equipment tracking Quick Facts Question Answer What does "known-good-die" (KGD) mean? A die individually tested and verified to mee...
Read more

CoWoS and Hybrid Bonding Explained: TSMC's Advanced Packaging Behind AI Chips

Image
CoWoS (Chip-on-Wafer-on-Substrate) is TSMC's 2.5D advanced packaging platform — it places a large logic die, like an AI accelerator or GPU, next to multiple HBM memory stacks on a shared interposer, all inside one package. Hybrid bonding is a different thing entirely: a bump-less, direct copper-to-copper die-to-die (or die-to-wafer) bonding technique used for 3D stacking. They are not competing options, even though a lot of existing coverage frames "CoWoS vs hybrid bonding" as an either/or choice — CoWoS is a packaging platform, hybrid bonding is a bonding technique, and TSMC increasingly combines both inside the same package, most visibly in Nvidia's newest AI accelerator platforms. Quick Facts Question Answer What is CoWoS? TSMC's 2.5D packaging platform that places a large logic die and HBM stacks side-by-side on a shared interposer What is hybrid bonding? A bump-less, direct copper-to-copper die-to-die/die-to-waf...
Read more