Securing the IT/OT Boundary: Technical Architecture Patterns

IT and OT networks are converging. ERP systems pull data from historians. Cloud dashboards display real-time production metrics. Vendors connect remotely to diagnose PLCs. Each connection creates a path from IT into OT.

The question is not whether to connect IT and OT. It is how to control the boundary between them.

This post covers three architecture patterns, each addressing a different aspect of IT/OT boundary security.

IT/OT Convergence: The Problem

IT and OT have different priorities. IT optimizes for confidentiality and availability of data. OT optimizes for safety and availability of physical processes. When you connect them, you inherit the risk profile of both.

What goes wrong:

• A compromised IT system (phishing, ransomware) gains access to OT through a shared network path
• A vendor VPN tunnel intended for PLC diagnostics becomes a persistent backdoor into the plant
• Cloud replication of historian data exposes OT operational patterns to anyone with cloud credentials

What convergence enables when done right:

• Real-time production visibility without manual data export
• Centralized incident response across IT and OT
• Unified compliance posture for CMMC, NIS2, and NIST 800-171

Pattern 1: Industrial DMZ

The industrial DMZ places a buffer zone between IT and OT. No direct traffic crosses from one to the other. Instead, proxy services in the DMZ relay authorized requests.

Architecture:

• Outer firewall faces IT, inner firewall faces OT
• DMZ hosts proxy bastions, historian replicas, patch servers, and log collectors
• Both firewalls default-deny all traffic; only explicitly defined flows are permitted

When to use it:

• You need to share data between IT and OT (historian data, production metrics)
• You need a staging area for patches and updates before they reach OT
• Compliance requires demonstrable boundary protection (NIST 800-171 SC-7)

Technical detail: The outer and inner firewalls should use different vendors or rule engines. If both firewalls share a vulnerability, an attacker can traverse both in a single exploit. Diversity at the boundary adds resilience.

Limitation: A single DMZ protects the boundary between IT and OT but provides no segmentation within OT itself. Lateral movement inside OT is still possible.

Pattern 2: Secure Remote Access

Remote access is the most common attack vector in OT. Vendor VPNs, remote desktop sessions, and cloud-based remote access tools create persistent paths into OT that bypass other controls.

Architecture:

• VPN terminates at the DMZ, not inside OT
• Multi-factor authentication (MFA) required for every session
• Sessions are time-limited and scoped to specific assets
• No persistent tunnels, no standing access

When to use it:

• Vendors need to connect for diagnostics or maintenance
• Remote operators need to monitor or control systems
• You need an audit trail of every remote session for compliance

Technical detail: A common mistake is terminating VPN tunnels directly on OT devices or on a jump host inside the OT network. This gives the VPN user the same network access as a local operator. Instead, terminate the VPN at a gateway in the DMZ. The gateway authenticates the user, restricts access to the specific asset they need, and disconnects when the maintenance window expires.

Limitation: Addresses remote access only. Does not segment local OT traffic or prevent lateral movement from a compromised local device.

Pattern 3: Zero Trust Segmentation

Zero trust segmentation extends security inside OT by placing enforcement points between individual assets or groups of assets. Every connection is authenticated, authorized, recorded, and inspected, regardless of whether it originates from IT or from within OT.

Architecture:

• VPN + MFA at the perimeter for remote users
• An access gate sits between network segments, recording and inspecting every session
• Each segment contains a small group of related assets (one control loop, one production cell)
• Connections between segments require identity verification (user + device)

When to use it:

• You need to prevent lateral movement inside OT
• Compliance requires per-system access control (CMMC AC.L2-3.1.1)
• You have mixed-trust environments where vendors, operators, and automated systems share the same network
• You need full session recording and inspection for audit

Technical detail: Zero trust in OT works at Layer 3. Each micro-segment gets its own subnet. The enforcement point (access gate) inspects every connection request: source identity, destination, protocol, and action. Every session is recorded with full metadata. Because enforcement is network-based, it works with legacy devices that cannot run agents or participate in authentication handshakes. The access gate authenticates on behalf of the device.

Limitation: Requires more enforcement points than a single DMZ. Operationally simpler with appliances that combine segmentation, authentication, recording, and logging in a single device.

Combining Patterns

These patterns are not mutually exclusive. A production environment typically needs all three:

Compliance Mapping

Conclusion

Securing the IT/OT boundary is not a single architecture choice. It is a layered approach: a DMZ at the boundary, zero trust segmentation inside OT, and controlled remote access for external connections. Each pattern addresses a different threat vector. Together, they provide boundary protection, lateral movement prevention, and session-level visibility.

Start with the DMZ if you have none. Add zero trust segmentation for your highest-risk OT assets. Lock down remote access with MFA, session recording, and time-limited scope. An integrated gateway appliance can deliver all three patterns from a single enforcement point.