Many OT security programmes are designed for comprehensive coverage but spend months navigating procurement, maintenance windows, and production constraints. A more deliberate sequence can produce useful insight earlier without compromising the long-term architecture.
Why do OT security projects stall? Explore how ambitious scope, production constraints, and the pursuit of complete coverage delay meaningful improvements.
The problem is rarely a lack of ambition. It is the assumption that meaningful visibility must wait until the complete architecture is in place.
Few OT security programmes begin modestly.
The initial scope often includes improved asset discovery, network segmentation, stronger remote access, additional firewalls, new monitoring capabilities and integration with the security operations centre. For a multi-site manufacturer or critical infrastructure operator, the ambition may extend across dozens of plants, substations or treatment facilities.
There is nothing unreasonable about that target. Most of the proposed controls are necessary somewhere in the environment.
The difficulty lies in the sequence.
To deliver the complete architecture, teams first need to select technology, identify network locations, procure hardware, agree on data flows, coordinate with equipment vendors and obtain approval for changes. Installation may require physical access to remote sites or maintenance windows that occur only a few times a year. Production teams need assurance that monitoring will not affect availability. Works councils, data protection teams and infrastructure owners may also need to be involved.
By the time the first useful information reaches the security team, the programme may already have spent months in preparation.
The project has not failed. Everyone involved may be doing exactly what the operational environment requires. Yet the blind spots that justified the investment remain in place throughout the planning phase.
A Sensible Plan Meets The Plan Floor
Consider a manufacturer planning to improve OT monitoring across 18 production sites.
The central security team develops a comprehensive architecture. Network sensors will be positioned at relevant boundaries, additional firewalls will strengthen segmentation
and alerts will feed into the existing SOC. The programme aims for consistent coverage and a common operating model across all locations.
Then the site assessments begin. One plant has modern switching infrastructure and a well-documented network. Another runs equipment that has been expanded gradually over two decades.
A third relies on an external integrator for network changes. At one facility, the next suitable shutdown window is four months away. Elsewhere, the local team is preparing to commission a new packaging line and will not accept additional changes until production has stabilized.
The architecture still makes sense, but it cannot be deployed as a single, uniform project.
This is common in OT. Standardization may be a valid destination, while the route towards it differs by site.
Treating every location as if it were technically and operationally equivalent usually creates more planning, more exceptions and more coordination.
Meanwhile, the central team still cannot answer some of its original questions. It does not know which undocumented systems are communicating,
where remote maintenance paths exist or whether the assumed network boundaries reflect current traffic.
The need for visibility has become part of the dependency chain for delivering visibility.
Why “Complete” Is An Expensive Starting Point
In IT environments, adding security telemetry can often be handled through software deployment or configuration changes.
OT introduces a different set of constraints.
An agent may not be supported on an engineering workstation running a vendor-controlled configuration.
Active scanning may be inappropriate for fragile devices. Adding a sensor can require changes to switching infrastructure, physical installation and validation
that network performance remains unaffected. Even a technically straightforward change must compete with production schedules and local engineering priorities.
These are not signs of resistance to security. They are the normal consequences of protecting environments where availability, safety and process integrity come first.
Problems arise when programme success is defined primarily by the completeness of the planned deployment. A team may spend months designing for near-total coverage
before it has enough current information to know where that coverage matters most.
The pursuit of completeness can also hide a more basic question: which parts of the environment are already observable using data that exists today?
Firewalls, switches, routers, remote access systems and existing OT security platforms may already produce useful information about assets and communication flows. It may not provide every protocol detail or cover every isolated segment, but it can establish a starting point without waiting for the final architecture.
Partial visibility is not the same as partial commitment. Used well, it is a way to improve the decisions behind the full programme.
The problem is rarely a lack of ambition. It is the assumption that useful visibility must wait until the complete deployment is ready.
The Cost Is Not Only Delay
The most obvious cost of a long planning phase is time. The less visible cost is that the environment continues to change while the plan is being developed.
A supplier receives temporary access during commissioning. A new MES interface creates communication between production and an application server. A firewall exception is added during maintenance. An engineering laptop is moved between lines. None of these changes waits for the security roadmap.
As the programme progresses, teams risk implementing controls against an increasingly dated picture of the environment.
There is also an investment risk. Without evidence of current communication patterns, it is difficult to determine where additional sensors, segmentation controls or remote access improvements will reduce the most risk. The programme may distribute technology evenly even though the operational exposure is not evenly distributed.
A small wastewater facility with limited local IT support may present a different visibility challenge from a highly automated pharmaceutical plant. A substation with predictable communication patterns requires a different monitoring approach from a manufacturing site where OEMs regularly connect during maintenance windows.
A uniform target architecture can accommodate these differences. A uniform deployment order usually cannot.
Start With The Questions That Change Decisions
A more practical starting point is not “How do we deploy the complete security architecture?” but “What do we need to learn before we finalize it?”
For many programmes, a useful initial baseline should answer questions such as:
- Which assets are currently communicating?
- Which network zones and site boundaries carry the most relevant traffic?
- Where do connections exist that are not reflected in the documentation?
- Which remote access paths reach critical production systems?
- Where can existing infrastructure provide sufficient telemetry?
- Which blind spots genuinely require additional sensors or other controls?
These questions narrow the space in which heavier investments need to be made.
If existing network metadata already provides a useful picture across much of a site, specialized sensors can be reserved for areas where protocol-level context or additional asset detail is necessary. If observed communication reveals that a supposed boundary carries little traffic, segmentation may be simpler than expected. If an undocumented OEM path reaches several critical systems, remote access may become a higher priority than originally planned.
The resulting programme is still comprehensive. It is simply informed by the environment before the most disruptive and expensive decisions are made.
Progress Without Creating Production Risk
Starting earlier does not mean moving recklessly.
OT teams are right to be cautious about anything that could affect production. A visibility-first phase therefore needs to respect the same operational principles as the broader programme: avoid introducing unnecessary traffic, use passive data sources where possible and agree clearly on how information will be collected, retained and accessed.
The objective is not to bypass local engineering teams or accelerate deployment at their expense. In fact, early visibility often improves collaboration with them.
A central security team may see an unexpected communication path as a potential policy violation. A plant engineer may recognize it as the connection used by an OEM during quarterly maintenance. Neither perspective is sufficient on its own. Reviewing observed behaviour together allows the team to distinguish an undocumented but legitimate dependency from access that has simply remained open longer than intended.
That conversation is more productive than presenting the plant with a completed architecture based largely on central assumptions.
It also builds trust. Local teams can see that the purpose of monitoring is not to impose controls without understanding production, but to reduce uncertainty before changes are made.
Architecture As A Direction, Not A Prerequisite
None of this argues against long-term architecture.
Industrial organizations still need consistent approaches to segmentation, remote access, monitoring, incident response and security operations. Multi-site environments cannot be governed indefinitely through isolated local solutions. Standards matter, particularly when organizations need to demonstrate a coherent control framework across many facilities.
The distinction is between architecture as a direction and architecture as a prerequisite for learning.
When every design decision, procurement step and site dependency must be resolved before useful visibility is available, the programme postpones the evidence it needs most. When visibility is established early, the architecture can be tested against real conditions and adapted before implementation becomes expensive.
This changes how progress is measured.
Instead of reporting only the number of sites deployed or sensors installed, the programme can track practical improvements:
- Previously unknown assets and communication paths identified
- Critical production dependencies validated
- Remote access connections reviewed
- Segmentation assumptions confirmed or corrected
- Priority locations selected for additional controls
- OT and SOC teams working from a shared operational view
These outcomes do not replace coverage metrics, but they show whether the programme is reducing uncertainty as it expands.
Investing In The Right Order
The central lesson is not that large OT security programmes should become smaller. It is that they should reveal value earlier.
A programme may still require additional firewalls, specialized OT monitoring, stronger access controls and deeper integration with security operations. Some sites will need new infrastructure. Others will require careful deployment during planned shutdowns.
Those investments become easier to justify when the organization can show where the current risks and dependencies lie.
At Exeon, we approach passive visibility as a way to support that first phase and connect the information already available across network and security infrastructure. It is not a substitute for specialized OT tools or long-term architecture. Its role is to help organizations begin learning before every element of the final design has been deployed.
OT security will always involve operational constraints. Maintenance windows will remain limited, legacy systems will remain difficult to change and local conditions will continue to differ. The answer is not to ignore those realities, but to structure programmes around them.
The strongest architecture is not necessarily the one designed with the most complete initial scope. It is the one that can absorb what the organization learns once the real environment becomes visible.
Key Takeaways
- OT security projects often stall because comprehensive coverage depends on procurement, network changes, maintenance windows and site-specific coordination.
- Operational caution is justified, but useful visibility does not always need to wait for the final architecture.
- Existing infrastructure can often provide an initial view that helps identify where additional controls and specialized sensors are most valuable.
- A visibility-first phase reduces investment risk by grounding programme priorities in observed communication and production dependencies.
- Long-term architecture remains essential, but it works better as a direction for the programme than as a prerequisite for learning.
Continue Reading
OT Security Without the Overhead
How can organizations establish useful OT visibility without waiting for a multi-year transformation programme?
Download the white paper OT Security Without the Overhead to explore a practical sequence for building visibility, validating segmentation and improving incident readiness while respecting the operational constraints of industrial environments.
OT Security Evaluation Guide
Planning an OT security investment or reviewing an existing programme? The OT Security Evaluation Guide provides a structured framework for assessing coverage, deployment requirements, operational context and the ability to build on existing infrastructure.
