Most of the public ICS exposure numbers you see treat every industrial device that answers a probe as roughly the same level of risk. The totals look big, but they're mixing a lot of different things together. Cloud test systems, scanners, honeypots, and devices that only talk back with status information. That mix makes the problem look bigger and less specific than it actually is.
The part that actually matters is smaller: the devices that will accept a write command. Not just respond, but change state when told to. In the common protocols that's visible in specific function codes. Modbus 5, 6, 15, 16. Certain S7 writes. CIP tag writes. And the like. Those are the ones that can move from reconnaissance into real operational impact.
Responding ≠ Writable. A device that answers a probe on port 502 is not the same risk as a device that will execute a Modbus function code 5 (write single coil) or 6 (write single register). The first tells you it exists. The second tells you it can be controlled.
I flagged this distinction earlier when looking at outbound telemetry channels. The higher risk cases aren't just the ones sending data out. They're the ones that can also take commands coming back in. The recent incidents involving cellular telemetry and remote control systems at multiple water utilities showed why that filter is more useful than raw device counts.
Public scans start from the same place: large sweeps of industrial ports. What comes back is anything that replies. But a reply doesn't tell you much about risk. A big chunk of those results never accept a command at all. Treating the whole set as equal dilutes attention and makes prioritization harder than it needs to be.
The practical question is simpler. How many of the devices that answer will actually execute a write? That's the subset worth tracking more carefully.
You can see this if you look for it. In our companion guide on telemetry detection, I walked through the exact Wireshark filters that surface these write operations, including the inbound command path check and an example of a Function Code 5 arriving over what looks like a monitoring connection. The filter is straightforward:
modbus.func_code in {5, 6, 15, 16}Combined with the directionality checks in that guide, it separates one-way telemetry from channels that can also carry commands.
Most exposure reporting still stops at "the device responded." That number is easy to generate and easy to publish. The more useful number is smaller and takes more work: how many of those devices will accept a command that changes state.
That is the surface that actually matters for operational risk. The number worth tracking.