What it means
OT zones group assets with similar function, trust, criticality, and security requirements, while conduits define and control the communications allowed between them.
Why it matters
Flat segmentation or arbitrary VLAN boundaries do not protect process functions when permitted flows, identities, fail-safe behavior, and operational dependencies are not engineered.
Practical focus
- Define zones by process function, safety, criticality, ownership, lifecycle, and required communications rather than address convenience.
- Specify conduits with source, destination, protocol, command, direction, identity, time, inspection, logging, and failure behavior.
- Validate normal, maintenance, emergency, failover, recovery, and vendor workflows before enforcing restrictions.
- Preserve this evidence: Retain zone and conduit diagrams, flow requirements, firewall and gateway rules, owner approvals, tests, exceptions, monitoring, and change history.
- Exercise this failure scenario: A broad rule preserves uptime but permits an IT compromise or vendor session to reach controllers far beyond the intended process boundary.
Common mistakes
- Using the label OT Network Zones and Conduits without defining scope, ownership, decision authority, and the exact data, systems, people, or process affected.
- Treating a policy, contract, diagram, dashboard, or tool demonstration as proof that OT Network Zones and Conduits operates consistently in production.
- Closing work without retaining the evidence needed to reconstruct the decision and verify the intended control outcome.
- Testing only the normal path and never rehearsing the failure condition: A broad rule preserves uptime but permits an IT compromise or vendor session to reach controllers far beyond the intended process boundary.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: