A controller cannot run a security agent, and no plant manager will let you put a new box in the path of the line. That leaves exactly one safe place to watch from, which is beside the traffic.
In an IT network you can install something. In a plant you usually cannot. The controllers, drives, relays, sensors and human-machine interfaces that matter most were not designed to host software, are often long out of vendor support, and cannot be patched on your schedule because the process cannot stop.
So the question is not which agent to deploy. It is what can be learned from a copy of the traffic, without adding a single device to the control path. The answer turns out to be a great deal, because industrial protocols are far more descriptive than general network traffic.
Industrial protocols carry function codes, register addresses and device identity in the clear. Reading them properly turns a flow record into a description of what was actually asked of a machine.
A list of protocols is not a promise about your plant, so ask us before you assume. Protocol variants differ, newer engineering traffic can be integrity-protected, and serial links, PROFINET and an OEM's proprietary line protocol are each their own question. We will tell you what we parse on your estate and what we do not, in writing, before you buy anything.
Because these protocols answer identity requests honestly, a passive listener can build an inventory without scanning anything: vendor, model, serial number and firmware revision, read from the devices' own replies rather than from a spreadsheet somebody last updated three years ago.
Because it is built only from what the equipment volunteers, coverage is whatever your estate reveals rather than everything you own, and the report names the devices it could not identify instead of quietly leaving them out.
That inventory is then matched against published vulnerability data, prioritised by what is known to be exploited in the wild. We are realistic about this one: you already know your controllers carry unpatched issues you cannot patch on your own schedule. So the useful output is not a list of a thousand findings, it is the short list that changes what you would isolate, monitor or raise with your OEM. A report you cannot act on is worse than no report, because it exists.
Scanning an OT network to build an inventory is exactly the kind of activity that has knocked controllers offline in the past. Nothing described on this page involves sending a single packet to a single device.
The most useful OT signal is often not a known-bad indicator, because there may not be one. It is a change in the character of a relationship. A link between an engineering workstation and a controller that has only ever carried reads for months, and then one day carries a write, is worth a human look regardless of whether any signature matched.
The same applies to remote access reaching into the control network, and to control equipment that turns out to be reachable from the internet. Both are profile problems rather than malware problems, and both are visible from a mirror port.
It cannot be in the path of it. The sensor receives a mirrored copy of traffic and is never inline, so there is no failure mode in which the sensor stops or delays a control message. It also sends nothing to your devices, so it cannot disturb equipment that is sensitive to unexpected requests.
Many managed industrial switches can, and where a switch cannot, a passive network tap achieves the same thing without needing switch configuration at all. Working out which applies to your plant is part of the scoping conversation, and it is a short one.
No, and that is rather the point. The inventory is built from what the devices say about themselves on the wire. In practice the first version of that list is often more accurate than the documented one.
It is a fair objection and it is why the vulnerability output is prioritised rather than exhaustive. We assume you cannot patch on your own schedule, because the OEM has to recertify and the line has to keep running. So the finding is framed around what you can actually do: isolate the segment, restrict who can reach it, watch that link specifically, or take a case to your OEM. If all we could offer was a longer list, we would be making your position worse, not better.
Then the OT analysis stays empty, and it should. A section of a report that invents findings for equipment you do not have is worse than a blank one.
Tell us whether you suspect something is already inside, or whether you want to measure what your current tools would catch. Either way you get a concrete next step.
Contact us