Secure IT/OT Network Architecture for Manufacturing (IDMZ Guide)

Most manufacturing plants make the same mistake: they install a firewall between IT and OT networks and call it segmentation. In reality, a firewall with bidirectional rules between an IT server and an OT historian is not segmentation—it’s a managed bridge. This guide covers four proven data exchange patterns (firewall-controlled, IDMZ proxy, unidirectional gateway, and data diode), shows how to configure OPC-UA security across zone boundaries, explains historian replication without creating return paths, and details where Thinfinity’s brokered access fits within an IDMZ architecture—all without bridging IT and OT.

Why IT/OT Network Bridging Creates Cascading Risk

What Network Bridging Actually Means?

Network bridging occurs when a device, application, or protocol creates a routable path between two segments that should be isolated. A firewall between IT and OT with an “allow established” rule for historian polling traffic is a bridge—managed, yes, but the OT network is reachable from IT through legitimate permitted connections. An attacker who compromises an IT server with a permitted connection to the OT historian can pivot through that path.

The risk is not theoretical. The Colonial Pipeline attack, the Oldsmar water treatment incident, and the Triton/TRISIS malware that targeted safety systems in a petrochemical plant—each involved traversal from IT to OT through a connection path that existed for legitimate reasons. As the confirms, manufacturing has been the most attacked sector for five consecutive years.

“Manufacturing tops the target list for the fifth year. The sector accounted for 27.7% of incidents observed by X-Force”

newsroom.ibm.com

It reinforces this trend: manufacturing accounted for 65% of all industrial ransomware incidents in Q2 2025, with construction and discrete manufacturing subsectors bearing the heaviest impact. North America alone recorded 355 incidents in that quarter.

Why OT Networks Amplify IT Threats?

IT security professionals new to OT often underestimate why an OT compromise is categorically different from an IT breach. Four characteristics of OT environments make the consequences far more severe:

Long device lifecycles: PLCs, RTUs, and DCS controllers in manufacturing plants have operational lifespans of 15 to 25 years. A PLC commissioned in 2008 is running firmware written before modern security practices were applied to embedded systems. These devices frequently lack authentication, encryption, and the ability to be patched without vendor-managed firmware updates that require production downtime.

Real-time deterministic operation: OT networks are engineered for deterministic, low-latency communication between controllers. A network scan, broadcast storm, or unexpected traffic burst that an IT network would absorb without issue can disrupt PLC ladder logic execution timing and cause equipment to behave unexpectedly—potentially causing physical damage or safety incidents.

Safety system integration: Safety Instrumented Systems (SIS) monitor process conditions and trigger emergency shutdowns when parameters exceed safe limits. The Triton/TRISIS malware specifically targeted SIS controllers—not to cause an immediate incident, but to disable the safety response to an engineered process failure. Attacks on OT networks have the potential to cause physical harm to people, not just data loss.

No EDR, no patch cadence: OT endpoints—HMI workstations, historian servers, engineering workstations—often run Windows operating systems that are years or decades out of support. Installing endpoint detection and response (EDR) software requires vendor validation and can void software support agreements. The OT environment simply cannot be defended using the same tools and processes that work in IT.

Four IT/OT Data Exchange Patterns

There are four distinct approaches to IT/OT data exchange, each with a different security posture. Understanding the differences—as outlined in frameworks like and —is the foundation for a defensible architecture.

Pattern 1: Firewall-Controlled Exchange

A firewall with explicit rules permitting specific IT/OT traffic (historian polling, SCADA queries, MES writes) is the most common pattern—and the most commonly misunderstood. It provides access control and logging, but does not eliminate the network path between zones. Rules accumulate over time as integrations grow, and each addition makes the boundary more permeable.

Firewall-controlled exchange is only acceptable for low-sensitivity data flows from an OT DMZ intermediary (not directly from Level 2 or below), with strict change control and regular rule review.

Pattern 2: IDMZ Proxy (Recommended for Most Plants)

The Industrial DMZ (IDMZ) proxy places an intermediary zone between IT (L4/5) and OT (L3 and below). All data exchange between IT and OT flows through the IDMZ—there are no direct connections between the two networks. From the IT side, the IDMZ presents a data service endpoint (a historian mirror, an OPC-UA server, an API endpoint) that IT systems consume. From the OT side, OT systems push data to the IDMZ using outbound connections, which are inherently less dangerous than inbound connections from IT to OT. The ISA/IEC 62443 series uses the Purdue Reference Model to describe how data should flow through industrial networks using zones and conduits.

The critical security property of the IDMZ proxy pattern is asymmetric data flow: OT pushes to the IDMZ (outbound from OT), IT reads from the IDMZ (IT-to-IDMZ only). The IT network never has a connection path into OT. If the IDMZ is compromised, the attacker can access the mirrored data, but cannot reach OT systems directly—they would need to compromise the IDMZ-to-OT connection as a second step, which the OT firewall prevents by permitting only outbound connections from OT.

The IDMZ typically hosts: historian mirror servers (OSIsoft PI Relay, AVEVA Data Hub Edge), OPC-UA aggregation servers, REST/MQTT brokers for event data, MES data staging tables, and the Thinfinity secondary broker for brokered VDI and vendor access sessions. None of these systems have a routable path to OT Level 2 or below—they receive data pushed from OT or serve brokered sessions to specific assets through the broker architecture.

Pattern 3: Unidirectional Security Gateway

A unidirectional gateway is a hardware device that physically enforces one-way data flow between network segments. The device contains a transmit fiber and a receive fiber—but only one direction has an active transmitter. Data can flow from the OT side to the IT side, but the laws of physics prevent any data from flowing in the reverse direction. There is no software vulnerability, no misconfigured firewall rule, and no protocol exploitation that can create a bidirectional connection through hardware unidirectional gateway.

The FLIP is a rack-mounted appliance with transmit-only hardware on the OT side. HALO extends this with application-level data transformation, supporting protocol translation (Modbus, OPC-DA, OPC-UA, PI, MQTT) while maintaining hardware-enforced directionality. Owl Cyber Defense, Genua, and Fox-IT (now NCC Group) are other vendors in this space.

“Gateway hardware ensures one-way data flow, preventing any inbound threat.”

waterfall-security.com

The tradeoff: unidirectional gateways only support data flows in the hardware-enforced direction. Management access, software updates, and any return-path data exchange require alternative channels (separate networks, physical access, out-of-band management). For manufacturing environments that need bidirectional data exchange—like sending production schedules from IT to OT—a unidirectional gateway must be combined with a carefully designed protocol that encodes return signals into the forward data stream, or a separate hardware gateway for each direction.

Unidirectional gateways are the right choice for environments with IEC 62443 SL3/SL4 requirements, safety-critical production where even a software misconfiguration creating a return path is not acceptable, and critical infrastructure sectors (power generation, chemical manufacturing, defense) where regulations specify hardware data diodes. For most general manufacturing at SL2, the IDMZ proxy pattern provides sufficient assurance without the operational constraints.

Pattern 4: Software-Defined Data Diode

A software data diode implements one-way flow at the application layer. The most common example in manufacturing is OSIsoft PI Relay (now AVEVA PI Relay): the OT PI Server pushes tag data to the IDMZ Relay, which republishes to an IT PI Server. The relay has no return-channel connection to the OT server. MQTT brokers with write-only OT credentials and read-only IT credentials work similarly for event data.

Software diodes provide strong assurance for specific data flows but depend on correct configuration. For IEC 62443 SL3/SL4 requirements, hardware unidirectional gateways are the appropriate control.

Data Flow Across Purdue Model Zones

The Purdue Model defines the security zones—but the architecture question is which data flows between which zones, through what mechanism, and in which direction. Understanding this mapping is essential before choosing specific tools and protocols.

Enterprise (Level 4/5): Business systems, ERP, analytics, cloud. Receives production KPIs, quality metrics, energy consumption data. Sends production schedules downward through the IDMZ—never directly to OT. Systems include SAP, Oracle ERP, Power BI, Tableau, MES analytics, and EAM/CMMS.

IDMZ (Industrial DMZ): The architecture linchpin. Hosts historian mirrors (PI Relay, AVEVA Data Hub Edge), OPC-UA aggregation servers, MES data staging tables, REST/MQTT brokers, and the Thinfinity secondary broker. Connection rules: OT pushes into the IDMZ (outbound from OT), IT reads from the IDMZ (IT-to-IDMZ only).

Operations (Level 3): Historian, MES execution, engineering workstations—the OT data origin. The OSIsoft PI Server collects tag data from L2 and pushes to the IDMZ relay (outbound only). Engineering workstations are accessed through brokered sessions from the IDMZ broker, not directly from IT. Connection rules: outbound to IDMZ permitted; inbound from IT blocked.

Supervisory (Level 2): SCADA, HMI, batch systems. Writes process values to L3 historian via OPC-DA/OPC-UA (L2 to L3 only). No enterprise network connection. Access in: brokered only.

Control (Level 1): PLCs, RTUs, DCS controllers. Communicate via Modbus, EtherNet/IP, PROFINET to L2 SCADA and DCS. No routable network connection to L3 or above.

IT/OT Data Flow Patterns: Allow, Block, and Mechanism

The table below maps common manufacturing data exchange requirements to their recommended direction, mechanism, and tools.

OPC-UA Security for Cross-Zone Data Exchange

OPC-UA (OPC Unified Architecture) is the dominant data exchange standard for modern manufacturing OT environments, replacing the legacy OPC-DA protocol that required Windows DCOM—a notoriously difficult protocol to secure across network boundaries. OPC-UA is designed for secure, cross-platform data exchange, but only if its security features are correctly configured. According to the , Sign+Encrypt with X.509 certificate authentication is the minimum for any session crossing zone boundaries.

OPC-UA Security Modes: Why ‘None’ Is Never Acceptable Cross-Zone

OPC-UA defines three message security modes: None (plaintext, unauthenticated), Sign (digitally signed for integrity but not encrypted—content visible to network observers), and Sign & Encrypt (signed and encrypted—the only mode appropriate for cross-zone exchange).

‘None’ security mode is commonly deployed in OT environments because it simplifies commissioning and avoids certificate management overhead. For OPC-UA servers communicating within an isolated OT segment (L1 to L2, L2 to L3), the absence of encryption may be acceptable if the segment is physically and logically isolated. But for OPC-UA sessions crossing zone boundaries—from L3 to the IDMZ, or from the IDMZ to IT—‘None’ mode is never acceptable. Network traffic crossing zone boundaries is observable from both connected zones, and any observer in the IDMZ can capture unencrypted data streams.

For L3 OT to IDMZ connections, use Sign+Encrypt with CA-signed certificates and Basic256Sha256 security policy minimum. For IDMZ to IT, automate certificate rotation using a PKI solution like Microsoft CA or HashiCorp Vault. For legacy OPC-DA devices that cannot support OPC-UA directly, deploy a Kepware or Matrikon gateway in the OT L3 zone to translate to OPC-UA before data crosses zone boundaries.

OPC-UA Certificate Management in Manufacturing

OPC-UA security requires X.509 certificates on every client and server. Certificate management in OT is operationally harder than IT for several reasons: OT devices have limited certificate storage capacity, many cannot perform automated certificate enrollment (no EST or ACME client), certificate expiry causes OPC-UA sessions to drop and may halt data collection, and updates on PLC-connected systems typically require a maintenance window.

The recommended approach is a two-tier PKI: an offline root CA (air-gapped, physically secured) signing an online issuing CA in the IDMZ. The issuing CA handles certificate issuance for OPC-UA servers and clients in the IDMZ and reachable OT devices. For devices that cannot perform automated enrollment, implement a documented manual renewal procedure with calendar reminders set 60 days before expiry—giving the operations team time to schedule a maintenance window before expiry causes disruption.

Keep OT and IT PKI hierarchies separate. Separate hierarchies ensure that a compromise of the IT PKI does not affect the integrity of OT certificate authentication, and vice versa.

Historian Replication: OSIsoft PI and AVEVA Across Zones

The process historian is typically the highest-value data source IT needs from OT. The correct replication pattern uses two separate PI Server instances: one in OT L3 receiving tag data from SCADA/HMI, and one in the IDMZ (or IT zone) receiving replicated data. The replication link is configured so the OT PI Server initiates the connection outbound—the IDMZ server never polls into OT.

OSIsoft PI Relay implements this as a purpose-built component in the IDMZ. AVEVA Data Hub Edge works similarly for AVEVA Historian environments. The principle: OT pushes out, the IDMZ holds the data, IT reads from the intermediary.

Common Historian Mistakes

Direct PI-to-PI trust (no relay): Connecting an IT PI Server directly to an OT PI Server through a firewall rule creates a bidirectional trust relationship. The IT PI Server can issue queries to the OT PI Server, and any compromise of the IT server gives the attacker access to OT data and the historian’s network-adjacent position. Always use an IDMZ relay between the two servers.

PI Server in IDMZ with OT firewall access: Placing the PI Server in the IDMZ and giving it a firewall rule to reach OT L3 for direct tag collection is equivalent to bridging—the PI Server becomes a dual-homed system with connections to both IDMZ and OT. If compromised from IT, the attacker has an OT-connected host. The IDMZ PI Server should only receive pushed data from OT, never make outbound connections to OT.

Wide-open PI trust store: IT-side PI clients should be trusted only for the IT/IDMZ PI Server, not the OT PI Server. A client trusted to query both servers directly is a bridging risk.

PI Asset Framework crossing zones: If PI AF is configured to pull from both the OT PI Server and an IT PI Server without going through the relay, it creates a cross-zone connection dependency. Design PI AF to reference only the IDMZ or IT PI Server—use replicated data, not the OT source.

Ecosystem Tools for Secure IT/OT Data Exchange

Waterfall Security: Hardware Unidirectional Gateways

Unidirectional gateways are hardware gateways that physically enforce one-way data flow. The FLIP is a rack-mounted appliance with transmit-only hardware on the OT side. HALO extends this with application-level protocol translation (Modbus, OPC-DA, OPC-UA, PI, MQTT). These are the right choice for IEC 62443 SL3/SL4 environments and safety-critical production.

Claroty: Detecting Unauthorized Boundary Crossings

Continuous threat detection monitors OT network traffic passively and alerts on patterns that violate intended zone boundaries—IT systems reaching OT Level 2 directly, unauthorized protocols on OT segments, new connections between OT devices not part of the baseline map, or data volumes inconsistent with normal historian replication. Its zone and conduit management feature maps segments to Purdue levels and flags violations in real time.

The practical workflow: deploy Claroty on mirror ports of switches in each zone (OT L3, IDMZ, IT), configure zone boundaries in the asset management console, and set alerts for any inter-zone traffic that does not match defined conduit paths. Monthly Claroty reports on zone boundary violations become a standing agenda item in your IT/OT security governance review.

Kepware and Matrikon: OPC-UA Protocol Translation

Many plants have legacy devices using Modbus, Allen-Bradley DF1, Siemens S7, or OPC-DA over DCOM. Kepware KEPServerEX translates 150+ legacy protocols into OPC-UA. Matrikon (now Honeywell) provides similar gateway functionality. Deploy these in OT L3 or the IDMZ so the aggregator consumes OPC-UA with Sign+Encrypt security instead of needing direct legacy device connectivity.

MQTT and Sparkplug B: Event-Driven Data Exchange

MQTT is a lightweight pub-sub protocol for constrained devices. adds a standardized payload structure for OT data including device birth/death certificates and tag change events. The IDMZ pattern: broker in the IDMZ, OT publishes outbound, IT subscribes from IDMZ. Common brokers include HiveMQ, EMQX, and Inductive Automation Ignition. AWS IoT Core and Azure IoT Hub serve as IT-side consumers for cloud analytics.

IT/OT Anti-Patterns: Common Mistakes and Fixes

The following anti-patterns appear repeatedly in manufacturing environments. As and both emphasize, effective segmentation requires more than perimeter firewalls—it demands microsegmentation and continuous monitoring. Each anti-pattern below creates a security gap that may not be obvious from a high-level network diagram but becomes visible under security review or during an incident investigation.

“Without OT-specific security, manufacturers face catastrophic downtime, safety risks, and regulatory penalties.”

rockwellautomation.com

Where Thinfinity Fits—Without Bridging IT and OT

The Secondary Broker in the IDMZ

Thinfinity’s secondary broker (Relay Gateway) deploys in the IDMZ. It initiates an outbound connection to the primary Thinfinity Gateway in the IT zone or cloud and maintains an encrypted tunnel for proxied session traffic. Its only network connectivity is outbound to the Gateway (IDMZ to IT/cloud) and outbound to specific authorized OT assets (IDMZ to OT L2/L3 for sessions defined in the access policy).

Session flow: user device → Thinfinity Gateway (IT/cloud) → secondary broker (IDMZ) → target OT asset. The user never gets a network path to OT. The OT firewall permits only outbound connections from the broker to specific assets on specific ports—no inbound rules from IT to OT are needed.

This is architecturally distinct from a VPN or jump server. A VPN gives network-level access to the entire OT segment. The Thinfinity broker reaches only the hosts and ports explicitly permitted—a much smaller attack surface.

Protocol Support for OT Assets

Thinfinity’s multi-protocol session delivery (RDP, VNC, SSH, Telnet, TN3270/5250) covers the full range of OT access methods. Each session is a protocol-specific proxy to a specific host and port. No other OT assets are reachable through that session, and it terminates when the user disconnects.

Session Recording for Audit and Forensics

Every session brokered through Thinfinity to an OT asset is recorded—capturing the full session video or action log, the authenticated user identity, the target asset, the session duration, and the termination method. These recordings are stored in a location inaccessible to session participants and provide the audit trail required by IEC 62443 SR 2.8 for remote maintenance sessions crossing zone boundaries.

The session recording also provides the forensic record for incident investigations involving the brokered access path. If an OT asset shows unexpected configuration changes after a maintenance session, the recording allows your security team to review exactly what the engineer or vendor did during that session—distinguishing an authorized change from an unauthorized action in the same session window. This forensic capability is not available for sessions conducted through VPN or shared jump servers.

Conclusion

Manufacturing plants face a stark choice: controlled segmentation or undefended exposure. The IDMZ proxy pattern with OPC-UA Sign+Encrypt and historian relay delivers defensible IT/OT separation for IEC 62443 SL2 compliance. Thinfinity’s brokered access eliminates dual-homed jump servers while meeting forensic requirements. Start with your current state assessment: identify unintended bridges and implement the IDMZ pattern as your foundation. Secure IT/OT integration is achievable—bridging is not inevitable.