Blind spots in production networks

The network diagram shows a clear separation between corporate IT and production. In day-to-day operations, the reality can be different: A maintenance computer connects the two networks, while a separately purchased LTE router provides an additional access point to the production system. These practical solutions can improve production and maintenance processes, but they can also create security gaps if they are not accounted for in the overall security architecture. The network diagram alone therefore does not show all the ways in which a production system can actually be accessed.

You cannot protect what you do not know about. Securing operational technology (OT) requires an overview of the systems behind the production process: Which systems control production? How are they connected, and who can access them? Combined with an understanding of each system’s technical role in operations, this visibility provides the basis for assessing risks and planning targeted security measures.

Blind spots often affect entire production areas

Even when the technology within an individual production system is well understood, its connections to adjacent networks or external service providers may be inadequately documented. Visibility gaps arise precisely at these boundaries between areas of responsibility. In some cases, entire production areas are neither monitored nor centrally controlled.

An asset inventory often reveals a range of gaps: inadequately protected internet-accessible systems, previously unknown OT devices, or unclear responsibilities. Even well-designed network segmentation can be bypassed. A multihomed system, for example, has network interfaces connected to multiple networks. Depending on its configuration and use, it can enable an unintended communication path between those networks.

An undocumented remote maintenance connection can also fall outside centralized access control. If misused, it may allow unauthorized changes, data exfiltration, or production outages. Depending on the process, equipment damage and hazards to people are also possible. It is therefore important to understand how far a connection extends into production and which functions can be accessed through it.

Network diagrams need to be checked against operational reality

Network diagrams and a configuration management database (CMDB), which documents systems and their relationships, are valuable starting points. Their usefulness, however, depends on whether changes are recorded consistently. An expansion of a production system, an additional firewall rule permitting traffic, or a connection set up by an external service provider can leave the documentation out of date.

Even production environments with long service lives change over time. Without a mandatory process for procurement, connection, and documentation, shadow OT emerges: devices and connections operating outside centralized management. A separately installed cellular router can contribute to this just as much as an unreviewed addition connected to a freely accessible network port.

Gaps in the asset inventory can delay planned network changes and increase costs. If additional devices or previously unknown but necessary communication links are discovered only during a segmentation project, firewall rules must be adjusted and maintenance windows rescheduled. Checking the inventory against the actual environment before implementation helps limit this additional effort.

What a useful OT asset inventory needs to include

A list of IP addresses is not enough to support security decisions. A reliable OT asset inventory combines technical device data with an understanding of the production process:

• Identity and location: Manufacturer, model, device type, and network address, such as the IP address, form the basic technical data. The inventory should also record the physical location and the production system to which the device belongs.
• 
  
• Technical status: What operating system or firmware version is known? Are there any limitations on updates or vendor support?
• 
  
• Connections and access paths: Which systems does the device need to communicate with? What connections exist to IT, other production areas, or external partners?
• 
  
• Operational responsibility and significance: Who maintains the system? Which process does it support? What would be the consequences of a failure or tampering?

IT, production, and maintenance teams need to determine together whether an observed connection is necessary for operations. The fact that two devices exchange data initially establishes only that they communicate. It does not establish whether that communication is operationally necessary or adequately secured.

Building visibility without putting plant operations at risk

Production systems often remain in service for decades. The operating systems and control components in these legacy systems often cannot be freely updated or replaced. NIST’s Guide to Operational Technology (OT) Security takes these specific constraints into account: Security measures must meet operational requirements for performance, reliability, and the safety of people and equipment. Before collecting asset data, it is therefore necessary to establish whether devices can tolerate additional network queries and under what conditions they can be assessed. The methods, scope, and timing of data collection must be coordinated with those responsible for the production systems to avoid disrupting control functions and ongoing processes.

More on NIST's Guide to Operational Technology (OT) Security

Existing documentation, configuration data, network traffic observation, and targeted device queries can be combined to map the OT environment. A scan alone does not guarantee a complete overview. Disconnected production systems, powered-off devices, or separate cellular access paths may fall outside its coverage. Site walkthroughs and discussions with the people who operate and maintain the equipment complement the technical discovery process.

From technical findings to operational priorities

For long-serving production systems with outdated operating systems that often cannot be upgraded to newer versions, age alone does not determine security priorities. Assessing these legacy systems requires an understanding of their vulnerabilities, the paths through which they can be accessed, and the effectiveness of existing safeguards. A tightly restricted network segment can reduce opportunities for attack, but it does not automatically eliminate them.

The consequences of a failure or tampering also matter: Would a single machine stop, or an entire production line? Together with the vulnerabilities, access paths, and existing safeguards, these consequences determine how urgently the system needs additional protection.

A risk assessment helps evaluate this information systematically and prioritize the actions needed. Implementation also requires clear responsibilities and schedules coordinated with production and maintenance teams.

To keep the assessment reliable, the inventory must subsequently reflect operational changes. New production systems, changes to remote access, and network expansions should trigger an update. Recurring technical checks establish whether the documented inventory matches the actual environment.