Connecting an OT network to enterprise infrastructure without proper segmentation is one of the highest-risk things an industrial organisation can do. Not because connectivity is inherently dangerous — but because most teams design the firewall rules before they design the architecture, put the wrong servers in the wrong zones, and create paths between IT and OT that are never documented and therefore never reviewed.
IT network segmentation is about protecting data. OT network segmentation is about protecting physical processes — and the consequences of getting it wrong are not a data breach, they're a generation trip, a process upset, or physical damage to equipment. This changes the design priorities. In OT, patch windows are planned months in advance, system restarts may require controlled process rundown, and brief communication interruptions can cause spurious trips or missed events. The architecture must protect the OT network without affecting system availability or performance.
The defensible baseline architecture for industrial systems connecting to enterprise infrastructure is three zones separated by two firewalls:
| Zone | Contents | Key principle |
|---|---|---|
| Corporate | Workstations, AD, email, ERP, business intelligence, internet access | No direct access to OT zone |
| DMZ | Historian, jump server, file transfer, patch staging, AV update server | Buffer between IT and OT — neither side directly reaches the other |
| OT Zone | SCADA servers, HMIs, engineering workstations, PLCs, RTUs, IEDs | OT-initiated traffic allowed out; enterprise-initiated traffic cannot come in |
The key principle: OT-initiated traffic can flow from OT to DMZ. Enterprise-initiated traffic cannot reach the OT zone. The historian in the DMZ pulls data from the OPC server in the OT zone — not the other way around.
The most dangerous DMZ mistake: putting a SCADA server in the DMZ because "it doesn't have write access." Write access is not the only risk. A compromised DMZ server can be used as a pivot point or to manipulate the data operators see. SCADA servers belong in the OT zone.
Every rule in your firewall ruleset should be justified by a specific operational requirement. "Allow any" rules in either firewall are both a compliance failure and a security failure. Each rule needs a named source, named destination, specific protocol and port, and a business justification. Rules without justifications don't survive an audit review.
| Mistake | Why it's a problem | Correct approach |
|---|---|---|
| Flat OT network with a single firewall | No DMZ — one compromised server reaches OT directly | Deploy two firewalls with a proper DMZ between them |
| Historian in the corporate network | Requires opening direct ports to/from OT — bypasses DMZ concept | Historian lives in the DMZ |
| Vendor VPN terminating in the OT zone | Vendor network gets direct access to OT devices | VPN terminates in DMZ — vendor uses jump server to reach OT |
| No session logging on the jump server | Security standards require logging of interactive remote access | Configure session recording and retain logs per your retention policy |
Our free IT/OT Integration Planning Framework guides you through architecture decisions, DMZ design, security risk assessment, and testing in a structured five-phase sequence.
Published by PROMEC Systems. Architecture recommendations align with IEC 62443 zone-and-conduit model principles. Review designs with your IT security team and validate against your regulatory requirements.
