OT Network Topology: How to Reconstruct It When No Documentation Exists

The problem of documentation that does not exist

Every OT security project starts with the same question: do you have an up-to-date network topology? The most common answer in Italian manufacturing SMEs is a variation on the theme of "more or less": there is something, but it is not up to date, or there was one but nobody can find it, or it is all in Mario's head and he is on holiday.

This is not a matter of negligence: it is a structural consequence of how OT networks grow over time. Manufacturing plants evolve organically (new lines, new machines, integrations with supervisory systems, connections to the corporate ERP, remote access for vendor maintenance) and each addition brings new devices and new connections with it. Documentation rarely keeps up with this pace. Often the priority is to get back into production as quickly as possible: documentation is postponed to a more convenient moment that never arrives.

The result is that the official network documentation, when it exists, is a snapshot of a past moment. In the meantime, the real network has kept changing. The gap between the diagram on paper and the real network grows with every undocumented intervention.

This creates a concrete problem for any security effort: you cannot segment a network you do not know. You cannot plan a firewall between two zones if you do not know which communications pass between those zones. You cannot manage an incident if you do not know which systems depend on which others. An up-to-date network topology is not a compliance document: it is an operational requirement for security.

What "topology" means in an OT environment

Before talking about how to reconstruct it, it is worth clarifying what we mean by OT network topology, because the term covers several layers of information with different uses.

The physical topology describes how devices are physically connected: which switches exist, which ports are used by which devices, how the switches connect to each other, where the cables run. It is essentially the cabling map.

The logical topology describes how devices reach each other at the network level: IP addresses, subnets, VLANs, routing rules between different segments. It defines the logical perimeters within the network.

The functional dependency map describes which device needs to communicate with which other device to perform its function: which PLCs send data to which SCADA, which HMIs connect to which controllers, which systems historize data from which sources. This map cannot be read from the switches: it emerges from the analysis of real traffic.

For OT security, the most important map is the third: the functional dependencies. Knowing that two switches are physically connected is less useful than knowing that a certain PLC sends critical commands to a certain actuator over a certain network path. Functional dependencies define the critical paths that cannot be interrupted, and therefore the constraints that any security intervention must respect.

Why manual documentation is not enough

The classic approach to documenting an OT network is manual reconnaissance: a technician walks the plant, identifies the devices, traces the cables, records the IP addresses. The approach produces useful results but has structural limits.

The first limit is time: a manual reconnaissance of a medium-sized plant takes days of work, during which production must continue normally. Access to all areas is not always possible: some machines are in hard-to-reach zones, some electrical cabinets are not opened during production. The result is always partial.

The second limit is visibility: a technician who physically inspects the network sees the physical devices but does not see the communications. They can find the PLC, they can find the switch, but they cannot know whether the PLC is communicating with devices other than those documented, whether there are open sessions toward unexpected IP addresses, whether there are devices that communicate on the network but have no obvious physical presence.

The third limit is staticity: manual documentation is accurate at the moment it is produced. The next day, if someone connects a laptop for maintenance, the documentation is already obsolete. Keeping it up to date requires a disciplined process that in practice is rarely sustained over time.

Reconstructing the topology with passive traffic monitoring

Passive network traffic monitoring solves the limits of manual documentation because it observes the network from the inside, seeing what actually happens instead of what is assumed to happen.

The passive topology reconstruction process works like this:

Endpoint identification: from every network frame you can derive the MAC and IP addresses of the source and destination devices. By aggregating this information over time, you obtain the complete list of all devices that emitted or received traffic on the network during the observation period, including those that appear in no documentation.

Reconstruction of the communications graph: every communication session between two IP addresses is an edge in the network graph. By aggregating all observed sessions, you build the map of real communications: who talks to whom, over which protocols, at what frequency. This map is the most accurate representation available of the functional dependencies.

Identification of communication layers: the application protocol of each session reveals the functional layer. Modbus TCP sessions indicate communication between controller and supervisor at the field level. OPC-UA sessions indicate communication with higher-level supervisory systems. SMB or RDP sessions indicate IT-type access. The layering of protocols makes it possible to reconstruct the Purdue levels even without architectural documentation.

Discovery of the physical switch topology: many industrial switches transmit protocol messages (LLDP, CDP) that contain information about their own identity and their network neighbors. By analyzing these messages it is possible to reconstruct the physical topology of the switches, that is, who is connected to whom, without accessing the configuration of the switches themselves.

Identification of critical paths: by cross-referencing the frequency of communications with the protocol type and the devices involved, it is possible to identify the critical paths: the communications whose interruption would have an immediate impact on production processes. These paths are the fundamental constraints for any subsequent network intervention.

The PLC-SCADA-HMI map: the most valuable result

Among all the outputs of passive topology reconstruction, the PLC-SCADA-HMI dependency map is often the one with the greatest immediate value. In a medium-sized plant, this map can be surprisingly complex: dozens of PLCs, each with communications toward one or more SCADA systems, with HMIs connecting to different subsets of controllers, with historians collecting data from multiple sources.

Without this map, any network intervention is a high-risk operation: adding a firewall rule between two segments could break a PLC-SCADA communication that nobody had documented. With the map derived from passive monitoring, every intervention can be verified against the real dependencies before it is applied.

The map often revealed unexpected dependencies: an HMI connecting to a PLC on a line different from its own "area of responsibility", a SCADA collecting data from a controller that nobody had included in its source list, a historian communicating with an undocumented IP address. These unexpected dependencies are not necessarily security problems, many have legitimate operational explanations, but they must be understood before they can be managed.

From topology to security: prerequisites met

An up-to-date and accurate OT network topology enables a series of security interventions that without it would be impossible or too risky:

Informed segmentation: knowing the functional dependencies makes it possible to design segmentation so that it respects the necessary flows and blocks the unnecessary ones, instead of proceeding by trial and error with the risk of blocking production processes.

Contextualized vulnerability management: knowing which segment a vulnerable device is on, and which other systems it communicates with, makes it possible to correctly assess the real risk of the vulnerability and to define the appropriate compensating controls while waiting for the patch.

Effective incident response: in the event of an incident, having an up-to-date topology drastically reduces the time needed to understand which systems are reachable from a compromised device, which production processes are at risk, and which containment actions can be taken without stopping production.

Demonstrable compliance: NIS2 and IEC 62443 both require knowledge and documentation of assets and their interdependencies. A topology derived from passive monitoring is verifiable documentation, not a self-declaration.

Network topology is not a document to be produced once and archived: it must be kept alive. Continuous passive monitoring ensures that the topology updates automatically when new devices appear on the network or when communications change, keeping the documentation aligned with reality without requiring periodic manual reconnaissance.

The MON5 angle

The passive topology reconstruction described in this article is the heart of MON5's DISCOVER phase: the sensor observes real traffic, identifies the endpoints, reconstructs the communications graph and the PLC-SCADA-HMI dependency map, without querying the devices and without stopping production. The platform decodes native OT protocols, from Modbus to Siemens S7, from OPC UA to PROFINET.

With the ANALYZE phase the map then stays continuously updated: every new device or communication automatically enters the inventory. If your plant's documentation is stuck several years in the past, an OT assessment is the fastest way to start again from real data.