When the Vulnerability Scanner Can't Save You
Industrial control system vulnerabilities have never been more numerous. Forescout’s latest research flags a sharp spike in high-severity OT/ICS flaws, and the attack surface is expanding downward — toward the field-level devices that actually run the physical processes. This isn’t just a bigger number on a dashboard. It’s a structural mismatch between the tools we’ve inherited from IT and the realities of operational technology.
The patching paradox
In IT, the playbook is well-rehearsed: scan, prioritise, patch, verify. It works because IT systems are designed to be patched. They’re redundant, they reboot quickly, and a few minutes of downtime is annoying but not catastrophic.
OT doesn’t work that way.
A PLC running a continuous chemical process can’t be rebooted for a firmware update without a scheduled outage that might be six months away. A safety instrumented system can’t be taken offline without a plant-wide risk assessment. And even when you can patch, the vendor may not have released one — because the controller was designed before anyone imagined it would be connected to a network at all.
This isn’t negligence. It’s physics, chemistry, and engineering economics. The plant comes first.
So when vulnerability counts rise — as they have, sharply, in 2026 — the patching-first approach doesn’t scale. You need detection that works on the live system, without touching it.
The field-level blind spot
Most security tools that do exist for OT sit at Level 2 or above in the Purdue model — above the control layer, watching north-south traffic between the DMZ and the enterprise. That’s useful, but it misses something critical.
Attacks are increasingly targeting field devices directly. A malicious engineering workstation can send a legitimate-looking S7comm STOP command to a Siemens PLC. A compromised HMI can issue Modbus function code 06 writes that change setpoints. An insider with the right software can alter DNP3 outputs to a substation RTU.
These attacks don’t look like exploits. They look like normal operations — the right protocol, the right function code, the right source. A signature-based tool sees nothing. A tool that only watches the DMZ never sees the lateral movement at Level 1.
You need protocol-level visibility at the field bus. You need to know what Modbus function codes are normal for this network, what write operations are expected between these devices, and what S7comm job types have never appeared before in this cell.
Why “learn your normal” isn’t enough
The conventional anomaly detection pitch is: “We learn your baseline, then flag deviations.” That’s half the answer.
A tool that only learns your normal will happily learn a broken normal. If a misconfiguration has existed since commissioning — a Level 2 device talking directly to Level 0 when it should go through Level 1, or a PLC responding to writes from a subnet that should be read-only — the baseline absorbs it. The anomaly goes silent.
What’s needed is a second lens: knowledge of what a healthy OT network ought to look like, grounded in engineering first principles and standards like IEC 62443. Proper Purdue segmentation. Sane polling intervals. Protocol behaviour that respects the intended architecture. This is what lets detection say: not just “this changed,” but “this shouldn’t be happening at all.”
Maigadi Networks pairs both lenses. Unsupervised baselining learns what’s normal for your site. Engineering-first principles flag what violates good — from day one, before a long baseline has even formed. A frozen baseline means an attacker can’t poison the reference either — they’re caught in the act, and the act is explainable.
Explainability isn’t optional
An alert that says “anomaly detected” is a starting point, not an answer. OT engineers and SOC analysts need to know what happened, on which assets, mapped to their Purdue levels, and mapped to MITRE ATT&CK for ICS techniques. They need to see the flows. They need to know whether this is a novel attack, a misconfiguration, or benign drift.
This matters in OT more than IT because the cost of a wrong call is higher. Shutting down a process based on a false positive can cost more than the attack itself. Every alert needs to show its work.
The path forward
The spike in ICS vulnerabilities isn’t going to reverse. The convergence of IT and OT networks, the proliferation of connected field devices, and the growing interest of sophisticated threat actors in industrial targets all point in one direction.
What changes is how we respond. Not with faster patching — OT can’t. Not with more signatures — novel attacks don’t have them. But with passive, protocol-aware detection that watches the field bus, learns what normal looks like, knows what healthy looks like, and explains every alert in terms an engineer can act on.
That’s what we built Maigadi to do.
Maigadi — the watchman for your industrial network.