Two queries run minutes apart against the same internet-wide dataset return 161,907 and 173. Both describe Siemens S7 exposure. Neither is wrong. Understanding why they differ by three orders of magnitude is the difference between a defensible exposure assessment and a number that collapses under the first question.
On 20 September 2026, the following queries were executed against the ZoomEye AI cyberspace search service with sub_type=all:
| Query | Role | Count |
|---|---|---|
port="102" |
Service port | 161,907 |
device="plc" |
Device class | 95,749 |
app="Siemens S7" |
Product fingerprint | 173 |
All three returned successfully. The counts are exact totals at query time.
Each query answers a different question.
port="102" asks: what answers on TCP 102? Port 102 is the ISO-TSAP transport used by S7comm, but it is not exclusive to it. Other industrial protocols use it, and port-forwarding appliances can make an unrelated service appear on that port. The count is a lower bound on reachability, not a count of PLCs.
device="plc" asks: what does the dataset classify as a programmable logic controller? This is a device-class fingerprint, broader than any single vendor. It includes controllers from multiple manufacturers and excludes devices whose classification is uncertain.
app="Siemens S7" asks: what does the dataset positively identify as a Siemens S7 product? This is the narrowest query and the most conservative. It returns only assets where the fingerprinting evidence supported that specific identification.
The tempting move is to select the largest number and describe it as the count of vulnerable devices. That inference fails on two grounds.
First, port reachability is not product identity. A host answering on port 102 may be a gateway, a different protocol, or a device that has since been reconfigured.
Second, product identity is not vulnerability. An asset matching app="Siemens S7" is a Siemens S7 device. Whether it runs a firmware revision affected by a specific advisory is a separate question that the fingerprint does not answer.
CISA advisory AA26-231A, published 20 August 2026 by CISA with NSA, FBI, DOE and EPA, describes threat actors exploiting internet-reachable Siemens S7 PLCs in water and wastewater environments. The advisory is about a deployment condition. Neither of the counts above measures that condition directly.
The port count is a scoping input. It tells you how much of the internet answers on the transport that this protocol family uses. If you are building an inventory, a port-scoped query against your own address space is the right starting filter because it will not miss a device simply because a fingerprint failed.
The device-class count is a population estimate. It describes how large the observable PLC population is without committing to a vendor. Useful for arguing that this is a systemic class of exposure rather than one vendor's problem.
The product fingerprint is a confirmation tool. When you need to state that a specific asset is a specific product, this is the query whose result supports that statement. Its small size is a feature: it reflects evidence, not inference.
A defensible exposure statement names the query, the scope and the time.
Industrial control exposure assessments have a credibility problem, and it comes from exactly this conflation. A headline that reports port counts as vulnerable-device counts is easy to produce and easy to discredit. The discrediting then extends to the underlying finding, which is real.
The underlying finding is straightforward: a large number of hosts answer on the transport used by an industrial protocol, and a smaller number are positively identified as a specific product line. Both facts are worth acting on. Neither is a vulnerability count.
ZoomEye's value in this workflow is that it separates these questions into distinct queries with distinct, reproducible answers. The product fingerprint is deliberately conservative: it reports what the fingerprinting evidence supports. For an exposure assessment that has to survive review, a conservative confirmation query is more useful than an aggressive one, because it produces a claim you can defend.
The practical pattern is to use the broad query to find candidates in your own space and the narrow query to confirm identity, then to state clearly which one produced the number you are reporting.
sub_type=all: port="102" = 161,907; device="plc" = 95,749; app="Siemens S7" = 173. Counts describe internet-observable matching assets at query time and do not confirm vulnerability or exploitation.