OT Network Segmentation: A Zones-and-Conduits Blueprint

OT network segmentation means dividing an industrial network into isolated zones connected only through controlled conduits, so a compromise in one area can't reach safety systems or production control elsewhere. The right approach for most operators is a phased rollout built on IEC 62443 zone-and-conduit design, an industrial DMZ separating IT from OT, and passive traffic mapping to document what's actually talking to what before a single firewall rule gets written.

TL;DR:

About 96% of OT incidents in 2024 stem from IT network connections, often through exposed VPNs or email accounts, not direct plant-floor attacks.

Zones should be assigned security levels from SL 0 to SL 4, with conduit security matching the higher of the two zones it connects, to prevent weakest-link vulnerabilities.

The industrial DMZ at Purdue Level 3.5 is the essential control point for restricting direct enterprise-to-control network access, using dual-terminated, monitored connections.

Passive asset mapping and communication matrix documentation are critical before implementing firewall rules, allowing phased, monitored deployment that minimizes operational risk.

Continuous monitoring and regular audits are vital to maintain segmentation integrity, detect rule drift, and ensure rapid incident response and recovery.

What Is OT Network Segmentation and Why Does It Matter?
Standards and Reference Models Behind Segmentation Design
How Do You Design Zones and Conduits?
What Role Does an Industrial DMZ Play?
When Should You Apply Microsegmentation Inside OT Zones?
What's the Right Sequence for Rolling Out Segmentation?
Which Technology Controls Actually Belong in an OT Segmentation Stack?
Operational Considerations: Safety, Change Control, and Maintenance
Common Pitfalls in OT Segmentation Projects
How Does a vCISO Operationalize Segmentation for Regulated Operators?
How Do You Continuously Monitor and Audit a Segmented OT Network?
How Should Segmentation Feed Into OT Incident Response and Recovery?
How Do You Test and Validate Segmentation Effectiveness?
How Should Remote Access and Vendor Connectivity Work in a Segmented OT Network?
Will Segmentation Slow Down My OT Systems?
Where Should You Start With a Limited Budget?
Where Should You Go Deeper on These Standards?
Sources

What Is OT Network Segmentation and Why Does It Matter?

Segmentation is the practice of grouping OT assets into zones that share a common security requirement, then routing all traffic between zones through a conduit that enforces which source, destination, protocol, and port combinations are allowed. Everything outside that permitted list gets blocked by default.

The case for doing this well is not theoretical. The 2025 SANS State of ICS/OT Cybersecurity Survey found that 22% of organizations experienced an OT cyber incident in the past year, and 96% of those incidents originated from IT network connections rather than a direct assault on the plant floor. Attackers land in a business email account or an exposed VPN, then walk laterally into the control network because nothing stops them.

OT segmentation differs from IT segmentation in three important ways:

Safety comes first. A blocked packet in IT means a delayed email; in OT, it can mean a safety interlock fails to fire.
Legacy protocols dominate. Modbus, DNP3, and proprietary PLC protocols often lack authentication entirely, so segmentation has to compensate for what the protocol can't do itself.
Availability trumps confidentiality. A control loop that stops running can shut down a refinery unit or a power feed, so segmentation design has to account for real-time timing, not just data secrecy.

Standards and Reference Models Behind Segmentation Design

Three frameworks anchor almost every credible OT segmentation program, and referencing them explicitly makes audits and board conversations far easier.

IEC 62443 defines the zones-and-conduits model: assets are grouped into zones sharing a security level, and every conduit between zones carries an explicit, documented set of permitted communications.
NIST SP 800-82 Rev. 3 codifies that same zone-and-conduit approach for U.S. federal and critical-infrastructure environments, and its guidance recommends industrial DMZs, passive asset mapping, and compensating controls specifically for legacy equipment that can't be patched or agent-monitored.
The Purdue Enterprise Reference Architecture gives you the vertical map: Level 0/1 field devices and controllers, Level 2 supervisory HMIs, Level 3 site operations, and Level 3.5 as the DMZ boundary before Level 4/5 enterprise IT.

Mapping Purdue levels onto IEC 62443 zones gives you a defensible architecture: each Purdue level typically becomes one or more security zones, and every crossing between levels becomes a conduit with its own security level requirement. Our NIST-aligned IT security guide covers how these controls translate for security leaders managing both IT and OT estates.

How Do You Design Zones and Conduits?

Zone design starts with grouping, not tooling — following key principles from the Fire Alarm Zoning: Practical Design and Compliance Guide. Get the grouping wrong and every firewall rule built on top of it inherits the mistake.

Group by function and risk, not by physical location alone. A safety system, a batch controller, and a historian rarely belong in the same zone even if they sit in the same cabinet.
Assign a security level (SL) to each zone, from SL 0 (no specific requirement) to SL 4 (protection against sophisticated, resourced attackers), based on consequence of compromise.
Document every conduit with a communication requirements document listing source, destination, protocol, port, direction, and business justification for the flow, an approach practitioners consistently recommend as the foundation for firewall rules and monitoring signatures.

The rule that trips up most first-time designs: conduit SL must match the higher of the two zones it connects, not the lower one or an average. If a low-security engineering workstation zone connects to a high-security safety zone, the conduit itself needs high-security controls, because it becomes the weakest link in the chain regardless of how hardened the safety zone appears on paper.

Pro Tip: Build the communication matrix as a living document in a spreadsheet or GRC tool before you touch a firewall. Every rule you write later should trace back to one row in that matrix, and every row without a matching rule is a gap someone needs to explain.

What Role Does an Industrial DMZ Play?

The industrial DMZ, often called the IDMZ, sits at Purdue Level 3.5 and acts as the only legal crossing point between the business network and the control network. No traffic should pass directly from an enterprise workstation into a PLC network under any circumstance.

The IDMZ typically hosts:

Historian replication servers that pull production data out without letting IT push anything in.
Jump servers for engineers who need remote access to control systems, forcing all sessions through a monitored, authenticated hop.
Patch and antivirus proxies that let OT devices receive updates without connecting directly to the internet-facing update infrastructure.

The core rule is dual termination: every connection between IT and OT terminates in the IDMZ and starts a new, separately authenticated session on the other side. There is no straight pipe through. When a flow only needs to move in one direction, such as historian data leaving the plant floor for enterprise reporting, a unidirectional gateway or data diode enforces that physically, not just by policy.

Given that 96% of OT incidents in 2024 traced back to an IT network connection, the IDMZ is arguably the single highest-leverage control most operators can add, because it closes the exact path attackers are already using.

When Should You Apply Microsegmentation Inside OT Zones?

Coarse zones stop the worst-case scenarios. Microsegmentation, dividing a single zone into smaller VLAN-isolated segments with inter-VLAN filtering, stops the everyday scenario: one infected engineering laptop spreading to every device on a flat production VLAN.

Apply microsegmentation when you have:

High-value or high-risk assets sharing a broadcast domain with general-purpose devices, such as a safety PLC sitting on the same VLAN as printer traffic.
A demonstrated need from traffic analysis, not a hunch. Passive capture over several weeks should show which device groups actually never need to talk to each other.
Managed switches with VLAN support, since many brownfield OT environments still run unmanaged switches that make microsegmentation impossible without a hardware refresh first.

Skip microsegmentation on process cells where every device legitimately needs to talk to every other device in real time. Splitting those apart with strict inter-VLAN rules risks introducing latency into a control loop that has none to spare.

What's the Right Sequence for Rolling Out Segmentation?

Sequence matters more than speed here. Jumping straight to firewall deployment without mapping the network first is the fastest way to cause an unplanned outage.

Start with passive discovery. Use SPAN ports or network taps to build a full asset inventory without sending a single active probe into the network, since active scanning risks disrupting legacy controllers that were never built to handle unexpected packets. Our guide to industrial cybersecurity assessment types breaks down passive versus active discovery methods in more detail.
Build the communication matrix from captured traffic, documenting every legitimate flow before you decide what to block.
Draft zone and conduit boundaries against that matrix, then translate each permitted flow into a specific firewall rule or monitoring signature.
Pilot on one cell or line first. Run new rules in monitor-only mode for at least two to four weeks to catch flows your matrix missed.
Roll out in phases with a documented rollback plan for every change window, and keep continuous monitoring running throughout so drift gets caught immediately, not at the next annual audit.

Pro Tip: Treat your first pilot zone as a controlled experiment, not a finished deployment. The goal is catching the flows nobody remembered to document, like a vendor's remote diagnostic tool that only phones home once a quarter.

Which Technology Controls Actually Belong in an OT Segmentation Stack?

Not every firewall marketed for "industrial use" is built for the job. Look for specific capabilities before you buy.

Industrial firewalls need deep packet inspection for OT protocols like Modbus, DNP3, and EtherNet/IP, not just generic port and IP filtering, plus low-latency throughput and ratings for the temperature and vibration conditions of a plant floor.
Data diodes and unidirectional gateways fit any flow that only needs to move one way, historian exports being the classic case, and they enforce that direction in hardware rather than policy.
Managed switches with VLAN and port-security support are the prerequisite for microsegmentation and often the first hardware gap brownfield sites discover during a segmentation project.
Passive OT monitoring platforms provide the ongoing asset visibility and anomaly detection that a one-time mapping exercise can't sustain on its own.

NIST SP 800-82's Appendix E maps each of these control types to specific Purdue levels, which is worth reviewing before finalizing a procurement list.

Operational Considerations: Safety, Change Control, and Maintenance

Segmentation projects fail operationally more often than they fail technically. A perfectly designed conduit rule still causes a shutdown if nobody validated it against the actual control loop timing.

Bring control engineers into the design process from day one. MITRE ATT&CK's mitigation guidance is explicit that segmentation decisions affecting real-time control loops need safety and reliability sign-off, not just a security team's approval.
Schedule changes inside approved maintenance windows and validate every new rule against a test environment or a non-production line before touching live control systems.
Review rules on a fixed cadence, quarterly at minimum, to catch drift and confirm the communication matrix still matches reality.
Fold segmentation logs into your incident response plan so an alert on a conduit violation triggers a defined escalation path, not a shrug.

Common Pitfalls in OT Segmentation Projects

Most segmentation failures trace back to a handful of repeatable mistakes.

Temporary exceptions that never expire. A vendor gets a firewall exception for a one-time troubleshooting session, and eighteen months later nobody remembers it's still open. Every exception needs a hard expiration date and an owner who gets pinged before it lapses.
Rule drift with no monitoring. Firewall rules accumulate over years of small changes until nobody can explain why half of them exist. Continuous validation against the communication matrix catches this before an audit does.
Active vulnerability scans against legacy PLCs. Older controllers can crash or lock up under scan traffic that a modern IT asset would shrug off. SANS guidance is blunt on this point: use passive methods for legacy device discovery, always.

Pro Tip: Set a calendar reminder tied to every firewall exception the day it's created, not the day someone remembers to look. Exceptions without expiration dates are how flat, unsegmented networks quietly come back.

How Does a vCISO Operationalize Segmentation for Regulated Operators?

For law firms, energy operators, and other compliance-sensitive organizations, segmentation has to satisfy an auditor as much as an attacker. A vCISO frames each zone definition around the specific regulatory control it satisfies, whether that's a SOC 2 network security criterion or a CMMC boundary protection requirement, so the architecture doubles as audit evidence.

Typical deliverables include:

A documented communication matrix mapped to firewall rules
Conduit-by-conduit justification records tied to business need
Verification reports confirming rules match the approved design
A phased remediation roadmap with compensating controls for legacy devices that can't be replaced this budget cycle

This approach lets leadership see risk reduction in concrete terms rather than technical abstraction, which is the gap most internal teams struggle to close alone.

How Do You Continuously Monitor and Audit a Segmented OT Network?

Segmentation isn't a project with an end date. It's a control that degrades the moment nobody's watching it.

Continuous monitoring in a segmented OT environment means feeding conduit traffic into a platform that can flag anything outside the documented communication matrix, in near real time. A device suddenly talking to a new IP address, a protocol appearing on a segment where it's never run before, or a spike in traffic volume between two zones should generate an alert, not sit unnoticed in a log file.

Auditing needs two separate cadences. Technical audits, run monthly or quarterly, compare live firewall rule sets against the documented communication matrix and flag any rule that doesn't trace back to a justified business need. Compliance audits, run annually or ahead of a certification cycle, confirm the whole segmentation program still maps cleanly to the framework it's built against, whether that's SOC 2, CMMC, or an internal risk framework.

Segmentation breach detection works best layered: passive network monitoring for anomalous flows, firewall and switch logs correlated in a SIEM, and periodic manual review of exception lists. No single layer catches everything. A firewall log alone won't show a rogue device that never generates a rule violation but simply appears on a network segment it shouldn't reach.

The organizations that get burned worst are the ones that build a strong initial architecture, declare victory, and stop watching. Rule drift and quiet configuration changes accumulate fastest in the months right after a successful rollout, when attention has already moved to the next project.

How Should Segmentation Feed Into OT Incident Response and Recovery?

A segmentation architecture that isn't wired into your incident response plan is a missed opportunity at the exact moment it matters most.

When a conduit monitoring alert fires, the response plan needs to specify, in advance, who has authority to isolate a zone, what the isolation procedure actually looks like on that specific network, and how operations gets notified before a control loop unexpectedly loses connectivity to a supervisory system. Deciding this during a live incident wastes minutes that matter.

Segmentation also shapes recovery strategy directly. A well-designed zone architecture means a ransomware event that lands in the business network stays contained at the IDMZ boundary, letting operations continue running in a degraded but functional state while IT rebuilds. Without that boundary, recovery means restoring the entire environment from backups before anything can safely run again, a difference that can turn a one-day recovery into a multi-week one.

Recovery plans should also define a validated "known good" configuration for every zone's firewall rules and switch configs, stored offline and tested for restoration speed. Nearly 20% of organizations hit by an OT incident needed more than a month to remediate, and slow recovery is frequently a documentation problem as much as a technical one. If nobody can quickly confirm what the segmentation rules were supposed to look like before the incident, rebuilding takes far longer than it should.

Our breakdown of cyber risk in oil production covers how segmentation-driven containment changes recovery timelines in field-heavy operating environments specifically.

How Do You Test and Validate Segmentation Effectiveness?

Design documents describe intent. Testing tells you whether the network actually behaves the way the documents claim.

Rule validation starts simple: for every entry in the communication matrix, confirm the corresponding firewall rule exists and blocks everything not explicitly listed. This sounds obvious and still turns up gaps in most first audits, usually from a rule written broader than intended to avoid breaking something during initial rollout.

Penetration testing in OT carries constraints that IT testing doesn't. Live exploitation against production PLCs risks the exact outage segmentation is meant to prevent, so effective OT penetration testing typically runs against a test bed or digital twin that mirrors the production architecture, with any live-network testing scoped tightly and scheduled during planned maintenance windows with engineering sign-off.

Tabletop simulation fills the gap live testing can't safely cover. Walking a cross-functional team through a scenario, a compromised vendor laptop connecting through the IDMZ, say, and tracing exactly which conduits would block it and which alerts would fire, surfaces design gaps without touching a single production device.

Segmentation testing should also validate the negative case deliberately: attempt flows that should be blocked and confirm they actually are, rather than only confirming that legitimate flows still work. It's common for teams to validate that production keeps running after a change and skip the harder step of confirming the new rule actually blocks what it was built to block.

How Should Remote Access and Vendor Connectivity Work in a Segmented OT Network?

Vendor remote access is one of the most common paths attackers use to reach OT, and it's also one of the hardest to lock down completely because operators genuinely need vendors to troubleshoot equipment remotely.

The IDMZ jump server model handles this correctly: a vendor connects to a jump server sitting in the IDMZ, authenticates separately from any enterprise credential, and only then gets a scoped, monitored session into the specific OT segment their equipment lives in. The vendor never gets a direct route into the control network, and the session gets logged in full for later review.

Access should be time-bound and requested, not standing. A vendor connection open by default, available any time someone happens to need it, is functionally identical to a permanent exception nobody's watching. Multi-factor authentication on every remote session, plus session recording, closes off the credential-theft path that shows up repeatedly in OT incident postmortems.

Hands using remote access jump server console

Segment remote access permissions the same way you segment the network itself: a vendor supporting one specific PLC line shouldn't have visibility into the entire plant's control network just because it was easier to configure that way. Least-privilege access matters as much for a temporary vendor session as it does for a permanent employee account.

Will Segmentation Slow Down My OT Systems?

Done correctly, segmentation shouldn't introduce meaningful latency into real-time control loops, but done carelessly, it absolutely can, and that risk is the single biggest reason some operators hesitate to start.

The failure mode usually isn't the firewall itself. It's placing a security control inline with a control loop that has millisecond-level timing requirements and no tolerance for even small added delay. This is exactly why zone boundaries should align with natural process boundaries rather than arbitrary network segments: traffic within a tightly coupled control loop stays inside one zone, while only supervisory and non-time-critical traffic crosses a conduit where inspection adds a few milliseconds nobody notices.

Industrial firewalls built for OT specifically are rated for the throughput and latency profile of control traffic, which is precisely why generic enterprise firewalls belong in the IDMZ and not inline with a process cell. Choosing the wrong device class for the wrong location is where most performance complaints originate.

Operational continuity during rollout matters just as much as long-term performance. Piloting changes in monitor-only mode before enforcing them, keeping a documented rollback plan for every change window, and validating against a test environment first are what separate a segmentation project that improves security quietly in the background from one that generates a production incident and a very unhappy plant manager. Balancing security and availability isn't a one-time design decision. It's a discipline maintained through every change made after the initial rollout, too.

Where Should You Start With a Limited Budget?

If you're constrained on time or budget, protect safety-critical and process-critical zones first. Everything else can wait a phase. Run a short, passive-mapping pilot on one line or cell to build a real communication matrix and show leadership concrete findings, not projections, within weeks rather than months. Where full architectural change isn't feasible yet, layer in compensating controls, monitoring, access restrictions, and stricter change control, while you build the business case for the conduits and IDMZ work that come next. Segmentation is a program, not a single purchase order, and the operators who succeed treat the first pilot as proof, not perfection.

— vCISO

For organizations that need this translated into an audit-ready program rather than a one-off project, CisoSafe's vCISO services build the communication matrix, conduit documentation, and phased remediation roadmap alongside your team, scoped to the compliance framework your regulators actually check.

Where Should You Go Deeper on These Standards?

Read NIST SP 800-82 Rev. 3 for OT design guidance, IEC 62443 for normative engineering requirements, SANS for incident trends, and CISA for current advisories.