OT segmentation is usually designed carefully. The harder task is ensuring that maintenance, commissioning, and operational changes do not gradually undermine it.
OT segmentation changes over time. Learn how firewall exceptions, maintenance access, and undocumented connections create segmentation drift in industrial networks.
A firewall rule tells you what traffic is permitted. It does not tell you whether every permitted connection is still necessary.
Network segmentation projects tend to end on a reassuring note.
The zones have been defined, firewall rules reviewed and communication paths tested. Production is running, the documentation has been updated and the final architecture reflects the organization’s security requirements. For a period, the design and the operational environment are closely aligned.
Then normal work resumes.
A supplier needs access to diagnose intermittent faults on a filling line. A new historian is connected to several production areas. An engineering workstation is moved during an upgrade. A firewall exception is introduced because a maintenance activity is taking longer than expected. Another rule is widened temporarily to get a line running before the morning shift.
Most of these changes have a legitimate operational reason. Some are documented carefully. Others are recorded in a ticket that few people will revisit once the immediate problem has been resolved.
Over time, the architecture on paper and the communication observed on the network begin to diverge.
The segmentation project has not failed. It has encountered the less visible challenge that follows every successful implementation: keeping the control aligned with an environment that continues to change.
How Temporary Access Becomes Part Of The Architecture
Consider a manufacturing site preparing for a planned weekend shutdown.
An OEM needs remote access to update equipment on a packaging line. The existing connection does not reach one of the required engineering systems, so a temporary firewall rule is approved. The scope is broader than the long-term policy would normally allow, but the maintenance window is short and several specialists are waiting to begin their work.
The update takes longer than expected. Production restarts late, and the immediate priority is confirming that the line operates correctly. The temporary rule remains in place in case the vendor needs to reconnect during the following week.
The vendor does reconnect once. After that, the rule is no longer used, but no one removes it.
Months later, the documented segmentation model still shows a controlled maintenance path. The firewall policy now permits considerably more communication. Because no active traffic regularly draws attention to the rule, the difference remains unnoticed.
This is segmentation drift in its most ordinary form. There is no single major error and no deliberate weakening of security. A reasonable exception simply outlives the work that justified it.
Similar changes accumulate through production line upgrades, emergency troubleshooting, MES integrations and the commissioning of new equipment. The intended boundaries remain visible in diagrams and policy documents, while the effective boundaries become more permissive.
Permitted Does Not Mean Required
Firewall reviews are an important part of segmentation governance. They can identify overly broad rules, duplicate entries, unused objects and policies that no longer correspond to the approved architecture.
However, a rule base mainly describes what the firewall will allow. It does not show which permitted connections are actually being used, whether those connections still serve an operational purpose or when their behaviour changed.
Suppose a rule permits communication from an engineering network to a group of controllers. Several questions still remain:
- Are all of the controllers still being reached?
- Is communication limited to expected protocols and maintenance periods?
- Have new systems started using the same rule?
- Does the connection remain active outside approved work?
- Is the rule necessary at all, or has the underlying process changed?
A policy can be technically correct and operationally outdated.
The reverse is also possible. Observed communication may be legitimate even though the documentation has not caught up with a recent production change. In that case, the problem is not necessarily the traffic. The organization needs to decide whether to update the approved design, change the communication path or introduce a more appropriate control.
Continuous validation is therefore not a search for every deviation that should be blocked. It is a way to identify differences that require an informed decision.
The Limits Of The Annual Snapshot
Many organizations review OT segmentation during an audit, a major architecture assessment or the next phase of a security programme. These point-in-time reviews can be thorough. They bring together network diagrams, firewall configurations, asset inventories and local engineering knowledge.
The weakness is not the quality of the review. It is the time between reviews.
A network may be assessed in March and change in April. By the time the next audit begins, the organization has operated for months with communication paths that were never part of the validated snapshot.
This matters because segmentation is not valuable simply because the architecture exists. Its value lies in limiting communication and reducing the paths available for unintended access or lateral movement.
If the environment changes continuously, confidence in the control must come from more than its original design.
Observed network metadata adds another perspective. It can show which systems communicate across boundaries, when a new connection first appeared and whether temporary activity continued after a maintenance window. Compared with intended policy, this provides an ongoing indication of where design and behaviour no longer match.
Not every deviation requires an alert. Some are expected and temporary. The objective is to make meaningful drift visible before it becomes embedded in normal operations.
Validation Without Disrupting Production
OT teams are understandably cautious about testing segmentation.
In an IT environment, a team may be able to block a connection and observe what breaks. On the plant floor, the same experiment could interrupt production, affect product quality or interfere with a safety-relevant process. Even when the expected dependency appears simple, legacy systems and undocumented interfaces can produce surprises.
Passive observation provides a safer way to build confidence before changing policy.
A team planning to restrict communication between two production zones can first examine the traffic crossing the boundary over a representative period. This may include normal production, shift changes, maintenance activity and batch transitions. The objective is not merely to list source and destination addresses, but to understand which flows correspond to operational processes.
The review may reveal:
- Regular communication required by the MES or historian
- Intermittent engineering traffic during planned maintenance
- Legacy dependencies absent from current diagrams
- Vendor connections that remain active beyond approved windows
- Protocols crossing a boundary for which no clear owner can be identified
The resulting firewall change can then be narrower and better informed. After implementation, observed traffic helps confirm that the expected communication continues and that prohibited paths no longer appear.
Validation takes place both before and after the policy change.
A Governance Problem Disguised As A Technical One
Segmentation drift is often discussed as a firewall-management issue. In practice, it is equally a question of ownership.
OT operations, network teams, IT security, equipment vendors and compliance functions may all influence how production networks change. Their responsibilities overlap, but their priorities differ.
A plant engineer authorizing temporary access is focused on restoring or maintaining production. The network team implementing the rule needs a technically precise request. Security wants to understand the exposure created. Compliance may later need evidence that the exception was approved and removed.
Problems emerge when no one owns the full lifecycle of the change.
A practical exception process should establish:
- Why the change is required
- Which systems and communication paths it covers
- Who approved it
- When it should expire or be reviewed
- How the organization will confirm that it was removed
- Who decides whether a temporary change should become permanent
Expiry dates help, but they are not sufficient on their own. A rule may be removed while another path still enables the communication. Conversely, a connection may continue because the production process has genuinely changed and the documentation now needs to be updated.
Validation should connect the change record with what the network shows afterwards.
When No One Recognizes The Connection
One of the more difficult findings in a segmentation review is not necessarily an obviously prohibited connection. It is a connection for which no team can explain the purpose.
The network group confirms that the traffic is permitted. Security finds no corresponding exception or recent change. The local OT team recognizes the devices but not why they need to communicate. The equipment vendor that originally commissioned the system may no longer support it.
Immediately blocking the path could be risky. Ignoring it leaves an unexplained dependency or exposure in place.
Historical context can reduce the uncertainty. When did the connection first appear? Is it continuous or limited to certain production states? Did it begin around a known upgrade or maintenance event? Which system initiates the communication? Does the traffic change when a particular line is running?
The answers may not resolve the issue automatically, but they give engineers a safer basis for testing and remediation. A poorly understood connection becomes a bounded investigation rather than an open-ended debate.
That is an important benefit of continuous segmentation validation. It does not simply identify policy violations. It helps organizations recover operational knowledge that has been lost over time.
Evidence That The Control Still Works
Segmentation is central to many industrial security architectures and relevant to frameworks such as IEC 62443. But evidence of segmentation cannot rest solely on the existence of zones, conduits and firewall policies.
Organizations increasingly need to show that the implemented control corresponds to current operations.
Useful evidence might include:
- Communication observed across defined zone boundaries
- New or changed connections reviewed over time
- Temporary exceptions and their eventual removal
- Deviations from approved policy and the decisions taken
- Historical data demonstrating how segmentation behaved during an incident or audit period
This turns segmentation from a design claim into a control that can be examined and demonstrated.
At Exeon, we see network metadata as a practical source for this type of validation. It can complement firewall policies and existing OT security platforms by showing how assets actually communicate over time. The goal is not to replace the architecture or the tools enforcing it, but to make changes and deviations easier to identify.
A segmentation programme may conclude with a documented target state. Segmentation itself never reaches a permanent final state.
Production environments will continue to change, and sometimes they need to. The purpose of continuous validation is not to prevent that evolution. It is to ensure that every meaningful change becomes visible, understood and either approved or corrected.
Segmentation is not a one-time architecture decision. It is a control whose effectiveness changes with the environment.
Key Takeaways
- OT segmentation gradually changes as maintenance, commissioning and production requirements introduce new connections and exceptions.
- Firewall policies show what is permitted, but not whether every permitted connection remains operationally necessary.
- Point-in-time reviews cannot identify drift that appears and persists between assessments.
- Passive observation helps teams validate dependencies before changing rules and confirm the outcome afterwards.
- Segmentation drift is also a governance issue, requiring clear ownership of exceptions, reviews and permanent policy changes.
Continue Reading
OT Security Without the Overhead
How can organizations continuously validate segmentation without adding disruptive testing or another complex security programme?
Download the white paper OT Security Without the Overhead to explore how passive visibility can support segmentation validation, historical evidence and operational resilience across industrial environments.
OT Security Evaluation Guide
The OT Security Evaluation Guide provides practical criteria for assessing whether your organization can compare intended segmentation with observed communication, manage exceptions and demonstrate that controls remain effective over time.
