An industrial DMZ prevents direct communication between IT and OT networks. Instead of allowing ERP servers to query PLCs directly, all cross-boundary traffic routes through a controlled buffer zone where it can be inspected, authenticated, and logged.
Understanding the Role of an Industrial DMZ
An industrial DMZ separates IT and OT into distinct security zones with a buffer in between. Unlike a traditional IT DMZ (which faces the internet), an industrial DMZ faces inward, sitting between two trusted-but-different networks.
Its job is simple: no packet travels directly from IT to OT or vice versa. Every connection passes through a service in the DMZ that proxies, translates, or relays the request.
What Lives in the DMZ
Typical DMZ services include:
- Proxy bastions that relay requests between IT and OT without allowing direct connections
- Historian replicas that mirror OT data for IT consumption without exposing the source historian
- Patch servers that stage updates for OT devices without giving the patch management system direct OT access
- Log collectors that aggregate OT logs for the enterprise SIEM
- Access gates that authenticate and authorize every cross-boundary session
Why Not Just a Firewall?
A single firewall between IT and OT creates a binary allow/deny boundary. It cannot inspect application-layer protocols, authenticate users per session, or provide visibility into what happens after a connection is allowed.
A DMZ adds depth. The outer firewall controls what enters from IT. The inner firewall controls what reaches OT. The services between them inspect, authenticate, and log every transaction.
Designing the DMZ
Dual Firewall Architecture
Place a firewall on each side of the DMZ:
- Outer firewall (IT-facing): Allows only specific IT systems to reach DMZ services. Denies all direct IT-to-OT traffic.
- Inner firewall (OT-facing): Allows only DMZ services to reach specific OT assets. Denies all direct DMZ-to-OT traffic that is not explicitly permitted.
Technical detail: The outer and inner firewalls should be from different vendors or use different rule engines. If an attacker finds a vulnerability in one firewall platform, the second provides an independent barrier. Both firewalls should default-deny all traffic and only permit explicitly defined flows.
Access Control at the Boundary
Access control determines who can cross the DMZ and what they can do once they cross.
Role-Based Access Control (RBAC): Assign permissions based on operational role. A maintenance engineer gets access to specific PLCs during a maintenance window. A vendor gets read-only access to a single HMI for diagnostics. No one gets blanket access to "the OT network."
Network Access Control (NAC): Validate device identity and compliance before granting access. A laptop with outdated patches or missing endpoint protection does not enter the DMZ, regardless of the user's credentials.
Time-limited sessions: Vendor and remote access sessions should expire automatically. No persistent tunnels, no standing access.
Monitoring and Logging
Every DMZ service should log:
- Source identity (user, device, IP)
- Destination asset
- Protocol and action (read, write, configure)
- Timestamp and duration
These logs serve two purposes: real-time threat detection and compliance evidence. CMMC, NIS2, and NIST 800-171 all require access logging at system boundaries.
Zero Trust Within the DMZ
A DMZ is not a trusted zone. Apply zero trust principles inside it:
- Microsegmentation: Isolate DMZ services from each other. The patch server should not be able to reach the historian replica. Each service gets its own micro-segment.
- Per-session authentication: Every connection through the DMZ authenticates the user, the device, and the requested action. No cached credentials, no inherited sessions.
- Continuous monitoring: Baseline normal DMZ traffic and alert on deviations. A historian replica that suddenly initiates outbound connections to the internet is an anomaly worth investigating immediately.
Compliance Alignment
CMMC
- AC.L2-3.1.3: Control the flow of CUI in accordance with approved authorizations. The DMZ enforces flow control between IT (where CUI may reside) and OT.
- AU.L2-3.3.1: Create and retain system audit logs. DMZ services generate per-session logs with identity, action, and timestamp.
NIS2
- Article 21: Requires risk-based security measures including access control and incident handling. The dual-firewall DMZ with session logging satisfies both.
- Incident reporting: DMZ logs provide the forensic evidence needed for the 24-hour early warning and 72-hour incident notification timelines.
NIST 800-171
- SC-7 (Boundary Protection): The DMZ is the boundary protection mechanism. Dual firewalls, proxy bastions, and access control enforce the boundary.
- AC-17 (Remote Access): Remote sessions through the DMZ are authenticated, encrypted, and logged.
Conclusion
An industrial DMZ is not just a firewall rule. It is a controlled zone with its own services, its own access policies, and its own monitoring. Design it with dual firewalls, populate it with proxy services that prevent direct IT-OT traffic, and enforce access control per user, per device, per session.
The goal is simple: no uncontrolled path between IT and OT. Every cross-boundary connection is authenticated, inspected, and logged.
