A DMZ between IT and OT is a security pattern, not a single blueprint. In regulated, long-lifecycle plants, the “best” structure is one that reduces risk while remaining operable, maintainable, and supportable across legacy systems, vendor constraints, and validation requirements.
Core principles for an IT/OT DMZ
Before deciding on specific topology, align on a few principles that are usually non-negotiable in regulated environments:
- Segregation of duties and zones: IT, DMZ, and OT should be distinct security zones with explicit policies, not just VLANs on the same flat network.
- Least privilege for connectivity: Only flows required for operations, monitoring, or compliance are allowed, and they are tightly scoped by source, destination, protocol, and port.
- Minimize OT exposure: OT assets (PLCs, DCS, SCADA, historian, MES servers) should never be directly reachable from the corporate network or the internet.
- Deterministic and auditable paths: Every route between IT and OT is known, documented, and controllable under change control.
- Protocol and vendor reality: The design must accommodate OT protocols, vendor remote support requirements, and obsolete operating systems without pretending they are easily replaced.
Common DMZ reference structure
A common and generally defensible approach in manufacturing is a two-firewall DMZ with clearly separated functions:
- Firewall 1 (IT edge to DMZ): Separates corporate/enterprise IT from the DMZ.
- DMZ zone: Hosts systems that must communicate with both IT and OT but are not allowed to initiate direct sessions into OT uncontrolled.
- Firewall 2 (DMZ to OT edge): Separates OT from the DMZ, typically with more restrictive rules and higher scrutiny.
In many plants, the firewalls are from different vendors to reduce common-mode vulnerabilities, but this is not always achievable, especially where validation and support are constrained.
What typically belongs in the DMZ
Systems in the DMZ should be those that legitimately require bidirectional communication with both IT and OT but where compromise should not immediately compromise control systems. Typical examples include:
- Replication and integration endpoints:
- Historian replication servers (OT historian to enterprise historian)
- MES/ERP integration brokers or application gateways
- Middleware or message queues bridging plant data to enterprise analytics
- Remote access termination:
- Jump hosts / bastion servers used by vendors or engineering for remote access
- VPN concentrators that terminate partner or vendor connections
- Security and monitoring tooling:
- Central log collectors or SIEM connectors that forward OT logs to enterprise SIEM
- Passive OT network monitoring sensors that export data northbound
- Patch and update staging (where feasible):
- Antivirus/EDR update relays
- Patch management staging servers used for OT (often with additional manual gating)
By contrast, PLCs, RTUs, controllers, and core HMI/SCADA servers usually stay in the OT zone, not in the DMZ.
Traffic patterns: one-way vs controlled bidirectional
The most robust designs start from the premise that OT should not depend on inbound traffic from IT to keep producing. Under that assumption:
- Prefer one-way or data-export patterns where possible:
- OT historian sends data to DMZ historian or replication node.
- DMZ node then forwards subsets to enterprise analytics or cloud endpoints.
- For strict segregation, data diodes or unidirectional gateways can enforce one-way flows, though these introduce cost and operational complexity.
- When bidirectional is required:
- Restrict connections to specific application gateways or integration services in the DMZ.
- Disallow direct desktop-to-PLC or corporate-laptop-to-HMI sessions.
- Use jump hosts with multi-factor authentication and strong session recording where remote administration is needed.
In practice, brownfield OT often requires some level of bidirectional communication for MES, recipe management, electronic batch records, and quality systems. The key is to concentrate and mediate this traffic via DMZ-resident services instead of exposing OT directly to IT.
Segmentation within OT and the DMZ
A DMZ is not a substitute for proper segmentation inside OT networks. In many plants, the more realistic goal is:
- Tiered OT zones: Separate safety systems, critical control networks, and less critical monitoring networks, each with its own policies.
- Cell or line-level segmentation: Use VLANs and firewalls or industrial security appliances to prevent lateral movement across manufacturing lines.
- DMZ micro-segmentation: Group DMZ hosts by function (e.g., integration, remote access, monitoring), and limit east-west traffic so compromise of one host does not expose all others.
These measures can usually be introduced incrementally, which is important when downtime for large redesigns is not practical.
Identity, access control, and monitoring
Structuring the DMZ is not only about topology. In regulated environments, the following controls are often as critical as the network design itself:
- Centralized identity for DMZ and OT edge systems where feasible: For example, a dedicated OT Active Directory forest, selectively federated with IT, to keep blast radius smaller while enabling traceable user access.
- Strong authentication for jump hosts and remote access: Multi-factor authentication, short-lived credentials, and role-based access help enforce least privilege.
- Logging and monitoring: DMZ firewalls, jump hosts, and integration servers should feed logs to a SIEM, with clear ownership for triage and response.
- Configuration management and baselines: Golden images, hardened builds, and documented baselines are important for demonstrating due diligence and supporting incident investigation.
Change control, validation, and lifecycle realities
In regulated, long-lifecycle manufacturing, DMZ architectures must respect:
- Change control and validation: Any changes to firewall rules, DMZ-hosted integration components, or remote access patterns typically fall under formal change management. For GxP or aerospace, they may require validation or re-qualification of connected systems.
- Downtime constraints: Large-scale network re-segmentation or firewall replacement may not be practical if they require prolonged outages across multiple lines or test cells.
- Vendor and protocol lock-in: Many OT assets run obsolete operating systems or proprietary protocols that limit hardening options and force compromises in DMZ design.
- Long asset lifetimes: Controllers and OT servers may be in place for 10–20 years. The DMZ needs to be designed with an expectation of coexisting with multiple generations of equipment and systems.
Because of these constraints, full rip-and-replace network architectures are rarely viable. Most plants incrementally move toward a stronger DMZ posture by:
- Standing up the DMZ and firewalls first with minimal, well-controlled traffic.
- Gradually migrating integrations and remote access paths into the DMZ.
- Tightening rules and decommissioning legacy direct connections as each dependency is addressed and, where needed, revalidated.
Interactions with existing MES, ERP, and cloud integrations
Any DMZ design must co-exist with existing systems:
- MES and batch systems: Often require deterministic, low-latency communication with controllers. Placing core MES servers inside OT and using DMZ-based integration nodes for ERP/cloud is a common compromise.
- ERP and PLM: Typically stay on IT. Data exchange via message brokers, web APIs, or file drops should pass through the DMZ, not direct OT-to-ERP links.
- Cloud-based analytics or historian services: DMZ-based gateways or collectors are typically used to manage outbound-only connections and to buffer data if connectivity is disrupted.
Every such integration should have clearly documented data flows, ownership, and failure modes, especially where production release decisions or quality records depend on those data.
Key tradeoffs and design decisions
When determining the “best” DMZ structure for your environment, expect to explicitly weigh:
- Security vs. operational flexibility: Stronger isolation (e.g., one-way gateways) improves security but can limit remote troubleshooting and increase MTTR without parallel processes.
- Complexity vs. supportability: Multiple firewalls, micro-segmentation, and diverse vendors improve defense-in-depth but can strain local support teams if documentation and training lag.
- Standardization vs. plant-specific realities: Corporate-standard architectures are desirable, but plants with older or more sensitive assets may need exceptions and phased adoption.
- Upfront redesign vs. incremental hardening: Big-bang re-architecture can be efficient in theory but is usually hard to validate and schedule. Incremental improvements are more survivable, though they can leave temporary gaps.
How to move toward a robust IT/OT DMZ
In practice, most organizations advance through stages rather than achieving an ideal design immediately:
- Document current flows: Identify all existing IT/OT connections, including “temporary” ones that became permanent.
- Define target zones and basic DMZ: Agree on what belongs in IT, DMZ, and OT, and implement core firewalls.
- Migrate high-risk traffic first: Remote access and direct OT exposure to IT or internet should be routed through DMZ-based jump hosts or gateways.
- Introduce logging and monitoring: Ensure that DMZ and firewall activities are observable and that responsibility for review is assigned.
- Refine and validate: Iterate on rules and zoning as you learn, incorporating formal change control and, where applicable, validation testing.
Because every plant’s legacy stack, regulatory context, and vendor ecosystem is different, the best DMZ structure is the one that achieves a defensible balance of isolation, operability, traceability, and long-term maintainability for your environment.
