How an OT Assessment Is Conducted: Phases, Methods and What You Really Find

Why an OT assessment is not the same as an IT one

When an IT security manager plans a vulnerability assessment on their infrastructure, they expect a well-established process: a scanner queries the systems, collects the responses, cross-references the data with vulnerability databases, and produces a report. The systems are actively queried, they respond, and the process concludes within a few hours or days.

The same approach in an OT environment can cause incidents. Industrial control devices (PLCs, RTUs, safety controllers, field instruments with network interfaces) were not designed to handle the volume of traffic that a vulnerability scanner generates. Some PLC models respond to anomalous network requests with unpredictable behavior: timeouts, communication resets, or in the worst cases, a crash of the running process.

This is not a rare or theoretical problem. There are documented cases in which vulnerability scans conducted without due caution on OT networks have caused production interruptions. In continuous process environments (chemical, pharmaceutical, food) a sudden interruption can have consequences that go well beyond the production stoppage.

An OT assessment therefore requires a different methodology, centered on the passive collection of information and on prioritizing the non-interruption of operational processes at every phase.

Phase 1: preparation and gathering context

A well-conducted OT assessment begins before any sensor is connected to the network. The preparation phase serves to gather the context needed to correctly interpret the data that will be collected and to plan the engagement in a way that minimizes risks.

The information to gather in this phase:

Documented asset inventory (if one exists): electrical schematics, machine documentation, device lists provided by vendors. Even if incomplete or outdated, this information provides a starting point for verifying what you expect to find.

Network topology: network diagrams, switch configurations, VLAN documentation. Here too, reality often differs from the documentation.

Operational calendar: the periods of normal production, the planned shutdowns, the maintenance shifts. Some phases of the assessment, in particular the installation of the sensors, should be scheduled to coincide with windows where operational impact is minimal.

Key people: who knows the OT network better than anyone else. This contact is indispensable for correctly interpreting the collected data: this is the person who can explain why a certain device communicates unusually, or who can confirm whether a certain behavior is normal or anomalous for that plant.

Assessment scope: which zones, which lines, which systems are included. In large environments, a complete assessment can be split into successive phases by zone.

Phase 2: passive collection and device profiling

The core of an OT assessment is the passive collection of network traffic. The sensors are positioned at the strategic points of the network (boundaries between zones, uplinks of the main switches, connections toward SCADA systems) and begin listening to the traffic without sending anything.

The duration of the collection phase is a critical parameter. OT traffic has specific temporal patterns: there are communications that occur every second, and communications that occur only during certain production cycles or during certain maintenance operations. A collection period that is too short will produce an incomplete inventory: only the devices that communicated during that period will be seen. In typical OT environments, a collection of two or three weeks makes it possible to capture the vast majority of active devices, including those that communicate rarely.

From passive collection, the following are extracted:

Device inventory: every device that emits traffic on the network is identified by its MAC address, classified by type (PLC, HMI, switch, workstation), and where possible identified by manufacturer and model from its traffic signature.

Communication map: which device talks to which, on which protocols, with what frequency. This map is often the first accurate representation of operational dependencies that the organization has ever had.

Firmware and software versions: many OT devices transmit information about their own firmware version during normal communication sessions. This information is extracted passively without querying the devices.

Protocols present: which industrial protocols circulate on the network (Modbus, EtherNet/IP, PROFINET, OPC-UA, DNP3, S7) and which IT protocols coexist with them.

Phase 3: vulnerability analysis and CVE correlation

With the device inventory and firmware versions available, it is possible to proceed to the vulnerability analysis phase. This phase is almost entirely offline: the passively collected information is cross-referenced with vulnerability databases (NVD, ICS-CERT, vendor-specific databases) to identify the known vulnerabilities applicable to the devices present.

The absence of active scanning means this phase is completely free of operational risk. The analysis happens on data already collected, requiring no further interaction with the systems.

The result is a list of vulnerabilities associated with the specific devices present in the environment: not a generic list based on the versions declared in a manual inventory, but a list derived from what the devices have actually communicated on the network. The difference is significant, because manual inventories often contain outdated firmware versions that hide the actual exposure.

For the identified vulnerabilities, the EPSS (Exploit Prediction Scoring System) score, which estimates the probability that a vulnerability will be actively exploited within 30 days, is more useful than CVSS alone for prioritizing actions. A vulnerability with a CVSS of 9.8 but a low EPSS (few exploits available, an unappealing target) has a different priority than a vulnerability with a CVSS of 7.5 but a high EPSS (public exploits, documented active campaigns).

Phase 4: pre-existing anomalous behavior

One of the most frequent discoveries, and the most surprising for the organizations that commission an assessment, is the presence of anomalous behavior in the OT network that pre-dates the assessment itself.

Some of the most common anomalies found during assessments at manufacturing SMEs:

Communications toward undocumented IP addresses: an OT device sending traffic toward an IP address that no one can explain. It may be a legitimate vendor telemetry channel that was never documented, but it needs to be verified.

Devices not present in any inventory: systems communicating on the network that no one remembers installing. They are often forgotten legacy hardware, but they must be investigated.

Traffic on unexpected protocols: IT protocols on segments that should contain only OT traffic. VNC or RDP toward PLCs that should not have remote access. SMB toward field controllers.

Active and unmonitored remote access: VPN sessions or remote support connections active on a persistent basis, often configured years earlier and never removed.

Anomalous communication patterns: an HMI that normally sends read commands to a PLC starting to send write commands, or doing so at unusual hours.

In the vast majority of cases, these anomalies have benign explanations: legacy of past configurations, undocumented vendor behavior, operational processes unknown to the IT team. But every anomaly must be investigated to rule out malicious causes, and this investigation process produces knowledge of the environment that is valuable regardless of the outcome.

Phase 5: reporting and managing results without creating panic

The report from an OT assessment must be calibrated for its audience and its purpose. A document listing hundreds of vulnerabilities without prioritization is often counterproductive: it produces panic without direction, and leads to reactive, ill-considered decisions.

An effective report clearly distinguishes:

Immediate critical risks: highly exploitable vulnerabilities on critical systems, active unauthorized access, behavioral anomalies that require urgent investigation. These require action in the short term.

Significant, plannable risks: vulnerabilities with an available fix that can be remediated within ordinary maintenance cycles, without requiring extraordinary shutdowns.

Risks to accept or mitigate with compensating controls: vulnerabilities for which no patch exists (legacy systems, end-of-life), where the mitigation is network segmentation or other compensating controls.

Areas for architectural improvement: structural gaps such as the lack of segmentation, the absence of an inventory, the lack of logging, which require medium-term projects.

The presentation of results to the organization should always include the operational team, not just the IT team. The people who run the plants have the context to correctly assess the priority of the risks and to plan actions compatibly with production constraints. An OT assessment that ignores the operational context during the presentation of results wastes half its value.

The MON5 angle

The phases described in this article reflect the way MON5 conducts its assessments: passive or hybrid traffic collection, device profiling and network topology, correlation of vulnerabilities with EPSS scores and real exposure, all without stopping production. This is the DISCOVER phase of the methodology: first you observe, then you interpret together with those who know the plant.

The output is not a sales proposal disguised as a report, but a plan of prioritized actions that the organization can execute with whatever resources it prefers. If you want to see how it works on your plant, request an OT assessment.