What is a DMZ in industrial networks?

VLANs are sufficient for most industrial environments, provided the firewalls between zones enforce strict access control lists and the VLANs are properly segregated at the switch level. Physical separation (separate switches, separate cabling) provides stronger isolation and is recommended for high-security environments, critical infrastructure, or sites where regulatory requirements demand physical segmentation (defense, nuclear, water/wastewater).

The key security requirement is that traffic crossing the iDMZ boundary must pass through a firewall with enforced rules and logging. VLAN hopping vulnerabilities are a concern, so use 802.1Q trunk isolation, disable DTP (Dynamic Trunking Protocol), and regularly audit switch configurations to prevent VLAN leakage.

No. The internet-facing DMZ and the iDMZ serve different purposes and should not be combined. The internet-facing DMZ buffers your internal IT network from the internet and hosts public-facing services (web servers, email gateways). The iDMZ buffers your OT network from your IT network. Combining them means an internet-exposed service compromised by a public attack now has network proximity to systems that can reach your OT environment.

Best practice is to implement three separate zones: an internet-facing DMZ between the internet and the IT network, the IT network itself, and an iDMZ between the IT network and the OT network. Each boundary has its own firewall with its own security policy.

Quarterly audits are the recommended baseline. Firewall rules accumulate over time as temporary exceptions become permanent and forgotten. Each audit should identify unused rules, overly broad rules, and rules with no documented business justification. Automated firewall rule analysis tools can help by identifying unused rules based on traffic logs.

Additionally, any change to firewall rules should go through a formal change control process with documented approval, a defined purpose, and a scheduled expiration date for temporary rules. Many organizations implement "default expiration" policies where temporary rules are automatically disabled after 30 or 60 days unless explicitly renewed.

Properly implemented, no. Outbound tunneling solutions like Cogent DataHub add minimal latency (typically less than 50 ms) because they maintain persistent encrypted tunnels rather than establishing new connections for each data transfer. MQTT pub/sub through an iDMZ broker is real-time by design; subscribers receive published data as soon as it arrives at the broker.

The performance concern with iDMZ architectures is typically around firewall throughput, not the data transfer pattern itself. Industrial firewalls must be sized appropriately for the volume of OT-to-IT data transfer. Deep packet inspection and IPS features on the firewall can introduce latency if not properly tuned for industrial protocols. For high-volume historian replication or streaming analytics, select firewalls with sufficient throughput and test under realistic load before deployment.

These terms are sometimes used interchangeably, but "screened subnet" is the more precise networking term for a network segment separated from two other networks by firewalls on both sides. An iDMZ is the industrial-specific application of the screened subnet architecture, positioned between IT and OT networks with specific design principles (outbound-only from OT, no dual-homed hosts, minimal services, logging of all boundary crossings).

In practice, if you see "screened subnet" in the context of OT security, it is describing the same dual-firewall architecture as an iDMZ. ISA/IEC 62443 uses the term "conduit" to describe the controlled pathways between zones, and the iDMZ is the physical implementation of a conduit with bidirectional communication capability under strict control.

Retrofitting an iDMZ into a running plant requires careful planning and staged implementation. Start with a network assessment to document all existing IT-to-OT connections, identify which systems need cross-boundary communication, and determine current data flow patterns. Then design the target iDMZ architecture with explicit rules for which connections will be permitted and through which mechanisms (tunneling, jump servers, MQTT broker, etc.).

The implementation is typically staged: deploy the iDMZ zone and its firewalls, migrate services one at a time (start with read-only data consumers like historians, then add jump servers for remote access, finally migrate bidirectional services), and verify functionality at each stage before proceeding. The most disruptive phase is cutting over the OT-facing firewall, which will require a coordinated outage window. Budget 6–12 months for a full migration in a complex industrial site, and plan for vendor coordination since many OT vendors will need to reconfigure their remote access methods to comply with the new architecture.