ICS Vulnerabilities Just Hit a Record. Here's What the Numbers Don't Tell You.
A cluster of reports landed this month that should make every OT security team pause. Forescout flagged a sharp spike in high-severity OT/ICS flaws. Infosecurity Magazine confirmed industrial control system vulnerabilities hit a record high. Industrial Cyber documented increasing attacks on field-level devices — the controllers, sensors, and actuators sitting at Purdue Levels 0 and 1. And perhaps most telling: Sandworm, the APT group behind some of the most consequential ICS attacks in history, is now observed using pre-compromised OT environments instead of zero-days to escalate attacks after detection.
Taken together, these reports paint a picture that is both urgent and deeply uncomfortable. The vulnerability count is climbing. Attackers are getting more sophisticated. But the real story isn’t in the numbers — it’s in what the numbers can’t capture.
The CVE Spiral
Here’s the dynamic: a researcher or vendor discloses a vulnerability. It gets a CVE. A patch is issued. Detection signatures are written. The industry moves on to the next one.
In IT environments, this cycle works reasonably well. Systems are homogeneous. Patching windows are measured in days. Downtime is tolerable. But OT environments break this model at every step.
Patching a PLC or an engineering workstation isn’t like updating a laptop. The device may be running firmware that hasn’t been touched in a decade. The vendor may no longer support it. And even if a patch exists, the operational cost of taking that device offline — even for minutes — can be measured in millions. So the vulnerability sits. The signature gets written. And everyone hopes for the best.
This is the familiar OT patching problem. But the Sandworm observation introduces a more uncomfortable layer.
The Attack That Has No CVE
What Sandworm is reportedly doing — using pre-compromised environments rather than deploying zero-days — is a strategy that bypasses the entire vulnerability management apparatus. There is no CVE for “someone logged in from a workstation that has never talked to this PLC before.” There is no patch for “the credentials were valid, the commands were normal, and nothing triggered an alert.” There is no signature for “the sequence of Modbus function codes was slightly unusual for this time of day on this particular controller pair.”
These aren’t vulnerabilities in the traditional sense. They are anomalies in behaviour. And behavioural anomalies don’t show up in CVE counts, no matter how high those counts climb.
The Field-Level Blind Spot
The industrial cyber reporting this month also emphasised something we have been saying for a while: attacks are moving deeper into the control network. Field-level devices — PLCs, RTUs, IEDs, sensor controllers — are increasingly the target, not the perimeter. But most detection architectures were designed to watch the perimeter. They inspect north-south traffic at the IT/OT boundary. They compare packets against known-bad signatures. They look for malware.
An attacker who has already established a foothold — through a compromised vendor remote-access session, a spear-phished engineer’s laptop, or a pre-positioned implant from a prior intrusion — doesn’t need to cross the perimeter again. They are already inside. And if their subsequent movements use legitimate protocol commands with valid credentials, the signature-based sensor sees nothing anomalous. Because, by signature definition, there is nothing anomalous.
This is the detection gap that the record CVE numbers inadvertently obscure. The industry is getting very good at counting vulnerabilities. It is not getting proportionally better at detecting the attacks that don’t use them.
What Actually Catches This
Catching a Sandworm-style escalation — legitimate access, normal commands, no malware — requires a detection paradigm that doesn’t start with “what does bad look like.” It starts with “what does normal look like.”
When you have a baseline of normal behaviour for every device on the network — which controllers this engineering workstation talks to, which function codes it issues, at what time of day, at what frequency — an anomaly becomes visible not because it matches a known-bad pattern, but because it deviates from the known-good one. A technician logging in from an unexpected workstation. A Modbus write to a register that has only ever been read. A firmware interaction at 3 AM when that device’s maintenance window is Thursday at 10 AM.
None of these trigger a CVE-based alert. None of them match a signature. But all of them are visible to a detection engine that has learned what normal looks like and flags what isn’t.
This is not a theoretical distinction. It’s the difference between catching an attack and reading about it in a post-incident forensics report six months later — which is, statistically, still the norm in OT environments.
The Numbers Will Keep Climbing
The ICS vulnerability count will almost certainly set another record next year. More researchers are looking at OT protocols. More vendors are participating in disclosure programmes. More devices are getting connected. That’s all good — transparency is healthy.
But the conversation we should be having alongside the CVE count is about the attacks those CVEs don’t describe. The insider with legitimate credentials. The pre-compromised environment. The field-level movement that looks, to a signature-based sensor, exactly like normal operations.
Those attacks won’t show up in next year’s vulnerability report either. But a detection architecture built on behavioural baselines — one that learns the normal rhythm of your network and flags deviation — will see them.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.