Beyond the CVE: Rethinking Cybersecurity for the Age of Physical AI

By Yaniv Maimon, VP Cyber Services at Upstream

1. Security teams have traditionally relied on CVEs, patching and vulnerability counts to measure risk. Why does that approach fall short when we’re dealing with connected vehicles, robots and other Physical AI systems?

Patch counts and CVEs made sense under previous threat models, where an attacker exploited a known flaw in known software. But they tell us almost nothing about whether a physical AI system, such as a vehicle or a robot, is actually safe. Behavioral manipulation and sensor spoofing typically need no documented vulnerability at all, since they manipulate real-world inputs or work around detection thresholds directly. Model context poisoning and coordinated fleet exploitation can occur due to an unpatched flaw, but they stay just as dangerous when they do not. What makes them work is a system executing correctly on corrupted input, not the flaw that let the input in. In neither case does patching close the exposure.

CVE counts also create a false sense of precision. Three things undercut them in practice. The volume of new disclosures keeps climbing, and it is climbing faster now that a large share of vulnerability discovery is LLM-driven, so the queue grows faster than any team can work it. Most of what sits in the SBOM arrives from a long and complex supply chain, which means the operator can see what is vulnerable but often cannot decide what gets fixed or when. And a raw count carries no signal about what deserves attention first. The only ordering that holds up is exploitability: what is being exploited in the wild, then what is exploitable in theory. Everything else measures effort rather than risk, and none of it captures the surface an attacker can actually reach on a modern robotics fleet, from the fleet management backend and the inference pipeline through to the OTA update chain and the wider API topology, which is far larger than any database reflects.

2. An attack doesn’t always have to exploit a known vulnerability. How should security teams think about threats like sensor spoofing or behavioral manipulation that may look completely normal to the system?

These attacks don’t always trigger a standard alert because nothing in the system technically breaks. Sensor spoofing feeds manipulated input into a perception model, camera, LiDAR, or radar, so the AI misreads the physical world while every software check still looks normal. The system isn’t malfunctioning, it’s operating correctly on a distorted view of what’s around it.

Behavioral manipulation works the same way from a different angle. An attacker who understands where the detection thresholds sit can shift a system’s behavior gradually, staying just under the line each time, so no single signal looks abnormal even though the cumulative drift is the attack itself. Security teams need to stop asking whether a request was authorized and start asking whether the pattern of behavior over time still matches how that asset, or its peers, normally acts.

Answering that question starts with the physical stack rather than the software one. Teams need a clear picture of the cyber-physical aspects of the device: what it does to the environment around it, and what it could do. The kinetic dimension is the obvious one – mass, speed, force, proximity to people. A vehicle or robot that can be made to sound its horn, a machine that can be made to move at the wrong moment, a system whose reading of its surroundings can be nudged – these all affect the environment without any software behaving incorrectly.

From there it belongs inside the threat and risk modelling, not alongside it. Manipulation and spoofing have to be treated as first-class entries in the assessment, the same way a known exploit path would be – the input channels the system trusts, the thresholds it makes decisions against, the conditions under which normal-looking data produces an abnormal physical outcome. That is what makes these threats tractable. They are invisible if you are looking for a flaw, but entirely visible if you have modelled what the system will do when it is fed something plausible and wrong.

3. You’ve talked about looking at groups or “cohorts” of devices rather than individual alerts. Can you explain why comparing the behavior of similar vehicles or devices can reveal an attack that might otherwise go unnoticed?

A single device rarely tells the whole story. Picture a sophisticated attacker compromising a handful of robots out of a fleet of hundreds, all running the same firmware from the same supplier. No individual device alert triggers, because the deviation is small and confined to that group. When inspected in isolation, each robot appears fine, but as a collective, grouped by configuration, software version, or deployment environment, the pattern becomes far more noticeable. That cross-fleet view is also what catches systemic issues like a compromised software update or a coordinated attack across many assets at once. That’s the kind of signal that would be missed when looking at a single machine’s data, but would be flagged the moment it’s compared against its peers.

The reason this works comes down to what a cohort gives you that a single device cannot. It gives you a real baseline. One machine’s history tells you what that machine has done, which is not the same as knowing what normal looks like, and it leaves you with no way to separate a genuine change in behavior from ordinary variation. Hundreds of peers running the same configuration in the same conditions establish that line properly, so a small deviation stops being noise and becomes something you can measure against. It also surfaces the external influences that only register at scale. The APIs and backend services these fleets depend on touch every device at once, so anything that goes wrong there, whether it is abuse of an interface, a change pushed through a management channel, or an upstream service behaving unexpectedly, shows up as a shift across the population rather than a fault on any one machine. Looked at device by device, that effect is invisible. Looked at across the cohort, it is one of the clearest signals you have.

4. When an autonomous system starts behaving differently, how can security teams tell whether it’s a technical fault, unusual behavior or an actual attack? Where does AI fit into that process?

It starts with the same mechanic in both cases: a deviation from baseline. Something is behaving differently from how that asset, or its cohort, normally behaves. What separates a fault from an attack is not the deviation itself but what follows it. A mechanical problem tends to stay where it started and degrade in ways that make physical sense. An attack tends to move, and the path it takes is the tell – a shift in one place followed by activity somewhere it has no reason to appear, in a sequence that reads as intent rather than wear. So the work is less about spotting the anomaly and more about following what it connects to.

That distinction is exactly why flagging an anomaly isn’t sufficient on its own. A system needs to say not just that something looks wrong, but which asset or cohort is affected, what likely caused it, and what actually changed. Then it must classify whether that deviation looks like an attack, a mechanical fault, or a legitimate edge case such as unusual weather. Doing this manually is very difficult to scale. The volume of behavioral signals a fleet of thousands of robots produces in a single day is more than a human team could work through in a year, so AI has to carry the first pass of pattern recognition and intent classification.

That first pass is where AI earns its place. It can compare an asset against its peers at a speed no analyst can match, test a deviation against what the rest of the cohort was doing at the same moment, and generate hypotheses for what would explain it – this looks like a sensor degrading, this looks like an upstream API change, this looks like something that warrants a closer look. It narrows thousands of signals down to the few worth human attention and arrives with a starting theory rather than a blank alert. The judgment call still belongs to the analyst, particularly where the consequence is physical. What changes is that they are deciding between a small number of framed possibilities instead of trying to find the question in the noise.

5. As vehicles and other connected systems become increasingly dependent on sensors, APIs, cloud platforms and AI, how difficult is it for security teams to get enough context to understand what an anomaly actually means?

This has become one of the more difficult problems in the space because the scope of what needs to be monitored is so much larger than the device itself. A robotics fleet generates traffic across cloud backends, AI inference systems, connected APIs, fleet management platforms, mobile apps and, increasingly, charging and battery infrastructure. Each of those layers has to be monitored on its own terms, not treated as an accessory to the robot. Most teams still assess the asset and stop there, which leaves real exposure within the layers around it. Recognizing an anomaly requires pulling together sensor data, network telemetry, API activity, and software lineage, into one contextual picture, rather than treating each layer as a separate alert stream.

6. If CVE counts and patch numbers aren’t enough, what should CISOs actually be measuring to understand whether their Physical AI systems are secure?

I’d point a CISO toward two timings. The first is how long the system takes to surface a meaningful behavioral deviation, for a single asset and across its cohort. The second is how long it then takes to turn that alert into a real explanation, meaning which cohort is affected, what likely caused it and what changed. Alongside that is how reliably the system separates an attack from a malfunction or a legitimate edge case on its own, rather than handing that judgment to an analyst starting from scratch.

On coverage, leaders should know what share of the fleet’s external API traffic is really being monitored and baselined, and whether detection correlates patterns across multiple assets or only looks at each one in isolation. I’d also track the false positive rate by detection tier, since a high rate usually means the baselines aren’t contextual enough and real signals are being lost in the noise. Those indicators describe security posture, patch compliance does not.

7. AI is also changing the job of the security analyst—from manually investigating alerts to interpreting patterns and intent. What skills will cybersecurity teams need as this shift accelerates?

The first thing is deep domain knowledge, and it becomes more important as AI takes over the mechanical part of the work, not less. If the analyst’s job is shifting from investigating alerts to interpreting patterns and intent, then judging whether a behavioral deviation on a vehicle or a robot is plausible requires understanding how that system actually works – what it is supposed to do physically, what its normal operating envelope looks like, how its sensors and control paths behave under real conditions. Without it, an analyst cannot tell a well-formed AI hypothesis from a confident wrong one. The useful part is that AI can help build this knowledge as well as consume it. It can compress the ramp-up on an unfamiliar platform, surface how a subsystem behaves across a fleet, and answer domain questions on the spot, so acquiring depth is faster than it used to be. But the analyst still has to own it.

The second is knowing how to work with agentic AI directly – understanding where it is genuinely strong and how to deploy it against real security workflows, including the integrations it needs to reach the right data and tooling. Alongside that comes the ability to redesign processes around it. Most security operations processes assume a human reading alerts one at a time, and they do not hold up when an agent handles the first pass at machine speed. Teams have to decide what runs autonomously, what escalates and on what trigger, where the human sits in the loop, and how that handoff actually works. That is closer to operations design than to traditional analysis, and it is becoming part of the analyst’s job rather than something handled elsewhere.

8. Ultimately, a cyberattack on a Physical AI system can have consequences in the real world. What is the biggest security assumption organizations need to rethink before these systems become even more autonomous?

The assumption I’d push back on hardest is that this is still a data security problem. A breach in IT means data loss or downtime, but a compromised physical AI system has real physical consequences for people, supply chains and infrastructure. Organizations that keep framing it as a data protection question will be under-defended in a structural way as these systems become more autonomous.

The second assumption worth rethinking is around liability. When something goes wrong, responsibility is still genuinely unsettled between the fleet operator, the manufacturer, the AI model provider, the software vendor and the security vendor that was meant to detect the anomaly, and most organizations are carrying that exposure today without having quantified it, and that leaves them at risk.

About Yaniv:

Yaniv Maimon is VP Cyber Services at Upstream, with over 20 years of experience in security operations and threat intelligence. He leads the company’s global managed services, including its SOC and AutoThreat®️ Cyber Threat Intelligence.