Active vs. passive vulnerability scanning in OT
(updated )
A ping sweep or port scan aimed at an RTU or a fuel controller can lock the device up. That’s the main reason passive methods are the default for OT assessment work. Tools that query a device in its own industrial protocol, such as a Modbus read, are a different case and carry less risk than a generic scan. Passive monitoring has blind spots of its own, though, and an assessment that treats it as the safe fallback without knowing what it misses ends up overstating its coverage.
The short version
There are three methods worth separating. Generic active scanning sends IT-style probes to a device and reads the response. Protocol-aware querying is also active, but it asks the device questions in the industrial protocol it already speaks. Passive monitoring sends nothing and reads traffic already on the network. NIST SP 800-82r3, the federal guide to OT security, describes all three and recommends none as a blanket rule. Its RA-5 guidance calls for “a risk-based determination” of how to scan, depending on the system being scanned.
| Passive monitoring | Protocol-aware querying | Generic active scanning | |
|---|---|---|---|
| How it works | Reads existing traffic from a SPAN port or network tap | Sends requests in the device’s own protocol, such as Modbus reads and device identification | Probes devices directly: ping sweeps, port scans, banner grabs, credentialed checks |
| Adds traffic to the network | No | Yes | Yes |
| Risk to OT devices | None from the scan itself | Lower, but depends on the device and on which requests the tool sends | Can cause device instability or disturb process state |
| Finds silent devices | No | Yes, if they answer the query | Yes, if they answer probes |
| Version detail | Only what the protocol carries on the wire | Where the protocol defines an identification request | Where a service banner or login exposes it |
| Time to results | Often days, because it waits for traffic | Minutes to hours | Minutes to hours |
| Where it fits | Live control networks | Live networks, after offline testing, with operator approval through change control; test beds; planned outages | IT systems, test beds, planned outages |
| Open-source examples | Wireshark, Zeek | Nmap’s modbus-discover script | Nmap, OpenVAS |
Generic active scanning
Generic active scanning learns about a device by talking to it in IT terms. A port scan, a banner grab, or a credentialed check that logs in and reads installed software versions all work the same way: the scanner sends something, the device answers, and the answer is matched against known vulnerabilities. Nmap is the usual tool for port scans and service detection. OpenVAS runs credentialed checks against vulnerability databases. Some controllers answer an unexpected request by hanging. 800-82r3 (Appendix E.2.3) says active scans “may cause device instability or interfere with the device process state, potentially impacting safety and integrity,” and recommends scheduling them during planned outages whenever possible.
NIST’s examples are old, and both involve the bluntest kind of probe. Appendix C.3.4 records a ping sweep on a live SCADA network that set a robotic arm in motion, swinging it 180 degrees out of standby. In a second case, a ping sweep for inventory hung a system at a chip fabrication plant and destroyed $50,000 worth of wafers. NIST’s footnote for both points to a 2005 Sandia National Laboratories report. They say nothing about how a modern protocol-aware tool behaves. They still show that a ping sweep, about the gentlest probe there is, was enough to hang that equipment.
Passive monitoring
Passive monitoring never sends the device anything. It reads traffic that’s already flowing and fingerprints devices, protocols, and firmware from what passes by. 800-82r3 (Appendix E.2.2) notes it can identify “manufacturers, part numbers, and firmware versions” for every device actively communicating on a monitored segment. Wireshark is the familiar example. Connected to a SPAN port, it decodes industrial protocols like Modbus and DNP3 alongside ordinary IT traffic. Zeek does similar work continuously and logs every connection it sees, which is closer to how a passive inventory gets built over several days. Match those versions against CISA advisories or the NVD and you have a vulnerability list without touching a single controller.
Where passive monitoring falls short
Passive monitoring only knows what it hears. 800-82r3 names the gaps directly:
- Silent devices. A device that doesn’t communicate during the capture window doesn’t get found. Standby units, rarely polled field devices, and spares sitting on the network all fall in this group.
- Encrypted traffic. Without special provisioning, a passive tool can’t read inside encrypted sessions, so the version details it needs may never be visible.
- Time. Results depend on what traffic happens to flow, so a passive scan “will often take days to complete.” A short capture window means a short list.
- Version detail. Some protocols never carry firmware or software versions on the wire. The device shows up in the inventory, but there’s nothing to match against a vulnerability list.
Serial networks are a separate case. 800-82r3 notes that automated network scanning is “not applicable to non-routable communications, such as serial networks.” Those segments need manual inspection and documentation.
Configuration audit closes much of the gap. Pulling device configs, firmware manifests, and the asset register directly gives you the version data a banner grab would have produced, without the device having to transmit anything or answer a probe. 800-82r3’s discussion of vulnerability scanning (control RA-5 in its OT overlay) describes this pairing: passive monitoring plus manual inspection to keep the inventory current, cross-referenced against known vulnerabilities. Traffic analysis still matters, because it shows the connections and data flows a config file won’t. The two together cover more than either alone.
Protocol-aware querying: why it carries less risk
Protocol-aware tools fill the gaps passive monitoring leaves. 800-82r3 (Appendix E.2.3) describes “a safer version of active scanning” built into some OT-specific tools: it first learns about equipment passively, then “uses device-specific communication” to gather the missing details, which NIST says it does “without risk to OT operations.”
The reasoning holds up for read requests. A SCADA control server already polls its field devices at set intervals (NIST’s example in Section 2.3.2 uses 5 and 60 seconds), and Modbus defines read function codes, such as Read Holding Registers, for pulling those values. A protocol-aware tool asking for the same kind of read is sending traffic the device was built to answer. Modbus also defines a Read Device Identification request whose mandatory objects are the vendor name, product code, and revision number (Modbus Application Protocol Specification v1.1b3, Section 6.21). That fills the version gap passive capture often leaves.
Where protocol-aware querying still carries risk
Lower risk still means added traffic on a production network. NIST’s own description of monitoring platforms that use native protocol communications (Section 4.1.4) says they “may improve awareness, but the limitations of these OT systems must be understood.” The sources point to four limits worth checking before a tool runs:
- Not every function code is a read. Modbus diagnostics (function 08, defined for serial-line devices) include a Force Listen Only Mode sub-function. A device that receives it stops responding to Modbus messages until it gets a Restart Communications command, and the specification warns this “can affect the outcome of your application program.” Which codes a tool sends is a configuration choice.
- Connection limits. The Modbus TCP implementation guide leaves the number of connections to each device’s capacity and recommends that a device at its limit close its oldest unused connection to make room for a new one (Section 4.2.1). A scanner is one more client in a small pool.
- Serial gateways. A gateway lets one IP address front many serial devices. On the serial side, the master runs one transaction at a time (Modbus over Serial Line v1.02, Section 2.1), so a tool’s queries share that line with the control system’s own polling.
- Tool defaults. Nmap files its own modbus-discover script under the “intrusive” category, which its documentation reserves for scripts whose risk of crashing a target or consuming significant resources is too high to call safe. The script’s aggressive option walks every unit ID behind an address.
800-82r3 (Section 6.3.2.4) adds the practical step: test how a scanning tool affects OT components and communications in an offline environment before using it in production.
Where active scanning fits
Active scanning is standard practice on IT systems: corporate workstations, business servers, the reporting layer. They were built to absorb the kind of traffic a scanner sends, and most IT security programs scan them on a regular schedule.
Inside OT, both kinds of active method fit under the right conditions: during factory acceptance testing (FAT), before the system is installed and running a live process; on a test bed, which the RA-5 overlay lists as a compensating control (“a replicated or simulated system for conducting scans”); during a planned outage; or against devices the vendor has confirmed can handle it. Protocol-aware querying widens that list. It can reasonably run on a live network once the tool has been tested offline, the requests it sends are defined, and the operator has approved the work through change control.
Segmentation keeps IT scanning out of OT
The risk sits at the boundary between the two. 800-82r3 warns that when scanners run on networks adjacent to OT, “extra care is taken to ensure that they do not mistakenly scan the OT network.” A scan range that’s one subnet too wide, or a route between IT and OT that nobody documented, is how a routine IT scan ends up hitting a controller.
Segmentation handles that risk at the network layer, so OT safety doesn’t depend on every scan job being configured correctly. If the firewall between IT and OT permits only the specific connections the operation needs, a scanner on the corporate side has no path to the control network, and a bad target list gets dropped at the boundary. The IT team keeps its normal scanning schedule, and the OT side isn’t exposed to it.
That protection is worth confirming during an assessment, and it can be confirmed without sending anything across the boundary. A review of the IT/OT firewall rules shows whether the hosts that run IT scans can reach OT address ranges at all.
How this fits IEC 62443
ISA/IEC 62443 doesn’t prescribe active or passive scanning, but its structure gives the choice a natural home. Part 3-2 builds the risk assessment around zones and conduits: groups of assets that share security requirements, and the defined paths between them. Its detailed risk assessment step asks for the known vulnerabilities of the assets in each zone and conduit. That’s where the scanning method gets decided. The assets inside a zone tend to share the same tolerance for interactive traffic, so the zone is a sensible unit for choosing a method: passive capture and configuration audit for a zone of fragile controllers, tested protocol-aware queries where the operator has approved them through change control, generic active scanning for a zone of business servers. Conduits are where the passive taps go, since that’s where the traffic between zones is visible.
Part 3-3 adds a system requirement for a control system component inventory (SR 7.8). Passive discovery plus configuration audit can build and maintain that inventory without probing anything, the pairing the RA-5 overlay in 800-82r3 describes, and the same inventory is what gets cross-referenced against advisories in the vulnerability step.
What each method adds to the asset register
The register is where all three methods meet. 800-82r3 (Section 6.1.3) says an accurate inventory, “including the product vendor, model numbers, firmware, OSs, and software versions,” supports finding and tracking vulnerabilities, and IEC 62443-3-3 asks for a control system component inventory (SR 7.8). Each method fills different fields:
| Register field | Passive monitoring | Configuration audit | Protocol-aware querying |
|---|---|---|---|
| Device present | Yes, if it communicates during the capture | Yes, if it’s on record or found on inspection | Yes, if it answers the query |
| Protocols in use | Yes, from decoded traffic | Where configs record them | Confirms the protocol it queried |
| Vendor and part number or product code | Where the traffic carries them | From configs, manifests and the existing register | Where the device supports an identification request (Modbus: vendor name, product code) |
| Firmware or software version | Only if the protocol carries it on the wire | From configs and firmware manifests | Where the device supports it (Modbus: revision number) |
| Silent or standby devices | Missed | Found if on record or seen on inspection | Found if queried and they answer |
| Connections and data flows | Yes, from observed traffic | Permitted paths, from firewall rules | No, a query only returns the device’s answer |
Generic active scanning adds open ports and service banners to the register. 800-82r3 (Section 6.1.1) also asks organizations to consider whether an inventory tool’s collection method, such as active scanning, “may have a negative impact on their OT systems,” and to test it offline before deployment.
I treat the register as the thread through the passive-first sequence. The passive baseline and configuration audit fill in what they can, and they also show what’s still blank: devices on record that never talked during the capture, and entries with no version. In my view, those blanks are the target list for a native-protocol step. A short list keeps the query narrow.
What this means for scoping an assessment
The useful question for an assessment is which devices on this specific network can take which kind of traffic. Treating every active method as unsafe and passive as safe skips that question. A well-scoped assessment sets methodology zone by zone and device by device, and states plainly what each method covered.
Passive work comes first. Architecture review, configuration audit, and protocol capture give you a baseline with no change window and no added traffic on the process. Native-protocol discovery can come second, aimed at the specific gaps the baseline leaves, like quiet devices and firmware versions that never crossed the wire. That step should go through change control, after offline testing, with the operator involved in planning it and approving it.
I don’t think scale changes that order. Across a large fleet of networks you still need the assessment first, to identify which systems are in scope and which subnets need querying at all. The passive baseline produces that list.
My own work is passive first on live IT and OT networks. Native-protocol discovery is a separate step that can be in the initial scope or added later, and it goes through change control with the operator approving it. The report shows where confidence is high and where it’s limited by what the capture window happened to see, and those limits are the gaps a native-protocol discovery step could target.
For what an assessment built around that boundary looks like end to end, see the ICS and OT security assessment service. If the question is how IT and OT are separated in the first place, see IT/OT segmentation design and review.
Sources: NIST SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023: Sections 2.3.2, 4.1.4, 6.1.1, 6.1.3 and 6.3.2.4, Appendix C.3.4, Appendix E.2.2 and E.2.3, and the RA-5 OT overlay discussion. Modbus Organization, Modbus Application Protocol Specification v1.1b3 (Sections 6.8 and 6.21), Modbus Messaging on TCP/IP Implementation Guide v1.0b (Section 4.2.1), and Modbus over Serial Line v1.02 (Section 2.1). Nmap documentation for modbus-discover and script categories. IEC 62443 references are to Parts 3-2 and 3-3; the standard is available from ISA.