Industrial DMZ Design and Implementation Guide

Introduction

The Industrial Demilitarized Zone (DMZ) is the security architecture that makes IT/OT integration safe. Business users need access to operational data for reporting, analytics, and planning. Vendors need remote access to support control systems. SCADA systems need to send alarms to enterprise platforms. These data flows between IT and OT are legitimate and operationally necessary, nobody is going to stop them.

Without an industrial DMZ, those data flows require direct network connectivity between IT and OT. Direct connectivity is the condition that allowed Colonial Pipeline ransomware to threaten OT operations. It is the pathway that allows an enterprise Active Directory compromise to become an OT network compromise. It is the attack surface that every threat actor targeting industrial organizations attempts to exploit. The lesson from incident after incident is the same: when IT and OT are directly connected, a breach in one becomes a crisis in both.

The industrial DMZ does not eliminate IT/OT data exchange, it restructures it. Instead of direct connections, data moves through controlled, monitored intermediary systems in the DMZ. Business users access a historian replica, not the OT historian directly. Vendors connect to a jump server, not to OT devices directly. Alarms route through an alarm forwarding server, not through a direct SCADA-to-enterprise connection. The data still flows; it just flows through architecture you control and can observe.

This guide provides a complete reference for designing, implementing, and operating an industrial DMZ, from architecture principles through component selection, data flow design, high-availability configuration, and post-implementation monitoring.

Architecture Principles

Principle 1: No Direct IT-to-OT Connectivity

The industrial DMZ exists to enforce a single rule: no direct network path from the IT network to the OT network. Every IT-OT data exchange must pass through the DMZ. This principle must be absolute. Exceptions, however well-justified by operational convenience or vendor requests, consistently become the attack vectors exploited in real incidents.

Verify enforcement by confirming there is no routing between IT subnets and OT subnets at any layer, not at the firewall, not in the routers, not via management VLANs or shared infrastructure. The absence of direct routing should be demonstrable and tested, not assumed.

Principle 2: Defense in Depth with Two Firewall Layers

A single firewall at the IT/OT boundary creates a single point of failure. The preferred architecture uses two firewalls, an IT-side firewall and an OT-side firewall, creating a true DMZ zone that is trusted by neither the IT nor the OT network.

Vendor diversity: Where budget permits, use different vendors for the IT-side and OT-side firewalls. A zero-day vulnerability in one vendor's firewall platform does not simultaneously compromise both barriers. Fortinet (IT side) + Cisco (OT side), or Palo Alto Networks (IT side) + FortiGate Rugged (OT side), are common dual-vendor combinations in practice.

Security Level alignment: The IT-side firewall enforces rules appropriate for the IT network's security level; the OT-side firewall enforces OT protocol-aware rules appropriate for the OT network's security level. The DMZ zone between them has intermediate trust.

Principle 3: Controlled, Documented Data Flows Only

Every data flow through the industrial DMZ should be documented in a data flow register with business justification, data type, frequency, and direction; implemented through a specific DMZ component designed for that flow type; enforced by firewall rules that permit only the specific source, destination, port, and protocol; and monitored for anomalies and volume deviations.

Undocumented flows should not exist. If a communication is observed traversing the DMZ that is not in the data flow register, it is either a change that was not properly managed, or an unauthorized communication requiring immediate investigation. At Beacon Security, we've found that the data flow register discipline is one of the clearest indicators of a mature OT security program, organizations that maintain it catch problems early; those that don't often discover them during incidents.

Principle 4: DMZ Systems Are High-Priority Security Assets

DMZ systems, jump servers, historian replicas, file transfer servers, patch management systems, are simultaneously accessible from both the IT and the OT network. A compromised DMZ system can be used as a pivot point to attack either environment. That dual exposure makes them high-value targets, and they need to be treated accordingly: patched on the same cadence as perimeter security systems, monitored with the same intensity as the firewall infrastructure, hardened to the enterprise server baseline or better, and subject to privilege access management with no shared accounts and all administrative access recorded.

DMZ Component Architecture

Component 1: Historian Replica

Purpose: Provides IT users with access to process data without requiring direct access to the OT historian or the OT network.

Architecture: The OT historian (OSIsoft PI, Canary Labs, Ignition Historian) pushes data to a replica historian in the DMZ. The replica is configured to accept a one-directional data push from the OT historian and to allow read-only queries from IT users. IT users never connect to the OT historian directly, they connect only to the DMZ replica.

Data flow design:

• OT historian to DMZ historian replica: Push model. The OT historian initiates the connection outward. The OT-side firewall permits outbound connections from the historian to the DMZ replica on the historian synchronization port, and nothing inbound from the DMZ to the OT historian.
• DMZ historian replica to IT users: IT users connect to the replica via the historian's native query interface (PI Web API, Canary web services, Ignition web services) or via OPC UA read-only endpoints. The IT-side firewall permits inbound connections from IT subnets to the historian replica on the appropriate port.

Security configuration: The DMZ historian should be a separate physical or virtual server from the OT historian, not a read replica accessed directly. Configure the historian synchronization to push only the tag namespaces required by business users, not the complete OT tag database. Require authentication for all IT user access, and log all queries to the replica for anomaly detection.

Component 2: Jump Server (Bastion Host)

Purpose: Provides controlled, recorded remote access to OT systems without allowing direct connectivity from the IT network or the internet to OT devices.

Architecture: The jump server is placed in the DMZ and serves as the sole remote access point for authorized users who need to access OT systems. Remote users connect to the jump server through the remote access gateway. From the jump server, they can initiate connections to authorized OT system destinations, no shortcuts, no exceptions.

Security configuration: See TG-014 (Secure Remote Access Architecture) for full jump server design details. In the DMZ context, the critical firewall rules are:

• IT-side firewall: permit inbound to jump server on RDP (port 3389) from the remote access gateway IP only. All other inbound to jump server: deny.
• OT-side firewall: permit outbound from jump server to authorized OT destination addresses on authorized ports only. No direct IT-to-OT paths.

Component 3: File Transfer Server

Purpose: Provides a controlled pathway for transferring files between IT and OT, patch packages, configuration files, reports, with mandatory malware scanning before anything crosses the boundary.

Architecture: A file transfer server in the DMZ accepts file uploads from IT and from OT. All files are scanned by an integrated antivirus/anti-malware engine before being made available in the DMZ pickup directory. A separate controlled process, whether human review or automated policy check, approves files for transfer to the destination environment.

Data flow design:

• IT to DMZ file transfer server: IT users upload files to an IT-facing share. The server scans files on upload, and approved files are placed in a DMZ pickup area.
• DMZ pickup to OT: Either an automated process (scheduled pull from an OT management server) or a manual process (OT personnel log into the jump server and retrieve approved files) moves files from the DMZ into the OT environment. The OT-side firewall permits only the specific connection from the OT management server to the DMZ file server.
• OT to DMZ to IT: Process data exports, alarm reports, and similar files initiated from OT are pushed to the file server in the DMZ, where IT can retrieve them without direct OT access.

Scanning configuration: Deploy multiple antivirus engines, dual-engine scanning consistently catches more than a single engine. Update antivirus signatures on the file transfer server independently of any OT endpoint restrictions. Quarantine all files that generate alerts; do not automatically delete, as investigation may be needed.

Component 4: Remote Access Gateway

Purpose: The internet-facing component that accepts authenticated remote access connections and routes them to the jump server.

The remote access gateway is what external users, vendors, remote employees, partners, connect to from the internet. It enforces authentication including MFA before any session reaches the jump server. See TG-014 for full architecture.

DMZ placement: The remote access gateway may be placed in the DMZ itself, accessible from the internet via the IT-side firewall with a strict DMZ-facing policy, or in a separate internet-facing zone that feeds into the DMZ. Placing it in the IT-side DMZ keeps all remote access infrastructure in a single monitored zone, which simplifies oversight.

Component 5: Patch Management System

Purpose: Provides a distribution point for security patches and software updates destined for OT systems, without requiring OT systems to connect to the internet or to IT patch management infrastructure.

Architecture: A patch management server in the DMZ receives patches and updates from the IT patch management system (WSUS, SCCM, or vendor update portal). Updates are staged in the DMZ, reviewed and approved, then distributed to OT systems from the OT side.

Approval process: A manual approval step between patch receipt in the DMZ and distribution to OT systems provides a critical review point. Security reviews the patch and vendor release notes before it is distributed to OT. This catches patches that may have compatibility issues with OT software before they reach the production environment, a safety valve that has saved more than a few facilities from avoidable outages.

Component 6: Alarm and Event Forwarding Server

Purpose: Routes process alarms and OT security events to enterprise monitoring and notification systems without requiring bidirectional access between the enterprise network and the OT alarm systems.

Architecture: A forwarding server in the DMZ receives alarm data from the OT environment, via syslog push from OT devices or via SCADA alarm export, and forwards summarized or filtered alarm data to the enterprise alarm management, SIEM, or notification platform.

Data flow design: OT SCADA pushes alarms to the DMZ forwarding server (OT-initiated, one-way push). The DMZ forwarding server reformats and forwards to the enterprise platform.

Filtering: Do not forward all process alarms to the enterprise platform, this produces alarm flood and degrades analyst attention to significant events. Filter to security-relevant events: authentication failures, network anomalies, configuration changes, and high-priority process alarms.

Optional Component: Data Diode

For data flows where the security requirement justifies hardware-enforced unidirectionality, flows where even the theoretical possibility of a return channel is unacceptable, a data diode provides hardware-enforced one-way transmission.

Data diodes are hardware devices with a transmit-only physical medium (fiber with no receive path) that physically cannot carry traffic in the reverse direction. Common use cases in the industrial DMZ: historian data replication to the IT network where bidirectional communication must be absolutely prevented; real-time process data streaming to cloud analytics where cloud access to OT must be hardware-enforced; and security log forwarding from OT to SIEM where log data must be isolated from any return communication.

Major vendors include Waterfall Security Solutions, Owl Cyber Defense, and Garland Technology. Data diodes add cost and complexity, but they provide a level of assurance that software-defined network controls cannot match, and for the highest-consequence environments, that assurance is worth it.

High-Availability Design

For industrial DMZ infrastructure supporting critical operations, high-availability configuration prevents the DMZ itself from becoming a single point of failure for operational data flows.

Firewall High Availability

Both the IT-side and OT-side firewalls should be deployed in active/passive HA pairs with identical hardware on primary and secondary units, synchronized policy and session state, sub-second failover to the passive unit on primary failure, and regular HA failover testing, quarterly at minimum, to verify failover actually functions as expected.

HA testing procedure: Simulate primary firewall failure by disconnecting power or triggering a software failover. Verify that failover occurs within the expected timeframe, that active network sessions recover or establish new sessions through the standby, that no permanent traffic drops occur for critical OT-to-DMZ data flows, and that monitoring alerts correctly identify the failover event.

DMZ Server High Availability

Historian replicas and jump servers in the DMZ should have redundancy appropriate for their criticality. Historian replicas work well in active/active with load-balanced reads, or active/passive with synchronization. Jump servers benefit from active/passive pairs with shared session recording storage, ensuring that remote access is not dependent on a single server.

Virtual machine infrastructure (VMware vSphere HA, Microsoft Hyper-V with Failover Clustering) simplifies redundancy for DMZ servers considerably.

Resilient Connectivity Design

Ensure the data flows between the OT historian and the DMZ replica, and between the DMZ and IT systems, do not depend on a single network path. Deploy dual uplinks from DMZ switches to IT and OT firewalls using port channel or LACP bonding, use redundant routing paths where feasible, and test failover configuration under simulated link failure before relying on it in production.

Data Flow Design and Documentation

Data Flow Register

Maintain a data flow register documenting every communication that passes through the industrial DMZ. At minimum, record for each flow:

The data flow register is the authoritative source for firewall rule design. Every rule should correspond to a documented flow; every documented flow should have a corresponding firewall rule. When Beacon Security validates DMZ deployments, undocumented firewall rules are always a finding, if a rule exists without a corresponding flow in the register, nobody owns it and nobody can explain why it's there.

Traffic Flow Architecture Diagram

Maintain a current architecture diagram showing the IT network, DMZ zone, and OT network; all firewall interfaces and their IP addresses; all DMZ components; arrows for each documented data flow with labels indicating protocol and direction; and zone labels indicating the security level of each zone.

The architecture diagram is essential for training, onboarding, and incident response. When something breaks or something suspicious is observed, this diagram is what the team reaches for first.

Implementation Checklist

Phase 1: Design (4-6 weeks)

• Document current state: all existing IT-OT connectivity
• Define target architecture: zone assignments, component placement, firewall placement
• Define data flows: complete data flow register for all required IT-OT communications
• Select technology: firewalls, historian platform, jump server configuration, file transfer server
• Define high-availability requirements per component
• Design firewall rule set from the data flow register
• Review with operations team: confirm all required data flows are captured

Phase 2: Build and Test in Lab (4-8 weeks)

• Procure hardware: firewalls, servers, switches
• Build DMZ in lab or staging environment
• Configure firewalls with designed rule sets
• Configure DMZ components: historian replica, jump server, file transfer server
• Test all data flows: confirm each flow in the register works as designed
• Test firewall enforcement: confirm flows not in the register are blocked
• Test high availability: failover testing for firewalls and servers
• Test monitoring: confirm logging and alerting function correctly

Phase 3: Staged Production Deployment (4-8 weeks)

• Deploy DMZ infrastructure in production network (monitoring mode initially)
• Migrate historian integration to historian replica
• Migrate remote access to new jump server and remote access gateway
• Enable IT-side firewall enforcement
• Monitor for 2 weeks: review logs for unexpected denials or anomalies
• Enable OT-side firewall enforcement
• Monitor for 2 weeks: confirm no OT data flows are impacted
• Remove any legacy direct IT-OT connections
• Verify no direct IT-OT paths remain in routing tables

Phase 4: Validation and Acceptance

• Network penetration test: verify no direct IT-to-OT paths exist
• Review all DMZ firewall rules against the data flow register
• Confirm session recording is functioning for all jump server sessions
• Confirm historian synchronization latency meets operations requirements
• Confirm monitoring and alerting is active and receiving events
• Operations team sign-off: all required data flows are functioning
• Security team sign-off: DMZ architecture meets the security requirements

Ongoing Operations and Monitoring

DMZ as a High-Value Monitoring Target

The industrial DMZ is the most important network segment to monitor. All IT-OT traffic passes through it. Any lateral movement between IT and OT will be visible in DMZ logs and traffic, which means the DMZ is both the chokepoint for security and the best vantage point for detection.

Active monitoring requirements for the DMZ: real-time log analysis for both IT-side and OT-side firewall logs; alerting on denied traffic that suggests scanning or unauthorized access attempts; volume anomaly detection for significant increases in historian synchronization traffic, unusual file transfer volumes, or high rates of failed authentication attempts; and session monitoring on the jump server, with alerts for sessions outside business hours, sessions to unauthorized destinations, or unusually long sessions.

DMZ Change Management

Changes to DMZ configuration, firewall rules, component configurations, data flows, should follow the same change management rigor as OT changes. An unauthorized rule change in the DMZ firewall that opens a direct path between IT and OT effectively defeats the entire architecture. All DMZ changes require documented justification, technical review, and approval before implementation. Treat DMZ rule changes with the same seriousness you'd apply to a change on a safety system.

Conclusion

The industrial DMZ is the architectural control that makes IT/OT integration safe and manageable. With a properly designed and implemented DMZ, organizations can provide business users with the operational data they need, vendors with the remote access they require, and OT systems with the IT services they use, without creating the direct connectivity pathways that attackers exploit.

The investment in DMZ design and implementation is substantial, but the operational benefits extend beyond security: a well-designed DMZ with a historian replica, file transfer server, and managed remote access is also better infrastructure than the ad-hoc connectivity arrangements it replaces. Organizations that have gone through this process consistently tell us the security improvement was worth it, but they valued the operational clarity almost as much.

Beacon Security provides industrial DMZ design, implementation, and validation services for organizations building or upgrading their IT/OT boundary security architecture. Contact us to design the industrial DMZ appropriate for your environment and business requirements.