OT network segmentation for cybersecurity and OT teams

OT network segmentation is the practice of dividing industrial control system networks into isolated zones connected only through controlled, monitored conduits, so a compromise in one area cannot spread into safety-critical systems. If you do one thing this quarter, do three: stand up a dual-terminated Industrial DMZ, remove any direct routable path between IT and OT, and start passive asset discovery across your control network.

• Build the IDMZ first. Corporate systems terminate at the IDMZ; OT systems terminate at the IDMZ. No direct IT to OT sessions.
• Kill routable IT to OT paths. Firewall rules that “allow any” between subnets are the single biggest recurring failure Re-solution finds during audits.
• Start discovery now. You cannot segment what you have not mapped, and passive capture is safe to run even on live production lines.

These three moves matter because OT security is safety-first, not confidentiality-first. Every segmentation decision has to protect uptime and physical safety before it protects data.

Key Takeaways

Effective OT network segmentation depends on a dual-terminated IDMZ, documented zones and conduits, and continuous monitoring rather than a one-time firewall deployment.

Point	Details
Close the IT to OT gap first	Most OT incidents start via IT-connected paths, so the IDMZ and routable-path removal come before any other control.
Design zones by consequence	Group assets by security requirement and consequence of compromise, not physical layer or vendor.
Match control to failure risk	Use passive monitoring or unidirectional gateways where inline blocking could create an unsafe process state.
Segmentation needs governance	Cross-team workshops between IT and OT staff prevent the change-control clashes that derail most projects.
Partner for discovery and design	Re-solution’s network audits and NaaS model support the discovery, zone design, and ongoing maintenance segmentation requires.

Table of Contents

• What is OT network segmentation and why does it matter?
• Purdue, zones and conduits, and the Industrial DMZ
• How to segment an OT network step by step
• Microsegmentation versus traditional zone-based segmentation
• Controls and technologies that enforce OT segmentation
• Managing safety, availability and change control risk
• Field lessons: a practical checklist and common pitfalls
• Sources
• FAQ

What is OT network segmentation and why does it matter?

OT network segmentation means splitting an industrial network into zones, groups of assets that share the same security requirement, connected by conduits, the defined, monitored, and rule-governed pathways between them. Unlike a flat network where a compromised engineering workstation can reach a safety instrumented system in one hop, a properly segmented OT network forces every connection through a documented, inspected chokepoint.

OT security follows a different priority order to IT security. IT typically ranks confidentiality first; OT ranks safety, then availability, then integrity, then confidentiality. A firewall rule that blocks a legitimate control signal during a batch run is a bigger operational failure than a minor data leak, which is why segmentation design in OT has to account for process timing and fail-safe behaviour, not just access control.

The numbers make the case plainly. Industry data shows that 96% of OT security incidents originated from connections to the IT network, not from attackers breaching the OT perimeter directly. Segmentation, specifically closing the IT to OT pathway, is the highest-leverage control available for reducing that exposure.

• Zones group assets by consequence of compromise, not by physical location or vendor.
• Conduits document every allowed connection: source, destination, protocol, port, direction, and business justification.
• MITRE ATT&CK lists network segmentation as a formal mitigation against lateral movement in ICS environments, which tells you this is not a theoretical best practice; it is a documented response to observed attacker behaviour.

Purdue, zones and conduits, and the Industrial DMZ

Most OT architecture guidance still starts with the Purdue Model, which layers a plant network from Level 0 (sensors and actuators) up to Level 5 (corporate IT). It is a useful mental map, but modern practitioners increasingly design around IEC 62443 zones and conduits instead, because zones are defined by security requirement, not physical layer. A Level 2 HMI and a Level 2 historian might sit in different zones if one carries far higher consequence-of-compromise risk than the other.

IEC 62443 assigns security levels (SL 0 to SL 4) to each zone based on the sophistication of attacker it needs to resist, then requires every conduit crossing a zone boundary to meet the higher of the two zones’ security level requirements. A structured engineering methodology published in 2026 shows how to map this directly onto IPv4 subnetting and VLAN design, tying network engineering decisions to IEC 61511 functional safety requirements rather than treating them as separate exercises.

Sitting between the corporate network and Level 3 is the Industrial DMZ, sometimes labelled Level 3.5.

The defining rule of the IDMZ is dual-termination: corporate systems terminate at the IDMZ, and OT systems terminate at the IDMZ — neither side ever connects directly to the other. Every file transfer, patch update, or historian sync passes through a broker sitting inside that buffer zone.

• Purdue gives you the reference layers; zones and conduits give you the enforceable policy.
• The IDMZ is not a single firewall. It is a buffer network with its own hosts (patch servers, jump hosts, historian mirrors).
• Government guidance, including CISA’s architecture recommendations, treats IT and OT as systems that must be designed and risk-assessed separately, not as one network with different labels.

How to segment an OT network step by step

Segmentation projects fail when teams jump straight to firewall rules without first understanding what is actually on the network. A phased approach protects both the project and the process it’s meant to secure.

1. Prepare. Map stakeholders across OT engineering, IT security, and plant operations. Agree change control windows before touching anything.
2. Discover. Run passive traffic capture on span ports, not active scanning, and cross-reference findings against P&ID diagrams to build a real asset inventory.
3. Design. Define zones by consequence of compromise, write conduit documents for every cross-zone flow, and plan VLAN and subnet ranges that map cleanly onto those zones.
4. Pilot. Apply the new boundary to one non-critical production cell first, ideally one with redundancy or a maintenance window built in.
5. Roll out in stages. Enforce boundaries zone by zone, watching for unexpected traffic drops that indicate an undocumented dependency.
6. Validate and monitor continuously. Test fail-safe behaviour under fault conditions, measure added latency on time-sensitive conduits, and keep monitoring after go-live rather than treating segmentation as a one-off project.

Testing acceptance criteria should cover functional safety checks (does the safety instrumented system still trip correctly with the new boundary in place?), latency measurements on any control loop crossing a conduit, and a documented fail-safe analysis for every inline appliance. Timelines vary enormously by plant size, but a single production line typically takes weeks for discovery and design, then longer for staged rollout if legacy devices need replacement rather than reconfiguration. Budget for the discovery and documentation phase specifically; it is usually where projects run over, not the firewall deployment itself.

Pro Tip: Pilot on a cell with a manual override or backup process path. If the segmentation boundary misbehaves, operators can keep running the line manually while you fix the rule set, instead of forcing an unplanned shutdown.

Microsegmentation versus traditional zone-based segmentation

Microsegmentation pushes the zone concept down further, isolating individual PLCs or small groups of devices behind their own VLAN and inter-VLAN firewall rule, rather than grouping an entire production cell into one zone. NCSC guidance on OT connectivity highlights this granularity as a key principle for reducing east to west risk, the lateral movement that happens once an attacker is already inside a zone.

The trade-off is operational complexity. Microsegmentation demands managed switches everywhere, a detailed and accurate communication matrix, and ongoing rule maintenance as devices change. Traditional zone and conduit design is coarser but far easier to operate and troubleshoot at scale.

• Use microsegmentation for high-impact cells: safety instrumented systems, process controllers with catastrophic failure modes.
• Use traditional zone-based segmentation for system-level stability where the assets share similar risk and the operational overhead of per-device rules isn’t justified.
• Legacy unmanaged switches often force a gradual replacement plan before true microsegmentation is even possible.

Controls and technologies that enforce OT segmentation

The right control depends on what a zone boundary actually needs to do, block traffic, watch it, or physically prevent it from flowing at all.

• Industrial firewalls with protocol-aware deep packet inspection for Modbus, OPC UA, and EtherNet/IP, so rules understand the command inside the packet, not just the port.
• Data diodes or unidirectional gateways where information only needs to flow one way, historian data leaving OT, for example, with zero risk of a return path.
• Jump hosts for any remote access into OT, so vendors and engineers authenticate once and every session is logged.
• Network Access Control (NAC) on managed switch environments to stop unknown devices from joining the OT network unchecked.
• Passive traffic capture and NIDS tuned specifically for industrial protocols, catching anomalies without touching live traffic.

Every control choice has to respect OT timing: added latency that breaks a control loop is unacceptable, and any inline appliance needs a defined fail-safe behaviour if it dies mid-session. Feed logs from these controls into your existing SIEM, but expect to tune it for OT protocol noise, industrial network segmentation guidance consistently flags segmentation without matching visibility as one of the more common blind spots; see Network Security Protocols Explained for IT Pros for foundational understanding of these protocols.

Pro Tip: Before choosing a firewall model, check its published latency figures under full load, not idle benchmarks. A control loop with a 50ms tolerance will not forgive a device that adds 80ms under inspection load.

Managing safety, availability and change control risk

Placing an inline appliance between two tightly coupled OT sub-zones is where segmentation projects most often introduce new risk instead of removing it. If that appliance fails closed, it can trip a process unnecessarily; if it fails open, it defeats the purpose of the boundary. Deciding which failure mode is acceptable is a safety engineering question, not a networking one.

• Run a fail-safe versus fail-secure analysis for every inline device before deployment, involving process engineers, not just network staff.
• Build maintenance windows and vendor access policies into the change control process from day one, so segmentation doesn’t become the reason a vendor can’t reach a PLC during an emergency.
• Use passive monitoring or unidirectional controls instead of inline blocking wherever a boundary sits between safety-critical, tightly coupled systems.

CISA’s own guidance is explicit here: introducing a segregation appliance into ICS-OT requires its own safety analysis, because the appliance itself can become the single point of failure that causes an unsafe process state.

Pro Tip: Ask “what happens to the process if this box loses power right now?” for every inline device before it goes live. If nobody in the room can answer confidently, it isn’t ready for production.

Field lessons: a practical checklist and common pitfalls

Segmentation projects that hold up over time tend to follow a consistent pattern: a joint IT/OT stakeholder workshop before any design work, passive discovery run over a full production cycle (not a single shift), conduit documents written for every cross-zone flow, a pilot on a low-risk cell, and a rollback plan written before go-live, not improvised afterwards.

The recurring failure points are just as consistent. Asset inventories with gaps, usually legacy devices nobody remembered to include, lead to firewall rules that unexpectedly break something months later. Manual firewall rule sprawl, hundreds of ad hoc exceptions with no documented justification, turns a clean zone design into an unauditable mess within a year. IT and OT change processes that run on different clocks cause deployment windows to clash with production schedules. And conduits carrying time-sensitive control traffic often get tested for connectivity but never for latency under load, which is exactly where problems surface later.

• Run the stakeholder workshop before any firewall purchase decision.
• Treat conduit documentation as a living asset, not a one-off project deliverable.
• Test timing-sensitive conduits under realistic load, not just a ping check.

Pro Tip: Keep the conduit register in a format both OT engineers and network staff can update without IT ticketing overhead. If updating it requires a change request, it will fall out of date within months.

Prioritising segmentation work: an editorial view

Segment safety-critical zones and the IDMZ before anything else. Asset discovery should start in parallel, not after, because every week spent without a real inventory is a week of unknown risk sitting on the network. Re-solution’s work across manufacturing and logistics environments consistently shows the same pattern: technical design rarely fails a segmentation project, weak governance between IT and OT teams does.

How Re-solution supports OT segmentation projects

Segmentation projects live or die on accurate discovery and disciplined design, not just firewall rules. Re-solution runs network audits that map existing OT and IT traffic before a single conduit is written, then designs zone architecture, IDMZ deployments, and industrial firewall policy around the safety and availability constraints your plant actually operates under.

Where a full managed engagement makes sense, Re-solution’s Network as a Service model covers ongoing monitoring and rule maintenance, so segmentation stays effective as devices and processes change rather than drifting out of date within a year. If you’re weighing up where your own network stands, an infrastructure audit is the practical next step, get in touch to scope a discovery phase against your current architecture.

Sources

• Segregating the ICS-OT Insecure by Design Architecture Rev E — CISA
• Structured engineering methodology for ICS network architectures — Zenodo (2026)
• Network segmentation mitigation (M0930) — MITRE ATT&CK

FAQ

What does OT mean in networking?

OT stands for operational technology, the hardware and software that monitors and controls physical processes such as PLCs, SCADA systems, and safety instrumented systems, as distinct from IT, which manages data and business systems.

What are the types of network segmentation used in OT?

The main approaches are Purdue-based layering, IEC 62443 zones and conduits, and microsegmentation down to individual devices, often combined so critical cells get microsegmentation while broader plant areas use larger zones.

What is the difference between an OT network and an IT network?

OT networks prioritise safety and availability above confidentiality and run legacy, often proprietary protocols with long device lifecycles, while IT networks prioritise data confidentiality and refresh hardware far more frequently. Re-solution designs segmentation architecture that respects this priority order rather than applying IT-first assumptions to OT environments.

What is the relationship between OT and IoT?

IoT devices, sensors and connected equipment often sit at the edge of OT networks, and because many arrive with weak default security, they typically need their own dedicated zone rather than direct access to core control systems.

Recommended

• Secure network design: proven examples for robust protection
• Network infrastructure checklist: optimise compliance
• Harness advanced networking technologies for secure IT
• Modern network security: A complete guide for IT leaders