Industrial environments change continuously. Unless security teams can see how assets and communication paths evolve, segmentation, incident response and compliance remain based partly on assumption.
Learn why OT visibility is the foundation for effective segmentation, incident response, and demonstrable compliance with NIS2, KRITIS, and IEC 62443.
A firewall rule describes what is permitted. Observed network communication shows what is actually happening. OT security depends on understanding the difference.
Walk into an OT security workshop, and the discussion will usually turn to technology within the first few minutes. Network segmentation, industrial firewalls, remote access, asset discovery, and detection platforms are familiar territory. They are also necessary parts of a mature security architecture.
But they often enter the conversation too early.
Before deciding where to introduce another control, an organization needs a reliable understanding of the environment that the control is meant to protect. Most OT leaders would agree with the principle. Fewer can say with confidence that their asset inventories, network diagrams, and communication maps still reflect what is happening across every production site.
The gap rarely results from poor governance. Industrial environments simply change faster than their documentation.
A packaging line is commissioned. An engineering workstation remains connected after the project has finished. An OEM receives remote access during a shutdown window. A legacy Windows system gains a new interface to the manufacturing execution system (MES). Firewall rules are adjusted to resolve an urgent production issue and are never fully reviewed afterward.
Each change may be reasonable. Over time, however, the environment being operated begins to differ from the environment being governed.
Compliance Meets Operational Reality
Many compliance preparations still begin with documentation. Teams update the asset inventory, review network diagrams, revise policies, and check whether incident response procedures are complete.
Those activities matter, but documents can only provide evidence if they remain connected to operational reality.
NIS2 requires affected entities to implement and document appropriate, proportionate and effective cybersecurity risk-management measures. German KRITIS operators must also provide evidence that their required security measures have been implemented. The direction is clear: it is no longer enough to describe the intended security architecture. Organizations increasingly need to demonstrate that controls remain effective in the environment as it actually operates (BSI guidance on NIS2 obligations, BSI guidance on KRITIS evidence).
That changes the questions asked during an assessment:
- Which OT assets are communicating today, including unmanaged and legacy systems?
- Which connections cross production zones?
- Have new communication paths appeared since the last review?
- Does observed traffic still correspond to the approved segmentation model?
- Could the organization reconstruct an incident several months after it occurred?
These may arise in a compliance discussion, but they are fundamentally operational questions. Answering them requires more than a well-maintained spreadsheet.
Documentation describes the intended environment. Compliance evidence must increasingly reflect the environment being operated.
When the Diagram Is No Longer Enough
Consider a manufacturer preparing to strengthen segmentation across several production areas.
The target architecture has already been developed. Zones and conduits are defined, firewall policies are being prepared and the project team has agreed on the systems that should communicate across each boundary. On paper, the design is ready for implementation.
Before changing the firewall rules, the team observes the existing communication patterns.
Several findings alter the project.
An engineering workstation used during an earlier line upgrade is still communicating with controllers in another production zone. A legacy system that appears peripheral in the asset inventory turns out to exchange data with multiple production processes. Connections believed to be obsolete remain active, while several paths required for current operations do not appear in the documentation.
None of this necessarily indicates malicious activity. It reflects the cumulative effect of maintenance, commissioning and production changes.
Implementing the original firewall design without this information could interrupt legitimate processes. The engineers would then have to diagnose the disruption under production pressure, determine which rule caused it and restore connectivity quickly. In that situation, security policy usually loses to availability, often through a broader exception than anyone originally intended.
Observing the network first does not delay segmentation. It reduces the uncertainty surrounding it.
Why Large Programmes Keep Expanding
Many OT security initiatives begin with comprehensive ambitions: new firewalls, wider sensor coverage, stronger remote access, additional monitoring and improved detection across every site.
Each component may be justified. Together, they create a transformation programme involving hardware procurement, network changes, maintenance windows, production planning, supplier coordination and extensive testing.
While this work progresses, the environment continues to move. New equipment is commissioned, suppliers request access and temporary changes become part of normal operations. By the time deployment begins, some assumptions made during planning are already dated.
A more practical sequence is to establish broad, passive visibility early and use what it reveals to guide the heavier investments that follow.
This does not mean abandoning architecture or accepting incomplete security. It means learning where controls will make the greatest difference before committing to changes that are costly or operationally disruptive.
The question shifts from “How do we secure everything?” to “What is happening in the environment today, and where does that create meaningful risk?”
That question tends to produce a more focused programme.
From Assumed Communication to Observed Behavior
Once teams begin working with observed communication patterns, discussions become more specific.
A proposed firewall rule can be compared with traffic that actually crosses the relevant boundary. A remote maintenance connection can be reviewed in the context of when it first appeared, which systems it reaches and whether it is still being used. A legacy device can be assessed according to its role in production rather than its age alone.
This can change investment decisions in several ways:
- Segmentation projects are designed around real dependencies instead of diagrams alone.
- Remote access reviews focus on connections that reach critical processes.
- Maintenance changes can be checked afterwards to confirm that temporary access was removed.
- Protection for legacy systems can be prioritized according to their operational importance and exposure.
- Compliance evidence can be derived from continuously observed conditions rather than assembled shortly before an audit.
Visibility does not decide what an organization should permit. That remains a matter of architecture, operations, risk and governance. It provides the evidence those decisions need.
This distinction is important. A communication path may be technically unexpected but operationally necessary. Another may be permitted by a firewall rule yet no longer have a legitimate purpose. Neither situation can be judged from network data alone, but both are difficult to identify without it.
A firewall rule shows what is permitted. Network behaviour shows what is happening. OT governance needs both.
The Difference during an Investigation
The value of historical context becomes particularly clear when something changes.
Suppose a new connection appears between two production zones during the night shift. The activity may be related to planned engineering work, an incorrectly configured device, an OEM maintenance session or a genuine security event.
Before deciding how to respond, the team needs to understand:
- When did the communication first appear?
- Have these systems communicated before?
- Was maintenance planned for either system?
- Which production process depends on them?
- Who owns the assets and can assess the operational impact?
- What would happen if the connection or one of the systems were isolated?
In many organizations, answering these questions requires several teams and tools. The SOC sees the alert but lacks production context. OT engineers understand the process but may not have access to the historical security data. An external provider may have neither a current asset map nor the necessary local knowledge.
The delay is not necessarily caused by weak detection. It comes from having to reconstruct the environment before the investigation can begin.
Continuous visibility changes the starting point. Teams can determine whether a connection is genuinely new, review the systems involved and place the event within a known communication baseline. OT expertise is still essential, particularly where containment could affect safety or availability, but engineers spend less time establishing basic facts.
During an incident, that difference matters. The objective is not simply to produce an alert faster. It is to reach a sound operational decision with less uncertainty.
A More Useful Starting Point
OT security is sometimes framed as a choice between accepting blind spots and launching a large, intrusive deployment. In practice, the more useful path often lies between these extremes.
Existing firewalls, switches and security infrastructure may already produce network metadata that can support an initial view of assets and communication flows. Specialized OT security tools can add protocol-level and asset context where required. The appropriate combination will differ by environment, but the principle remains consistent: use available evidence early, then expand deliberately.
At Exeon, we see visibility as the starting point for operationalizing OT security, not as a replacement for industrial firewalls, OT security platforms or the expertise of plant engineers. A shared view of network behaviour helps those existing controls and teams work together more effectively.
Industrial environments will continue to evolve. IT and OT integration will deepen, remote maintenance will remain operationally necessary and legacy systems will continue to support critical processes long after their expected replacement dates.
The network diagram will always be useful. It just cannot be the final authority on what is happening.
Organizations that can compare intended architecture with observed behaviour are better placed to segment carefully, investigate efficiently and demonstrate that their controls work beyond the day of an audit. You cannot protect, segment or audit what you cannot see, and regulators increasingly expect organizations to prove that they can.
Key Takeaways
- OT environments gradually diverge from their documentation as equipment, access paths and production dependencies change.
- Observing communication before implementing segmentation reduces the risk of disrupting legitimate production processes.
- Continuous visibility helps teams identify the difference between permitted traffic and operationally justified traffic.
- Historical context allows SOC and OT teams to begin investigations with known facts instead of reconstructing the environment under pressure.
- Compliance evidence becomes more credible when it reflects continuously observed conditions rather than a point-in-time review.
Continue Reading
OT Security Without the Overhead
How can organizations close OT visibility gaps, validate segmentation and improve operational resilience without adding unnecessary complexity?
Download the white paper OT Security Without the Overhead for a practical approach to establishing visibility first and using it to guide the controls, processes and investments that follow.
OT Security Evaluation Guide
If you are assessing your current OT security approach, the OT Security Evaluation Guide provides a structured set of questions for reviewing visibility, segmentation, operational context and incident readiness.
