Ask two OT security teams how they built their asset inventory and you will often get two incompatible answers delivered with equal confidence. One team queries devices directly and gets firmware versions, module slots, and serial numbers. The other listens to a mirror port and gets a live map of who talks to whom, in what protocol, at what cadence, without ever touching a controller.
Both teams are right about what they have. Both are usually wrong about what the other method costs. The argument stays unproductive because it is framed as a choice of tools when it is really a question about what industrial devices are physically able to tolerate, and what evidence you actually need.
What Each Method Is Doing at the Wire Level
Active scanning sends packets to a device and reads the reply. In IT that means TCP SYNs, service banners, and credentialed queries. In OT it usually means something more specific: a Modbus read of holding registers, an EtherNet/IP Identity Object request to CIP object 0x01, an S7comm read of the SZL system status list, a DNP3 outstation poll. Done well, these are legitimate protocol operations that the device was designed to answer.
Passive monitoring reads a copy of traffic that is already flowing. A SPAN or mirror port on the cell switch, or a TAP on an uplink, delivers packets to a sensor that decodes them and sends nothing back. Flow telemetry such as sFlow or NetFlow is a lighter variant: the switch itself exports summaries of conversations rather than full packets, which gives you breadth cheaply and detail not at all.
The distinction that matters is not "one is intrusive and one is not." It is that active scanning produces answers to questions you asked, while passive monitoring produces a record of what the process actually did. Those are different kinds of knowledge and they fail in different ways.
Where Active Scanning Genuinely Wins
Active scanning tells you things that never appear on the wire during normal operation.
Firmware and patch level is the clearest case. A PLC running a vulnerable firmware build does not announce that fact in its cyclic traffic. It runs the same scan cycle it always has. If you want to correlate your fleet against an ICS advisory, someone has to ask each device what it is running, or a human has to walk the plant with a clipboard.
Dormant assets are the second case. A device that is powered but idle, a hot standby, a spare drive on a shelf that is still cabled, an engineering workstation nobody has booted since the last outage: none of these generate traffic, so none appear in a passive view. They still carry risk.
Configuration detail is the third. Module inventory in a rack, I/O card revisions, and controller mode are queryable and largely invisible otherwise.
So the honest summary is that active scanning is very good at depth of attribute per device, and it is the only practical way to answer vulnerability management questions at fleet scale.
Where Active Scanning Costs You
The risk is real and it is not folklore, but it is also frequently overstated in the wrong direction.
Legacy controllers were built for deterministic communication with a known set of peers. Many have a small, fixed number of TCP connection slots, sometimes fewer than ten. A scanner that opens connections in parallel can exhaust them, at which point the HMI cannot poll and an operator sees a comms fault on a screen. That is not a crash, but at three in the morning it becomes an unplanned investigation.
Some devices handle malformed or unexpected input badly. ICS-CERT advisories over the past decade include a long tail of denial of service conditions triggered by crafted or simply unusual protocol traffic on Modbus, EtherNet/IP, and proprietary stacks. A scanner does not have to be malicious to hit one of those paths.
There is also a timing cost that does not show up in a lab. Adding query load to a network engineered for jitter measured in milliseconds can push a control loop outside its expected window. Whether that matters depends entirely on the process.
The most common real world failure is not a bricked PLC. It is a scan that runs during production, degrades an HMI poll, and consumes two days of engineering time proving that the security tool was responsible. That outcome is enough to end an OT security program's credibility with the plant, which is why active scanning almost always ends up gated behind maintenance windows.
Gating behind maintenance windows is the correct engineering response, and it is also what quietly limits the method. A scan you can only run twice a year gives you an inventory that is accurate twice a year.
Where Passive Monitoring Wins
Passive collection has one structural property that active scanning cannot replicate: it is continuous and it carries zero operational risk, because the sensor transmits nothing into the process network.
That continuity is what makes behavioral detection possible. Industrial devices are unusually predictable compared with laptops and servers. A controller talks to a small, stable set of peers. It uses a narrow subset of protocol function codes, often the same three or four for years. It polls on a fixed interval. Its traffic volume per hour barely moves. Over weeks, this produces a baseline with genuinely tight variance, which means a deviation carries information rather than noise.
Concretely, a passive view answers questions active scanning structurally cannot:
- Which hosts have ever communicated with this safety controller, and when did each relationship start?
- Has any device issued a write, a configuration change, or a program download, and what were the values?
- Did traffic cross a zone boundary that your segmentation documentation claims is closed?
- Is a device's polling cadence drifting in a way that suggests it is doing something other than its normal job?
The last two are worth dwelling on. Segmentation drift is one of the most common findings in real assessments, and it is invisible to an inventory-based approach because every device involved is legitimate and correctly configured. Only the conversation between them is wrong.
Passive monitoring is also the only method that produces evidence after the fact. IEC 62443-3-3 requirements around audit and monitoring, and the NIS2 obligation to describe an incident's severity and indicators of compromise within 72 hours, both assume you have a history. You cannot instrument a network retroactively. A scan run after the incident tells you what the network looks like now, which is precisely the state the attacker left it in.
Where Passive Monitoring Falls Short
Two limits, and pretending otherwise is how vendors lose technical buyers.
Passive monitoring cannot see what does not transmit. Idle assets, cold spares, and devices behind a serial link that never crosses a monitored switch are absent from the picture. Worse, they are absent silently. A clean dashboard is indistinguishable from a blind spot unless you have deliberately reconciled coverage against a physical or engineering source of truth.
Passive monitoring also cannot read firmware version from most traffic. Some protocols leak identity information during session setup or in occasional management exchanges, and a full packet DPI sensor will capture that when it happens. But it happens on the device's schedule, not yours, and it does not cover the fleet. For vulnerability correlation, you eventually need either a query or an authoritative source such as the asset owner's own engineering records or an integration with the vendor's management software.
A useful reconciliation test: take the passive inventory, take the engineering asset register, and diff them. Devices in the register but not on the wire are either dead, dormant, or invisible to your collection points, and each of those three answers demands a different action. Teams that skip this step usually discover their blind spots during an incident.
How Mature Programs Actually Combine Them
The productive framing is not "which one" but "which one carries the continuous load."
Passive monitoring is the always on layer. It runs every hour of every day, builds the behavioral baseline, watches zone boundaries, and holds the forensic record. Nothing about it requires a change control conversation, which is why it can be deployed across every cell rather than only the ones important enough to justify risk.
Active queries become a targeted, scheduled supplement. Run them during planned outages, scoped to the devices where you need attribute depth, using protocol-native reads rather than generic IT scanners, and rate limited to one connection at a time per device. Prioritize by what passive already told you: the controllers that sit at zone boundaries, the ones with unexpected peers, the ones in the highest consequence process areas. Passive monitoring makes active scanning cheaper by telling you where to point it.
That sequencing also fixes the maintenance window problem. If your only inventory source is a biannual scan, the gap is a real exposure. If passive monitoring is running continuously and a scan is the periodic enrichment pass, a stale firmware field is an inconvenience rather than a blind spot.
The Question Worth Asking Instead
Most OT security debates about scanning are really debates about risk tolerance in a plant that cannot afford unplanned downtime, conducted between people who own that risk and people who do not.
A better opening question is: what decision are you trying to make? If it is "which of my devices are affected by this advisory," you need attribute depth and you will need to query something. If it is "is something happening on my network right now that should not be," you need continuous behavior, and no inventory refreshed twice a year will get you there.
Industrial devices are the most predictable endpoints in enterprise computing. They do the same thing, to the same peers, at the same interval, for years. That predictability is an asset that only a continuous observer can spend. Starting there, and adding targeted queries where the physics genuinely requires them, is a more defensible position than either method alone.