IEC 62443 Explained: Zones, Conduits, and Defense in Depth (A Practical OT/ICS Guide)

150

IEC 62443 uses zones and conduits to design secure industrial systems. A zone is a group of OT/ICS assets with similar security needs (risk, criticality, function). A conduit is the controlled communication path between zones, enforced with security controls like firewalls, allowlists, and monitoring. Together they enable defense in depth: limit trust, restrict traffic to what’s required, detect abnormal behavior, and reduce blast radius—without relying on a single perimeter. Implementing IEC 62443 typically starts with defining zones by consequence and function, documenting required data flows, then enforcing conduits with “deny by default” policies, strong remote access controls, and continuous monitoring.

What IEC 62443 is (and what it isn’t)

IEC 62443 (often written as ISA/IEC 62443) is a family of standards for securing industrial automation and control systems (IACS)—what most teams call OT/ICS.

What it is

IEC 62443 provides:

• a risk-based way to think about industrial cybersecurity,
• a common language for architects, engineers, security teams, and vendors,
• requirements that span the lifecycle: policies, system design, component capabilities, and operations.

A key contribution is the zones and conduits model, which gives a practical structure for OT segmentation and trust boundaries.

What it is not

IEC 62443 is not:

• a single checklist you “implement once,”
• a purely network standard (it includes process, people, technology),
• the same as the Purdue Model (they overlap conceptually, but they solve different problems),
• a guarantee that you will never have an incident.

Think of IEC 62443 as a framework that helps you move from “best effort security” to repeatable, defensible security engineering for industrial systems.

---

Why zones & conduits matter more than “flat OT networks”

Many OT networks evolved for reliability and uptime, not for adversaries. The default architecture in older environments often looks like:

• broad Layer 2 adjacency,
• permissive rules “because it works,”
• shared credentials and shared workstations,
• vendor remote tools with wide reach.

In a flat network, a single compromised engineering workstation, jump host, or OT server can become a launchpad for:

• lateral movement,
• ransomware spread,
• unauthorized controller interaction,
• loss of visibility (HMI/SCADA disruption),
• recovery chaos (too many dependencies to restore cleanly).

Zones and conduits solve a specific problem

They answer two foundational questions:

1. Where should trust exist? (zones)
2. How should communication be controlled and monitored? (conduits)

That’s the heart of OT defense in depth: reduce blast radius and make abnormal behavior easier to detect.

---

Zones explained (with OT examples)

A zone is a logical or physical grouping of assets that share:

• similar security requirements,
• similar risk/consequence levels,
• similar functionality,
• and similar operational needs.

Zones are not just VLANs. A zone is a security boundary: you define it, justify it, and control how traffic enters/leaves it.

What belongs in a zone?

A zone can include:

• PLCs, RTUs, drives, analyzers
• safety controllers and safety-related components
• HMIs and operator stations
• engineering workstations (EWS)
• SCADA servers, historians, OT application servers
• network equipment that is dedicated to that zone
• industrial IoT gateways or protocol converters

Common OT zone examples

Here are zone examples that map cleanly to how plants operate:

1) Cell/Area zone (production line or process unit)

A packaging cell, a mixing skid, a boiler unit, a compressor station—assets that work together and have shared operational consequences.

Why it’s a zone: it’s a natural blast-radius boundary. A disruption in Line 1 should not spread to Line 2.

2) Safety zone (SIS / safety PLC domain)

Safety functions often deserve their own zone(s) due to consequence and assurance needs.

Why it’s a zone: safety integrity and change control requirements are different.

3) Engineering zone

Engineering workstations and tools are high privilege. Putting them in their own zone makes their access:

• more controlled,
• more auditable,
• less likely to become “just another Windows PC.”

Why it’s a zone: compromise here is high leverage.

4) OT operations zone (Level 3-ish services)

Historians, OT domain services (if present), patch staging, application servers.

Why it’s a zone: these systems are often the “pillars” that ransomware disrupts, causing plant-wide visibility loss.

5) OT DMZ zone

A buffer between IT and OT where controlled integration happens:

• historian replication interfaces,
• file transfer services,
• remote access brokers/jump servers,
• update repositories, ticketing proxies.

Why it’s a zone: it allows IT/OT data exchange without making OT directly reachable.

How to decide zone boundaries (the practical rule)

Create separate zones when any of these differ meaningfully:

• consequence of compromise (safety, downtime, quality)
• required trust level
• protocol types and latency sensitivity
• administrative ownership (operations vs engineering vs IT)
• change frequency (static PLCs vs frequently updated Windows systems)

---

Conduits explained (with OT examples)

A conduit is the controlled communication path between zones. If zones define “where trust lives,” conduits define “how trust is allowed to flow.”

What a conduit includes

A conduit typically includes:

• policy (what is allowed, by requirement)
• enforcement points (firewalls, ACLs, proxies, gateways, data diodes)
• monitoring (logs, NetFlow, OT IDS/NDR sensors)
• management and change control (approvals, rule review, exception handling)

A conduit can be:

• a physical link between switches, protected by firewalling,
• a routed path with ACLs and monitoring,
• a unidirectional link (data diode) for one-way flows.

Conduit examples in OT

Example A: Cell zone ↔ OT operations zone

Allow:

• HMI/SCADA polling or subscriptions required for operations
• time sync (if required and safe)
• specific engineering traffic only from approved engineering zone (not from all of Level 3)

Block:

• general SMB file sharing
• broad RDP access
• any “any-to-any” rules

Example B: OT DMZ ↔ IT

Allow:

• historian replication to business analytics (prefer one-way or brokered flows)
• ticketing integration
• file transfer through controlled scanning and staging

Block:

• direct access from IT workstations to OT servers
• remote admin protocols into OT (unless through an approved jump host/bastion)

Example C: Engineering zone ↔ Controller zone

Allow:

• only the specific engineering protocols needed
• only from approved engineering workstations
• only during approved windows if your operations support it

Monitor heavily:

• controller write operations
• downloads/uploads
• mode changes

---

Defense in depth in IEC 62443: the real meaning

Defense in depth is often summarized as “multiple layers of security.” In OT, that’s true—but incomplete. The deeper meaning is:

Assume layers fail. Design so a single failure doesn’t become a plant-wide event.

Defense in depth across OT layers

A practical IEC 62443-aligned defense-in-depth design includes multiple control types:

• Preventive controls (block bad paths)
  • segmentation, allowlists, least privilege, hardening, application allowlisting
• Detective controls (see abnormal behavior early)
  • OT-aware monitoring, logs at conduits, alerting on controller writes/downloads
• Responsive controls (contain without stopping production)
  • boundary containment runbooks, targeted isolation, safe recovery sequencing
• Recoverability controls
  • offline/immutable backups, tested restores, golden images

Why zones & conduits are “multipliers”

A strong zone/conduit model:

• reduces the number of paths you must monitor,
• improves signal-to-noise (fewer allowed flows means anomalies stand out),
• makes containment safer (block at conduits, not by yanking cables blindly),
• supports compliance and audit defensibility.

---

IEC 62443 security levels and risk: how they influence segmentation

IEC 62443 introduces the idea of Security Levels (SL) to express how robust protections should be, based on threat capability and risk tolerance. You’ll see SL referenced in the IEC 62443 family in ways that help structure requirements.

The practical takeaway for architects

You do not need to memorize every clause to use the model correctly. The practical use is:

• some zones are higher consequence (safety, high downtime cost),
• those zones require stronger controls and tighter conduits,
• you can’t treat all assets equally—doing so wastes effort and still leaves gaps.

Security requirements become easier when zones are defined

When you define zones, you can apply stronger controls where they matter most:

• stricter access control for engineering and safety zones,
• more restrictive conduits into controller networks,
• tighter remote access governance for any zone that can reach Level 2 assets.

---

How zones & conduits relate to the Purdue Model

Many teams use the Purdue Model as a mental map (Levels 0–5). It’s useful—but it can also mislead if you assume “Level 3 = zone.”

Purdue is a reference model; zones are a security design

• Purdue helps describe where systems often sit in an industrial architecture.
• Zones and conduits define how trust and communication should be controlled, regardless of “level.”

The best way to combine them

Use Purdue for orientation and inventory, then design zones by:

• process function and consequence (cells/areas),
• trust differences (engineering vs operator vs server),
• and required communication paths (conduits).

Result: a design that matches operational reality and is defensible from a security standpoint.

---

A step-by-step method to build a zone/conduit architecture

This is the core “how-to” section: what an OT team can do even in brownfield environments.

Step 1: Inventory assets with roles (not just IPs)

Your inventory must include:

• asset role (PLC, HMI, EWS, historian, jump host, safety PLC, gateway)
• process association (line/unit/cell)
• site and location
• criticality and consequence tier
• owner (operations, engineering, IT, vendor)

If you only have IPs and hostnames, you’ll build zones that look nice on paper and fail in practice.

Step 2: Identify “crown jewel” functions and high-consequence zones

Examples of crown jewel outcomes:

• ability to safely start/stop a process
• safety function integrity
• product quality parameters and recipes
• centralized visibility and control
• engineering change capability

These inform which zones should be most restrictive.

Step 3: Draw the current-state data flows (what actually talks)

For each area, capture:

• source zone candidate → destination zone candidate
• protocol/port
• direction
• frequency/latency sensitivity
• business/operational justification (why it must exist)

This can be done by:

• passive network monitoring,
• firewall logs,
• switch telemetry,
• or a controlled discovery period.

Step 4: Define zones based on consequence + function

A pragmatic starting set for many plants:

• IT zone(s)
• OT DMZ zone
• OT operations (Level 3 services) zone
• Engineering zone
• Cell/Area zones (multiple)
• Safety zone(s)

Do not aim for perfection on day 1. Aim for boundaries that reduce blast radius and are operationally maintainable.

Step 5: Define conduits as “required flows only”

For each conduit, write a requirement statement:

• “Zone A must communicate with Zone B for purpose X using protocol Y from system list Z.”

Then turn that into:

• allowlists at firewalls/ACLs,
• user access rules (who may initiate sessions),
• monitoring requirements (what must be logged and alerted).

Step 6: Implement enforcement in layers (defense in depth)

A common implementation stack:

• perimeter/edge controls (IT/OT boundary)
• OT DMZ controls (broker services)
• internal OT conduit controls (L3-to-L2, engineering-to-cell)
• endpoint hardening (especially Windows systems)
• monitoring and alerting

Step 7: Validate with operations (the “does it still run?” phase)

Before enforcing strict rules, validate:

• operator visibility and control paths
• historian and reporting dependencies
• vendor support workflows
• maintenance window activities

A zone/conduit design that breaks operations becomes shelfware. Build with the process in mind.

Step 8: Establish change control and exception governance

Most segmentation failures come from:

• “temporary” rules that become permanent,
• vendor requests that bypass architecture,
• troubleshooting shortcuts.

Create:

• rule expiration dates,
• quarterly conduit reviews,
• an exception register with risk acceptance and compensating controls.

---

Design patterns: common zone models that work

Below are patterns that repeatedly work in real industrial environments. Use them as building blocks.

Pattern 1: Classic OT DMZ buffering

Goal: no direct IT-to-OT operations communication.

• IT ↔ OT DMZ conduit: controlled, logged, brokered
• OT DMZ ↔ OT operations conduit: strict allowlists
• No direct IT ↔ Level 3/Level 2 routes

Best for: most plants integrating with enterprise analytics, patching, and support.

Pattern 2: Per-line (or per-unit) segmentation

Goal: prevent line-to-line spread and reduce blast radius.

• each cell/line/unit is its own zone
• OT operations zone communicates to each unit via separate conduits
• engineering access to each unit is controlled and logged

Best for: manufacturing sites where one line stopping should not stop the plant.

Pattern 3: Engineering isolation

Goal: treat engineering capability as high risk.

• engineering workstations in a dedicated zone
• only engineering zone can reach controller programming interfaces
• strong identity controls and jump-host access for engineering remote work

Best for: environments where engineering tools are frequently used and frequently targeted.

Pattern 4: Safety segregation

Goal: reduce paths into safety functions.

• SIS zone with minimal conduits
• explicit, reviewed communication paths (if any) to BPCS/DCS
• strict governance for any remote access

Best for: high-hazard processes and regulated environments.

---

Conduit enforcement: what “good” looks like in practice

Conduits fail when they’re defined only in diagrams. “Good” conduits are enforced, monitored, and maintained.

The “deny by default, allow by requirement” principle

A strong conduit has:

• a small, justified set of allowed flows,
• explicit source/destination definitions,
• monitoring that alerts when something new appears.

Concrete conduit controls to consider

Pick controls based on operational constraints and risk:

• Industrial firewalls with strict rules and deep visibility
• Layer 3 ACLs (helpful but often insufficient alone)
• Application proxies (especially for file transfers)
• Jump hosts for administrative access
• Unidirectional gateways/data diodes for one-way requirements
• Protocol break/terminate (where possible)
• Rate limiting for certain conduits (situational)

What to log for conduit forensics (high value)

If you want investigations to be faster and less disruptive, log:

• allow/deny events with rule IDs
• session start/stop metadata
• NAT translations (if used)
• admin changes to firewall configs
• remote access session metadata (user → target → time)

These logs become your OT “black box recorder” for incident response.

---

Remote access in a zone/conduit world (vendors included)

Remote access is the most common reason conduits become overly permissive. IEC 62443-aligned designs treat remote access as a controlled pathway—not a convenience feature.

The secure remote access pattern (recommended)

• All remote users authenticate via an enterprise-controlled method (MFA)
• Sessions terminate in the OT DMZ on a jump host or access broker
• Access from OT DMZ to internal OT zones is allowlisted by:
  • user role,
  • target assets,
  • time window,
  • and protocol requirements
• Sessions are logged (and ideally recorded)

Vendor access: reduce permanent trust

Vendor access should be:

• named accounts (no shared credentials)
• time-bound approvals (ticket-based)
• restricted to specific targets
• routed through controlled brokers
• reviewed quarterly (accounts, usage, exceptions)

A practical “remote access acceptance test”

Your remote access design is meaningfully improved when:

• no one can reach controller networks directly from IT or the internet,
• every session has an attributable identity and MFA,
• the only path into OT zones is through controlled conduits,
• logs can answer: “who accessed what, when, and what changed?”

---

Monitoring and detection for zones & conduits (OT-aware)

Segmentation without monitoring is brittle. Monitoring without segmentation is noisy. Together, they produce high-confidence detection.

What to detect at conduits (high signal)

• new talkers between zones (unknown sources or destinations)
• protocol drift (new ports/services)
• abnormal SMB/RDP across conduits
• scanning behavior crossing zones
• unusual remote access times, locations, or devices
• controller write/download events originating from unexpected zones

Why OT-aware detection matters

In OT, the difference between “normal traffic” and “unsafe traffic” is often:

• the direction of a connection,
• whether it’s read-only vs write operations,
• whether it targets a programming interface,
• whether it occurred during a planned maintenance window.

Use asset role context: “PLC” is not just an IP; it’s a consequence-bearing device.

---

Common mistakes and how to avoid them

Mistake 1: Defining zones as VLANs without consequence logic

Fix: define zones by process function and risk, then map to networks/VLANs.

Mistake 2: “One big OT zone” plus a perimeter firewall

Fix: create at least one internal boundary: per-line/cell zones and an engineering zone are usually high-impact first steps.

Mistake 3: Allowing IT tools to dictate OT design

Security tooling should support OT architecture, not replace it.
Fix: use OT constraints to select controls and deploy safely.

Mistake 4: Permissive conduits “temporarily”

Temporary rules that never expire are the #1 segmentation drift source.
Fix: implement expiry dates, exception registers, and quarterly conduit reviews.

Mistake 5: Forgetting that identity is part of segmentation

If anyone can log in anywhere with shared accounts, your zone boundaries are porous.
Fix: tighten identity, privileged access, and remote access governance alongside network segmentation.

Mistake 6: Building diagrams no one can operate

If operations and engineering can’t maintain it, it will degrade.
Fix: keep designs understandable, document required flows, and create change workflows that fit maintenance windows.

---

Documentation that auditors and engineers both accept

IEC 62443 programs succeed when documentation is:

• technically accurate,
• operationally usable,
• and traceable from risk to control.

Minimum documentation set for zones & conduits

1. Zone inventory
   • zone name, purpose, assets, owner, criticality
2. Conduit matrix
   • source zone → destination zone, allowed flows, justification, enforcement points
3. Network diagrams (current + target)
   • include trust boundaries and enforcement devices
4. Ruleset governance
   • rule review process, expiry, exception handling
5. Remote access model
   • authentication, approvals, session logging/recording, vendor management
6. Monitoring plan
   • what is logged, where it’s stored, alert use cases
7. Incident response linkage
   • containment ladder: boundary → conduit tightening → targeted isolation

---

Implementation roadmap: 30/60/90 days and beyond

Below is a pragmatic approach that works for brownfield OT—especially when uptime constraints are real.

First 30 days: visibility and scoping

• confirm asset roles and criticality tiers
• identify the biggest pathways (remote access, IT/OT boundary, OT DMZ)
• gather baseline data flows from logs and passive monitoring
• create draft zones (even if not implemented yet)
• draft a conduit matrix with “required flows only”

Outcome: you can explain your current exposure and your target architecture.

Days 31–60: enforce high-value boundaries

• implement or harden OT DMZ and boundary firewall policies
• restrict remote access through a jump host/broker
• create an engineering zone boundary (even if small at first)
• block the most dangerous cross-zone protocols where not needed (commonly SMB/RDP)
• start logging and retention for conduit evidence

Outcome: measurable reduction in reachable attack surface.

Days 61–90: segment by consequence (cells/areas) and tune operations

• implement per-line/per-cell segmentation for top critical areas
• tighten conduits based on observed legitimate flows
• implement exception governance and rule expiry
• tune detections for new talkers, controller write operations, and drift

Outcome: reduced blast radius and faster incident scoping.

Beyond 90 days: maturity and standardization

• standard zone models across sites (templates)
• standard remote access for vendors (contract language + enforcement)
• regular restore tests and validation
• quarterly architecture drift reviews
• tabletop exercises based on your actual zone/conduit design

Outcome: repeatable security engineering, not one-off heroics.

---

Checklists and templates (copy/paste)

Checklist 1: Zone definition worksheet

•  Zone name and purpose
•  Process function (line/unit/cell)
•  Asset roles included (PLC/HMI/EWS/server/safety)
•  Consequence tier (safety, downtime, quality)
•  Owners (operations/engineering/security/vendor)
•  Required inbound/outbound communications (to other zones)
•  Special constraints (latency, legacy OS, vendor support)

Checklist 2: Conduit definition worksheet

•  Source zone → destination zone
•  Business/operational justification
•  Allowed protocols/ports (minimized)
•  Allowed source/destination systems (explicit)
•  Authentication requirements (who may initiate sessions)
•  Enforcement points (firewall/ACL/proxy/jump host)
•  Logging requirements (what to log, retention)
•  Monitoring use cases (new talkers, drift, scanning)
•  Change control process and rule expiry
•  Rollback plan (if enforcement disrupts operations)

Template: Conduit matrix (starter table)

Source Zone	Destination Zone	Purpose	Allowed Flows	Enforcement	Logging	Owner
OT Ops	Cell A	HMI visibility/control	HMI protocol X, time sync (if needed)	Industrial FW	allow/deny + session	OT Net Eng
Engineering	Cell A	Programming	Programming proto Y from EWS-01 only	Industrial FW + jump host	session + change alerts	Controls Eng
OT DMZ	IT	Reporting	Replication service Z	FW + proxy	full logs	IT/OT Sec

Checklist 3: “Deny by default” readiness

Before tightening rules:

•  Baseline flows captured for at least one production cycle
•  Operations sign-off on critical dependencies
•  Maintenance window identified for enforcement changes
•  Rollback steps tested (or at least rehearsed)
•  Monitoring in place to detect blocked-required flows quickly
•  Exception process ready (with expiry)

Checklist 4: Segmentation drift controls

•  Quarterly firewall/conduit rule review scheduled
•  Rule expiry is mandatory for temporary exceptions
•  Alerts for new cross-zone flows enabled
•  Vendor access reviewed quarterly (accounts + usage)
•  Architecture diagrams updated after changes
•  Incident postmortems feed improvements into conduit policy

---

FAQ

Is a “zone” the same as a VLAN?

No. A VLAN can implement a zone, but a zone is a security boundary defined by risk, function, and trust. Zones should be justifiable and enforced; VLANs are a network mechanism that may or may not reflect security needs.

Do I need an OT DMZ to follow IEC 62443?

You can implement zones and conduits without a DMZ, but an OT DMZ is one of the most practical ways to control IT/OT integration and reduce direct reachability into OT operations networks.

How many zones should a plant have?

Enough to meaningfully reduce blast radius and separate trust. Many plants start with: OT DMZ, OT operations, engineering, and a few high-consequence cell/area zones—then refine over time.

What protocols should be blocked across conduits?

It depends on operational requirements, but many environments benefit from minimizing or blocking general-purpose admin and file-sharing protocols across sensitive conduits (commonly SMB and broad RDP), replacing them with controlled access paths via jump hosts and allowlists.

How do zones & conduits help incident response?

They make incidents easier to scope and contain. If conduits are logged and tightly controlled, responders can quickly identify abnormal cross-zone behavior and contain at boundaries—often without disrupting production.