Inside an OT DMZ: Why a Firewall Alone Is Not Enough
In many industrial environments, cybersecurity architecture is summarized with a simple statement:
“We have a firewall between IT and OT.”
That sounds reassuring.
But a firewall alone does not create an OT security architecture.
Between enterprise IT networks and industrial control systems lies one of the most important—and frequently misunderstood—areas of industrial cybersecurity:
The OT DMZ.
Often associated with Level 3.5 of the Purdue Model, the Industrial Demilitarized Zone is not simply another network segment.
It is a controlled boundary between two environments with fundamentally different priorities.
Enterprise IT is designed around information, users, applications, and business services.
OT is designed around physical processes, deterministic control, availability, and safety.
The OT DMZ exists because directly connecting these two worlds creates unnecessary risk.
But building an effective OT DMZ requires much more than placing a firewall between them.
What Is an OT DMZ?
An OT DMZ is an intermediate security zone positioned between enterprise IT and industrial OT networks.
Its purpose is to prevent unnecessary direct communication between the two environments.
A simplified architecture may look like this:
Enterprise IT → Firewall → OT DMZ → Firewall → OT Network
This creates an important architectural principle:
IT systems should not communicate directly with critical industrial assets unless there is a clearly defined operational requirement.
Instead, services that need to exchange information between IT and OT can be positioned or mediated through the DMZ.
The DMZ becomes a controlled exchange point.
Why Direct IT-to-OT Connectivity Is Dangerous
Modern industrial organizations need information from production environments.
ERP platforms may need production data.
Business intelligence systems may require operational metrics.
Security teams may require logs.
Engineers may require remote support.
Vendors may occasionally need maintenance access.
The business requirement is legitimate.
The problem begins when convenience creates direct connectivity.
A workstation inside the corporate network should generally not have unrestricted communication with a PLC controlling a production process.
A vendor laptop should not receive permanent network-level access to an entire control environment simply because occasional maintenance is required.
Connectivity should follow operational necessity.
Not convenience.
The OT DMZ Is a Trust Boundary
One useful way to understand an OT DMZ is to stop thinking about it as a network segment.
Think of it as a trust boundary.
Systems above the boundary belong primarily to the enterprise environment.
Systems below the boundary belong to the operational environment.
The DMZ controls how trust moves between them.
That means every communication path should answer several questions:
- Why does this connection exist?
- Which system initiates it?
- Which destination is required?
- Which protocol is necessary?
- Is the connection permanent?
- Can it be monitored?
- What happens if the source system is compromised?
If these questions cannot be answered, the communication path probably deserves further review.
Why One Firewall Is Often Not Enough
A common industrial architecture places one firewall between enterprise and control networks.
This creates segmentation.
But segmentation alone does not necessarily create strong isolation.
A more mature architecture separates the environments through controlled zones.
Conceptually:
Enterprise Network
↓
Enterprise Firewall
↓
Industrial DMZ
↓
OT Firewall
↓
Industrial Operations
This provides an additional layer where cross-boundary services can be terminated, inspected, authenticated, or proxied before reaching operational systems.
The objective is not adding firewalls for the sake of adding firewalls.
The objective is reducing direct trust.
What Belongs Inside an OT DMZ?
There is no universal list.
Every industrial environment has different operational requirements.
However, several types of services are commonly considered for DMZ placement.
These may include:
- Jump servers
- Remote access gateways
- Patch or update staging services
- Security monitoring infrastructure
- Log collection systems
- Data replication services
- File transfer mechanisms
- Authentication intermediaries
- Application proxies
The critical principle is that the DMZ should contain services that mediate communication rather than simply extending one network into another.
Jump Servers and Controlled Engineering Access
Remote engineering presents a major architectural challenge.
An engineer may need access to systems inside the OT environment.
Giving an engineering laptop direct network access from enterprise IT into the control network creates unnecessary exposure.
A controlled jump architecture provides an intermediate access point.
Instead of:
Engineer Laptop → PLC
the architecture may conceptually become:
Engineer → Controlled Access → Jump Host → Authorized OT Asset
This allows organizations to apply additional controls around privileged engineering access.
Depending on operational requirements, these controls may include:
- Strong authentication
- Role-based access
- Session authorization
- Time-limited access
- Logging
- Session monitoring
The objective is not making engineering difficult.
It is making privileged access deliberate and observable.
Vendor Access Requires Special Attention
Industrial facilities depend heavily on external vendors.
OEMs.
System integrators.
Automation contractors.
Maintenance providers.
Equipment manufacturers.
These organizations may legitimately require remote access.
But vendor access should never automatically mean persistent access.
A mature environment should understand:
- Which vendor has access
- Which assets they can reach
- Why access is required
- When access is permitted
- Who approves the session
- Whether the account is still necessary
One of the most dangerous forms of industrial connectivity is forgotten connectivity.
A temporary remote-access solution created years ago can quietly become permanent infrastructure.
Historian Architecture and Data Flow
Industrial historians illustrate why DMZ architecture matters.
Organizations frequently need production information outside the control environment.
The easy solution is allowing enterprise applications to query an OT historian directly.
The better architectural question is:
Does enterprise IT actually need direct access to the OT historian?
In many architectures, controlled replication or intermediary services can reduce direct cross-boundary communication.
The security objective is straightforward:
Move the required information without unnecessarily extending trust.
This principle applies far beyond historians.
It applies to almost every IT/OT integration.
Data Direction Matters
Not all communication carries the same risk.
A system retrieving production information is different from a system capable of sending commands toward an industrial controller.
Organizations should therefore understand not only which systems communicate, but also in which direction meaningful control can flow.
This distinction becomes particularly important when designing data exchange between operational and enterprise environments.
For some high-consequence environments, organizations may consider architectures designed to enforce highly restricted or one-way data flows where operational requirements justify them.
Architecture should reflect consequence.
The Problem With “Any-to-Any”
One of the clearest warning signs in network security is an overly broad rule.
In OT environments, rules permitting large network ranges to communicate freely can undermine the purpose of segmentation.
Firewall policies should ideally reflect actual operational requirements.
Instead of asking:
“What traffic should we block?”
a stronger design question is:
“What communication does this process actually require?”
This moves the architecture toward explicit communication rather than inherited trust.
Allowlisting Communication
Industrial environments often have an advantage that enterprise environments do not.
Their communication patterns can be relatively predictable.
A PLC may communicate with the same HMI.
A historian may receive information from known sources.
An engineering workstation may interact with specific controllers.
This predictability makes communication allowlisting particularly valuable.
Where operationally feasible, the architecture can permit expected communication while restricting unnecessary paths.
This does not eliminate risk.
But it significantly improves control over the environment.
Monitoring the Boundary
A DMZ should not become a blind zone.
Because it sits between IT and OT, activity within this boundary can provide valuable security context.
Organizations should understand:
- Authentication activity
- Remote sessions
- New communication paths
- Failed connection attempts
- Unexpected services
- Configuration changes
- Privileged activity
The objective is not collecting every possible log.
The objective is obtaining enough visibility to understand meaningful changes at the IT/OT boundary.
Asset Inventory Must Include the DMZ
Asset inventories frequently focus on PLCs, HMIs, switches, servers, and engineering workstations inside the production network.
DMZ infrastructure deserves the same attention.
Organizations should know:
- Which systems exist
- Who owns them
- What function they perform
- Which network zones they connect
- Which software they run
- Who administers them
- Which dependencies they have
An undocumented server inside the OT DMZ can become a serious architectural blind spot.
Identity Becomes Part of Segmentation
Traditional segmentation focuses primarily on IP addresses, ports, and protocols.
Modern industrial environments increasingly require another dimension:
Identity.
Knowing that a connection originates from an approved IP address may not be enough.
Organizations may also need to understand:
- Who initiated the connection
- Which role they have
- Whether the access was approved
- Whether the session occurred during an authorized window
- Whether the account belongs to an employee or vendor
Network segmentation and identity controls increasingly need to work together.
The DMZ Must Not Become a Second IT Network
There is another common mistake.
Organizations create an OT DMZ and gradually fill it with services.
Over time, the DMZ becomes increasingly complex.
More applications.
More accounts.
More integrations.
More remote-access tools.
More exceptions.
Eventually, the security boundary itself becomes difficult to understand.
An OT DMZ should therefore be intentionally minimal.
Every service placed there should have a clear purpose.
Complexity creates operational and security debt.
Architecture Must Follow Operational Consequence
Not every factory requires the same architecture.
Not every PLC carries the same consequence.
Not every industrial process requires identical isolation.
A small manufacturing facility and a national electricity control environment have fundamentally different risk profiles.
Architecture should therefore consider:
- Operational criticality
- Safety consequences
- Production impact
- Recovery capability
- Regulatory requirements
- Remote-access requirements
- Business dependencies
Security architecture should be proportional to operational consequence.
Beyond the Purdue Model
The Purdue Model remains extremely useful for understanding industrial segmentation.
But modern environments increasingly include:
- Cloud services
- Industrial IoT
- Remote operations
- Centralized SOC platforms
- External analytics
- Vendor ecosystems
- Edge computing
These technologies do not always fit neatly into traditional hierarchical diagrams.
That does not make segmentation obsolete.
It makes trust relationships even more important.
Modern OT architecture should understand both:
Where a system is located
and
What that system is trusted to do.
The CROVA Perspective
At CROVA, we view the OT DMZ not simply as a network layer but as an operational security boundary.
Its purpose is not to isolate OT from the modern world.
Industrial environments need data exchange, remote maintenance, analytics, monitoring, and enterprise integration.
The challenge is enabling those capabilities without creating uncontrolled trust relationships.
A strong OT DMZ therefore combines:
- Segmentation
- Controlled access
- Operational visibility
- Identity
- Monitoring
- Explicit communication paths
- Engineering awareness
The objective is not maximum isolation.
The objective is controlled connectivity.
Final Thoughts
An OT DMZ is not created simply by installing another firewall.
It is created by understanding how information, access, and trust move between enterprise and operational environments.
A mature architecture should be able to answer:
Who can cross the boundary?
Which systems can they reach?
Why is the connection necessary?
How long should it exist?
Can the activity be observed?
What happens if one side becomes compromised?
If those questions cannot be answered, the organization may have segmentation—but not necessarily an effective security boundary.
Industrial cybersecurity is not about disconnecting operations from everything.
It is about ensuring that every connection has a reason.
And every reason has a control.
About the Author
Cihangir Dündar
Founder & CEO, CROVA
CROVA Research focuses on Operational Technology (OT), Industrial Control Systems (ICS), industrial cybersecurity, operational resilience, and critical infrastructure security.
Top comments (0)