Walk through any modern warehouse and you will see two very different kinds of computers working side by side: ordinary servers that run the scheduling software, and robots with embedded controllers that you really do not want to crash mid-aisle. Looking for software flaws across both worlds is exactly what VulnerabilityOps is about, and the first practical question is how to look. This post compares three common ways of finding weaknesses on a robot fleet, then compares two ways of deciding what to fix first. Same friendly rules as always: plain words, real trade-offs, and a verdict at the end.
Why robots complicate the picture
On a typical office network a scan is routine. On a fleet of mobile robots, arms and conveyors, it can be risky. The Ops Atlas, the catalogue of operating disciplines, puts the issue in a single line inside its VulnerabilityOps entry: on industrial equipment, an active probe can unsettle a device, so the Atlas recommends listening passively instead. If you have ever seen a controller restart because something probed it too hard, you will understand why that matters.
At the same time, the Atlas is clear that flaws on connected equipment still need tiers, dated owners, proof of closure and a way to count the flow. So the question is not whether to look, but how.
Method A: the unauthenticated active scan
What it does: sends probes to every address from the outside and records what answers.
Good for: the servers, gateways and web dashboards that face the network; spotting forgotten services; quick wins.
Weak at: anything inside the operating system. The Atlas lists “unauthenticated scans miss local flaws” among its myths, so a clean report here says very little about packages and libraries on the machine.
Robot verdict: use it on the fleet-management servers, and avoid it on controllers unless the manufacturer says it is safe. A mistake can stop a line.
Method B: the credentialed scan
What it does: logs into a machine with a service account and inspects installed software and settings.
Good for: accurate findings on the Linux and Windows hosts that run fleet software; verification, because a rescan with credentials is one of the four kinds of closure evidence the Atlas accepts.
Weak at: silent failure. If credentials stop working, findings drop and the dashboard looks greener. In the Atlas worked example, a key rotation cost 80 of 1,900 hosts their scan logins, so coverage fell short of full, and the missing machines produced no complaints at all. There is also a technical wrinkle on Linux: authenticated checks need a package inventory to work, or they report nothing useful.
Robot verdict: great for the servers; for embedded controllers it is often not possible at all, and the scan account itself is a privileged secret that needs protecting like any other.
Method C: passive discovery
What it does: listens to network traffic and builds an inventory of devices and software versions without sending probes.
Good for: fragile equipment, including controllers, drives and sensors; discovering devices nobody listed.
Weak at: depth. It sees what is spoken on the wire and may miss quiet components, so its output is an inventory and a hint, not a full audit.
Robot verdict: the default for anything that moves or controls something physical. Pair it with manufacturer advisories for firmware.
Scorecard
- Safety for fragile devices: passive wins, unauthenticated scan loses.
- Depth of findings: credentialed wins, passive loses.
- Cost of upkeep: unauthenticated is cheapest; credentialed needs credential hygiene and monitoring.
- Value as proof of a fix: credentialed wins.
The sensible answer is a mix. Servers get credentialed scans, perimeter systems also get outside-in scans, and controllers get passive discovery plus advisories. And each method gets its own coverage line in the weekly report, so nobody mistakes “not scanned” for “clean”.
A day in the life: one fleet, three methods
To make this concrete, imagine a small distribution centre with a dozen mobile robots, two robotic arms at a packing station, and four servers behind them. On Monday morning the operator runs an outside-in scan against the four servers during a quiet window and finds one forgotten test dashboard. On Tuesday the credentialed scan reports a library problem on the scheduling host, which goes to the software owner with a due date. On Wednesday the passive sensor notices that one robot is still announcing an old firmware version, so the operator opens a request with the manufacturer rather than touching the robot. By Friday each of the three findings has an owner, a clock and a defined proof of closure, and none of the robots has stopped.
Round two: two ways to decide what to fix first
Finding is only half of it; ranking is the other. Here is how the two most common approaches compare.
Policy 1: severity bands
“Fix everything rated nine or above first.” Simple to explain, easy to automate, and the Atlas lists it among the anti-patterns whenever it stands as the entire policy. A severity score describes how damaging an attack could be, and the score’s own maintainers caution against treating it as a standalone judgement. On a robot fleet this is especially clumsy: a high score on an unreachable controller can outrank a moderate flaw on an exposed dashboard.
Policy 2: clocks from facts
The alternative, which a US federal directive adopted in June 2026 for civilian agencies, derives a deadline from four inputs: whether the asset is public, whether the flaw is a known-exploited one, how automatable an attack would be, and the technical impact. Exposed, listed, automatable, total impact gets three days plus forensic triage. Internal, unlisted and non-automatable gets fixed on the next upgrade. Where automatability is unknown the answer defaults to no, and where impact is unknown it defaults to total. The directive binds only those agencies, but the logic transplants easily.
Verdict: clocks win for robot fleets because exposure is the fact that separates a warehouse controller on an isolated network from a gateway facing the internet. If you manage safety-critical systems, remember that fixes must be coordinated with safety reviews; our overview of how robotics safety standards shape automation explains why a patch window on a robot is never just an IT decision.
Measuring the fleet, not just the findings
Whichever method you choose, track how many items arrive against how many are verifiably closed in every tier, and keep that ratio under one. A tier receiving 180 items and closing 190 sits at 0.95 and is draining; one receiving 600 and closing 520 sits at 1.15 and is growing. Pair it with the seven-day coverage share and the percentage of fixes verified on time. Factory managers already live by operational indicators, and these slot neatly alongside the figures covered in the key performance indicators every factory manager should watch.
One more caution from the Atlas: an old entry on the exploited list does not prove active exploitation today. Use it as a trigger for the short clock, but keep notes on why you chose it.
Final verdict in three lines
- Match the discovery method to the device: probe servers, log in where you can, listen to controllers.
- Rank by facts and clocks, with severity as context only.
- Close with evidence, and report coverage honestly.
Do those three things and your robots keep working while your list of known weaknesses gets shorter, which is the whole point.
