Network Segmentation for OT Without Stopping Production
Almost every OT security assessment ends with the same recommendation, segment the network, and almost every plant manager has the same reaction: not if it means shutting the line down. The good news is that segmentation does not have to be a single, risky cutover. Done in phases, with the right preparation, it can be introduced with little or no disruption to production.
Why segmentation matters
Many industrial networks are still flat, or close to it. Once someone gets onto one part of the network, whether through a phishing email on the corporate side or a compromised vendor laptop, there is little to stop them reaching HMIs, historians and controllers. Segmentation breaks the network into smaller areas with controlled paths between them, so a problem in one place stays there.
The IEC 62443 series describes this as zones (groups of assets with similar security needs) and conduits (the controlled communication paths between them). The Purdue model offers a familiar way to think about levels, from field devices at the bottom to enterprise systems at the top. Either way, the goal is the same: only the traffic that needs to flow should be allowed to flow.
Step 1: Understand the flows before touching anything
The most common cause of segmentation-related outages is blocking traffic nobody knew existed. A historian that pulls data from a controller once a day, a licence server checked at startup, or a time synchronization source can all break quietly when a new rule goes in.
Start with evidence:
Passive traffic capture: use SPAN or mirror ports to record real communication over a period long enough to see normal cycles, including shift changes, batch runs and scheduled reports.
Configuration review: existing firewall and switch configurations show what was intended.
Interviews: operators, controls staff and vendors can explain flows that only happen during startups, shutdowns or maintenance.
The output is a communication map: which systems talk to which, using which protocols and ports, and how often. This becomes the basis for every rule you write.
Step 2: Define zones and conduits
With the map in hand, group assets into zones based on function, criticality and location. A typical starting point might include:
Enterprise IT
An industrial DMZ for shared services such as historians, patch servers and remote access gateways
Site operations, including supervisory HMIs and servers
Individual process areas or units, each with their own controllers
Safety instrumented systems, kept in their own tightly controlled zone
For each conduit between zones, document what traffic is allowed and why. Keep it simple at first. A handful of well-understood zones is far better than an elaborate plan nobody can maintain.
Step 3: Start with the IT/OT boundary and the DMZ
The boundary between corporate IT and OT is usually the best place to begin. It often carries the most risk, and changes there are less likely to affect real-time control.
The aim is that no traffic passes directly between IT and the control network. Instead, it terminates in the DMZ: data is replicated to a DMZ historian, patches are staged on a DMZ server and remote users connect through a gateway there. Once this boundary is solid, you can work inward toward finer segmentation between process areas.
Step 4: Roll out rules carefully
How rules are introduced matters as much as what they say:
Monitor mode first: where your firewall supports it, deploy rules in a logging or alert-only mode, or add an explicit allow-and-log rule ahead of the intended deny. Watch what would have been blocked.
Refine with operations: review the logs with operations and controls staff, and adjust rules for legitimate traffic you missed.
Enforce in a maintenance window: switch to enforcement during a planned window, with the right people on hand.
Have a rollback plan: document exactly how to revert each change, test that you can do it quickly, and agree in advance who decides to roll back.
Test with operations: after enforcement, confirm HMIs update, alarms reach the control room, historians collect data and any remote support paths still work.
Move one zone at a time: do not segment the entire site in one weekend. Each successful phase builds confidence for the next.
Step 5: Close the side doors and keep it clean
Remove bypass paths
A well-ruled firewall does not help if traffic can simply go around it. Common bypasses include:
Dual-homed hosts: a workstation or server with one network card on the corporate network and another on the control network acts as an unmanaged bridge. Remove the second connection or move the host into the DMZ.
Wireless links: Wi-Fi access points or point-to-point radios that connect zones without passing through a firewall.
Cellular modems and routers: often added at remote sites for vendor support, creating a path straight to the internet.
Forgotten cross-connects: a patch cable between two switches added during an outage and never removed.
Walkdowns and passive monitoring are the best ways to find these.
Maintain firewall rule hygiene
Firewall rule sets decay over time. Good hygiene keeps segmentation effective:
Avoid broad "any-any" rules, even temporarily, and give every rule a clear owner and business reason
Record a ticket or change reference in each rule's description
Set expiry dates for temporary rules and actually remove them
Review rule sets at least annually and after major projects
Monitor denied traffic, which often reveals misconfigurations or suspicious activity
How QBits Networks can help
Our network segmentation reviews start with the traffic that is actually on your network, using passive capture, configuration review and conversations with your operations team. We then help you lay out practical zones and conduits and a phased plan your site can carry out without putting production at risk. Tell us what you need through our contact page and we'll scope it with you.