A security model that groups assets with similar requirements into zones and allows communication only through controlled conduits. In OT environments, it limits lateral movement and turns segmentation into an explicit policy decision instead of a flat network assumption.
What Zones and Conduits Mean in OT Security
Zones and conduits are a way to describe trust boundaries in industrial networks. A zone groups assets with similar protection needs, while a conduit is the controlled path that permits communication between zones. The model replaces “everything can talk to everything” networking with explicit, policy-driven connectivity.
That matters because OT environments often combine legacy systems, long equipment lifecycles, and safety constraints. Once communication paths are made intentional, security teams can reason about what must be reachable, what should be isolated, and where monitoring or enforcement belongs.
Why This Model Exists
The core purpose is to reduce blast radius. If one device, cell, or segment is compromised, the zone structure helps prevent easy lateral movement into adjacent areas. Conduits also force organisations to define allowed flows rather than assuming a flat network is acceptable by default.
In practice, the model is useful because industrial environments rarely have uniform trust. Engineering workstations, safety systems, HMIs, historians, remote access paths, and vendor connections often need different controls. A zone-and-conduit design lets those differences become part of the architecture instead of ad hoc exceptions.
It is also closely associated with OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide, which explains how zone partitioning, conduit definition, and migration away from flat OT networks fit together.
How Zones and Conduits Change Security Design
Zones are usually formed around similar risk, function, or safety requirements, not simply physical location. A well-designed zone has a clear security intent, a defined asset scope, and a reason for the communication paths it allows. That makes segmentation something engineers can specify and verify, rather than a vague network preference.
Conduits are equally important because they define the permitted route between zones and the controls that protect it. A conduit may involve firewalls, protocol-aware filtering, jump hosts, unidirectional gateways, logging, or other enforcement points depending on the risk and process requirement.
For OT, this matters because an allowed connection is not just a transport path. It is a governed security decision that should reflect operational necessity, safety constraints, and the acceptable exposure created by one zone reaching another.
Where the Model Shows Up Operationally
Zone and conduit architecture is most visible during design, assessment, and change management. Teams use it to document current-state connectivity, identify unsupported cross-zone traffic, and define where enforcement must exist before a system can be considered adequately segmented.
It also provides a useful basis for risk review. If an asset is placed in the wrong zone, or if a conduit is broader than the process requires, the architecture can quietly recreate a flat network under a more formal label. That is why the model works best when paired with asset inventory, flow review, and periodic validation.
In mature OT environments, the value is not just cleaner diagrams. It is the discipline of making connectivity explicit, reviewable, and limited to what the process actually needs.
Risk and Threat Considerations
Zones and conduits reduce exposure, but they can fail when organisations treat segmentation as a diagram rather than an enforced control. If conduits are overly permissive, poorly monitored, or bypassed by exceptions, attackers can still pivot between zones and expand compromise across operational systems.
Failure mechanism: The architecture becomes ineffective when zone boundaries exist on paper but not in enforcement, or when conduit rules are so broad that they preserve lateral movement paths instead of constraining them.
Impact: Compromise can spread from one OT asset to neighbouring systems, increasing the chance of process disruption, unsafe states, credential exposure, and loss of containment across multiple operational functions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Zones and conduits define controlled boundaries and permitted communication paths. |
| AC-4 — Information Flow Enforcement | The model governs which information flows are allowed between zones. | |
| CM-2 — Baseline Configuration | Zone and conduit designs rely on controlled, documented network baselines. | |
| Recommendation — Enforce SC-7 to restrict traffic between OT zones to explicitly approved conduits. Apply AC-4 to approve, filter, and monitor OT inter-zone traffic flows. Maintain CM-2 baselines for segmented OT network topology and allowed conduits. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Segmentation and controlled conduits are core network infrastructure safeguards. |
| Recommendation — Use CIS-12 to manage OT segmentation, trusted paths, and boundary devices. | ||
| OWASP ASVS | V8 — Authorization | The architecture is an explicit policy decision about what communications are authorised. |
| Recommendation — Apply V8 principles to ensure each permitted connection is explicitly authorised. | ||
Practitioner Guidance
Why practitioners should care: The main decision is not whether segmentation exists, but whether every inter-zone communication path is justified, controlled, and observable. A zone-and-conduit model only adds security value when ownership for each conduit is clear and exceptions are deliberately approved.
What to watch for: Pay close attention to undocumented flows, shared services that quietly bridge zones, and legacy connections that were left in place “temporarily” but became permanent. Those are the places where the architecture usually drifts back toward a flat network.
Practitioner takeaway: Treat the model as a living security policy for OT connectivity, not a one-time network design exercise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org