Active vs. passive vulnerability assessment in OT

Active scanning against an RTU or a fuel controller can lock the device up. That’s the reason passive methodology is the default for OT assessment work. It isn’t the whole story. Passive assessment isn’t a strictly-worse substitute for active scanning, it’s a different method with its own coverage and its own gaps, and an assessment program that treats it as “the safe fallback” instead of understanding what it actually finds and misses will walk away with a false sense of completeness either way.

What each method actually does

Active vulnerability assessment interacts with the target to learn about it: a port scan, a banner grab, a credentialed check that logs in and reads installed software versions. That interaction is what produces the finding. The scanner sends something, the target responds, and the response gets matched against a CVE database. It’s thorough because it asks the target directly, and it’s risky on OT hardware for the same reason: some of that hardware answers a stray or malformed request by locking up instead of replying.

Passive assessment never sends the target anything. It reads traffic that’s already flowing, typically off a SPAN or mirror port, and fingerprints devices, protocols, and firmware versions from what passes by. Paired with a configuration audit, pulling device configs and an asset inventory directly rather than inferring them from the wire, it can build the same kind of picture: what’s on the network, what it’s running, and where that matches a known vulnerability. Nothing about that process can lock up a PLC, because the PLC never receives anything it didn’t already receive.

Where passive assessment falls short

Passive methodology has a real limitation, and it’s worth stating plainly instead of glossing over it: it can only characterize what it observes. A device that doesn’t transmit during the capture window doesn’t get fingerprinted. A vulnerability in a code path that never executes during that window doesn’t show up in traffic, no matter how long the capture runs. Passive assessment is comprehensive about what’s on the wire and blind to what isn’t, which is a different failure mode than active scanning’s risk of taking something down, but it’s a real one, and a program that treats a passive capture window as equivalent to a full active scan is overstating its own coverage.

Configuration audit closes part of that gap. A device config or firmware manifest pulled directly, rather than inferred from traffic, gives you the same version data an active scan’s banner grab would have produced, without needing that device to ever transmit or answer a probe. It doesn’t replace passive traffic analysis, since traffic analysis is what surfaces interconnections and data flows a static config file won’t show, but the two methods together cover more ground than either alone.

Where active testing still fits

None of this makes active scanning the wrong method everywhere. IT systems sitting outside the OT boundary, corporate workstations, business servers, the reporting layer, were built to absorb exactly the kind of traffic a vulnerability scanner sends, and scanning them actively is standard practice with no meaningful risk. NIST SP 800-82r3 doesn’t argue against active methods in general. It argues against pointing them at devices that were never built to receive that traffic, and the IT side of a segmented environment usually was built for it.

The dividing line an assessment has to draw isn’t “active is unsafe, passive is safe.” It’s which devices on this specific network can absorb interactive testing and which can’t, and building the methodology around that boundary rather than around a blanket rule in either direction.

What this means for scoping an assessment

An assessment that’s honest about this distinction scopes methodology device by device, not network by network: active testing where the target can take it, passive capture and configuration audit where it can’t, and a clear statement of what each method did and didn’t cover. That’s a more useful deliverable than a report that implies uniform coverage across a mixed environment, because it tells the reader exactly where the assessment’s confidence is high and where it’s bounded by what the capture window happened to see.

For what an assessment built around that boundary looks like end to end, see the OT/ICS security assessment page. If the specific question is how IT and OT are separated in the first place, see IT/OT segmentation design and review instead.