OT/IT Segmentation: Isolate the Plant Without Stopping It

OT/IT segmentation succeeds when you stop treating the plant floor like an office network. The control that matters is a layered boundary: a hardened IT-OT DMZ between enterprise IT and the production network, traffic allowed only through named conduits with an explicit protocol allowlist, and one-way data diodes wherever telemetry needs to leave but nothing should ever come back. Availability is the priority, not confidentiality, and that single inversion rewrites every rule you brought from IT.

The boundary between corporate networks and the systems that actually move things runs through KRITIS-regulated operators, Industrie 4.0 lines, and the firewalls sitting between them. The failures that surface there are rarely a missing feature. They are an IT segmentation playbook applied, unmodified, to a network where a dropped packet can stop a furnace. This guide sets out the architecture that holds, and the change discipline that keeps it standing.

Why IT Segmentation Breaks on the Plant Floor

The IT playbook assumes you can patch on Tuesday, reboot at midnight, scan whenever you like, and refresh hardware every four years. None of that holds in OT. A programmable logic controller may run for fifteen years untouched. Active scanning can crash a legacy device that has never seen a malformed packet. A maintenance window may open twice a year, and only with the plant manager present. The priorities invert as well: in IT the order is confidentiality, integrity, availability; in OT it is availability and safety first, with confidentiality often last.

That inversion is the whole story. A segmentation design that quietly drops an unrecognised flow is correct in IT and dangerous in OT, because the unrecognised flow may be the heartbeat that keeps a safety system armed. The architecture below is built to fail loud and fail safe, not silent.

The Reference Architecture: Purdue Plus an IT-OT DMZ

The durable reference model is the Purdue Enterprise Reference Architecture, the layered model that IEC 62443 and NIST SP 800-82 both build on. It splits the estate into levels, from enterprise systems at the top to physical processes at the bottom, and it places a dedicated demilitarised zone between the enterprise and the production network. Nothing from Level 4 enterprise IT talks to Level 2 control systems directly. Everything transits the DMZ, where a broker, a historian replica, or a jump host terminates the session and a new one is opened inward under tighter rules.

The IT-OT DMZ is the load-bearing element. When an operator says their plant is segmented because there is a firewall between the office and the factory, what they usually have is a single device with a permissive ruleset and no brokered layer. That is a speed bump, not a boundary. The zone-and-conduit discipline from microsegmentation applies here, but the unit of design is the cell, not the workload.

Conduits, Not Just Zones

IEC 62443 frames the design as zones and conduits. A zone is a group of assets with a shared security level. A conduit is the only sanctioned path between two zones, and it carries a named, allowlisted set of protocols. This is where OT segmentation earns its value. An enterprise firewall allows TCP 502 and considers the job done. An OT-aware conduit allows Modbus over TCP 502 and inspects the function codes, so a read-holding-register request passes and a write-multiple-registers request from an unexpected source does not.

That function-level allowlist is the difference between segmentation that looks good in a diagram and segmentation that survives a compromised engineering laptop. Industrial protocols, Modbus, OPC UA, PROFINET, EtherNet/IP, DNP3, were designed for trusted networks and carry little to no authentication. The conduit is where you add the control the protocol never had. The same egress-control logic that limits exfiltration in IT, covered in the egress filtering guide, applies inward here: a controller has no business reaching the internet, and the conduit is where you prove it cannot.

Where Firewalls End and Data Diodes Begin

A firewall is bidirectional by design, which means it can be misconfigured to allow a return path. For the highest-consequence boundaries, the production historian feeding a corporate dashboard, a safety instrumented system reporting status, the correct control is a data diode: hardware that physically permits data to flow one way and makes the reverse path electrically impossible. No ruleset, no firmware bug, and no insider change can turn it around.

Diodes are not a universal answer. They break any protocol that needs an acknowledgement, so they suit telemetry, syslog, and historian replication rather than interactive sessions. The practical pattern is a hybrid: data diodes for the one-way, must-never-reverse flows, and brokered firewall conduits in the DMZ for everything that genuinely needs a request and response. Deciding which flow is which is an architecture decision, not a procurement one, and it belongs in the design review before any hardware is ordered.

The Change You Cannot Make Is the Dangerous One

This is the part IT-trained teams underestimate. In an office network, the risk is the change you make badly. In OT, the larger risk is often the change you cannot make at all. The vulnerable controller that cannot be patched until the next planned outage, eleven months away, is a real exposure that no amount of segmentation removes on its own. Segmentation is what buys you the time, by shrinking the blast radius and the reachable attack surface until the window opens.

So the OT change process is built around compensating controls rather than fast remediation. When you cannot patch, you tighten the conduit, you add monitoring at the cell boundary, and you record the accepted risk with an owner and a review date. Every one of those compensating controls is a firewall change, and an unmanaged one drifts. The discipline that keeps an enterprise ruleset honest, documented in the firewall change management guide, matters more in OT, not less, because the window to correct a mistake is so narrow. Undetected policy drift on an OT conduit can sit unnoticed until the annual audit, by which point nobody remembers why the rule exists.

Compliance Mapping

OT segmentation is named, directly or by reference, in every framework that touches critical infrastructure and industrial security. The evidence an auditor expects is consistent: a current zone-and-conduit diagram, a rationale for each conduit, and proof the boundary is reviewed.

For operators inside the German and EU critical-infrastructure regime, the segmentation artifact is one of the core deliverables in the KRITIS firewall compliance guide, and it overlaps with the documentation set in the NIS2 Article 21 evidence mapping. Where multiple plant vendors and firewall platforms coexist, keeping one consistent policy view across them is its own problem, treated in the multi-vendor firewall management guide.

Recurring Failure Modes

Four patterns turn up again and again in OT segmentation reviews, and all four are avoidable at design time.

The flat cell. The DMZ is built correctly, then everything below Level 3 sits on one open VLAN. Lateral movement inside the production network is unconstrained, so a single compromised HMI reaches every controller on the line. Cell-level zoning is the fix, and it is the part most often deferred for cost.

The permissive conduit. A conduit is created for a commissioning task, opened wide to get the line running, and never tightened. Months later it is the widest path in the estate. Conduits need an owner and an expiry, the same recertification rhythm a healthy IT ruleset uses.

The forgotten remote-access path. A vendor VPN or a cellular modem on a controller bypasses the entire architecture. It is invisible on the network diagram because nobody from the OT team installed it. Asset discovery, not assumption, is the only way to find these.

The reversible diode. A device sold as a data diode that is really a firewall in one-way mode, configurable back to two-way by anyone with the password. If the one-way property is enforced in software, it is not a diode. Verify the hardware.

Frequently Asked Questions

Is air-gapping better than segmentation for OT?

True air gaps are rare and tend to erode the moment someone needs data off the line or a vendor needs remote support. A well-built IT-OT DMZ with diodes for one-way flows gives most of the isolation benefit while remaining operable. The honest position is that the air gap you think you have is usually a segmentation boundary you have not documented.

Can you run active vulnerability scanning on the OT network?

Cautiously, and rarely with the same tools used in IT. Many legacy devices fail under active probing. Passive monitoring that reads traffic without injecting it is the safer default for Level 2 and below. Reserve active checks for maintenance windows on equipment confirmed to tolerate them.

Where exactly does the IT-OT DMZ sit in the Purdue model?

At Level 3.5, between site operations at Level 3 and enterprise IT at Levels 4 and 5. It holds the historian replica, the patch distribution server, and the jump host. No enterprise system reaches into Level 3 or below without terminating in the DMZ first.

Do data diodes replace firewalls in OT?

No. They are complementary. Diodes secure the one-way flows where a return path must be physically impossible. Brokered firewall conduits handle the request-and-response traffic that diodes cannot carry. Most plants need both.

How often should OT conduits be recertified?

At least annually for low-change cells, quarterly where commissioning or vendor work is frequent. The trigger that matters more than the calendar is any change to the connected systems. A conduit whose purpose nobody can explain is a finding, not a footnote.

Further Reading

Authoritative external sources:

• NIST SP 800-82 Rev 3, Guide to Operational Technology Security
• ISA/IEC 62443 Series, Security for Industrial Automation and Control Systems
• CISA Industrial Control Systems Resources