AI is changing the vulnerability problem in operational technology in two ways: more flaws are being found, and the time between a flaw becoming known and being exploited is getting shorter. OT teams cannot patch on an IT clock, because many systems can only be updated in planned outages and some never. The practical answer is not to patch faster everywhere. It is to triage better: know what you have, decide what matters, and put compensating controls around the rest.
What is changing
In a September 2026 post, Dragos (an OT security vendor) described what it sees from the field. Its points, which are the company's own observations rather than independent measurements:
- AI models have found dozens of high-quality zero-day vulnerabilities across major industrial equipment manufacturers, and many more lower-grade flaws, so the volume of advisories is set to grow.
- A tracked threat group that once needed one to two days to turn a fresh vulnerability into a working exploit could, with AI help, get that down towards minutes.
- AI also widens the pool of attackers who can attempt OT targets, because a model can supply industrial knowledge an IT-focused intruder lacks.
- Dragos still describes most OT compromise as relying on known techniques, and says the SANS Five ICS Cybersecurity Critical Controls remain the core playbook.
Separately, security firm Frenos reported on 22 October 2026 that AI makes it easier to plan attacks on industrial infrastructure. The press coverage places the effect at the planning stage, meaning faster preparation, not a new class of attack. Read it as a trend signal, not a measurement.
The recent PHP flaws show the compressed clock in practice. Amazon's threat intelligence team reported the first exploitation attempt against its honeypots four days before the fix was released (see PHP2Shell explained).
Why OT cannot simply patch faster
| Constraint | Why it matters |
|---|---|
| Maintenance windows | Updates often need a planned outage, sometimes once or twice a year. |
| Vendor qualification | Controllers and SCADA software are patched when the vendor certifies the update, not when the flaw is public. |
| Embedded and legacy systems | Some products have no fix or are out of support. |
| Safety and availability | An unplanned restart is itself a risk to the process. |
| Unknown assets | You cannot assess a vulnerability on equipment that is not in the inventory. |
Dragos suggests sorting vulnerabilities into "Now, Next, Never". By its estimate only a small share, in the low single digits of percent, need immediate action, most belong in "Next", and a meaningful share can safely be "Never". The exact split will differ for every site, but the idea is sound.
A triage plan that works in OT
- Know the asset and its exposure. Vendor, model, firmware, zone, and which paths reach it. Without this, nothing below works.
- Ask whether the flaw is reachable. A critical remote-code-execution flaw in a device with no route from the internet or corporate network is a different problem from the same flaw on a boundary firewall.
- Check for exploitation. Prioritise vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog, which UK and EU teams can use as a shared signal, and any your vendor flags.
- Weigh process consequence. What happens if this system is compromised or taken offline? Safety and availability decide the order, not the CVSS score alone.
- Choose a treatment. Patch in the next window, apply a compensating control (segmentation, disabling a service, restricting management access, added monitoring), or formally accept the risk with an owner and a review date.
- Record it. A decision that is written down can be audited, repeated and defended to a regulator.
Where regulation fits
Under NIS2, essential and important entities in the EU must manage vulnerabilities as part of their risk-management measures. In the UK, the NCSC's Cyber Assessment Framework expects operators of essential services to manage vulnerabilities in a structured way. In the US, NERC CIP-007 covers patch management for the bulk electric system, and other sectors rely on the NIST and IEC 62443 approach. None of them demand patching everything at once; they expect a documented, risk-based process.
How OTVista helps
OTVista is built around that process. Asset Visibility holds the inventory and firmware detail, Vulnerability Management links advisories to the assets and zones they affect, Patch Management tracks decisions against maintenance windows, and Risk Management records accepted risk with an owner. Where you need hands-on support, a practitioner can run an OT vulnerability management review or a wider OT cybersecurity assessment. Start with the free Quick Check.
Related: AI-assisted attacks on OT: what actually changed.
Sources: Dragos, "What AI Actually Changes for OT Security: Observations from the Field" (10 September 2026); Frenos research as reported by Let's Data Science (22 October 2026); CISA Known Exploited Vulnerabilities catalog; SANS Five ICS Cybersecurity Critical Controls; Directive (EU) 2022/2555 (NIS2). Vendor statements are the vendors' own. This article is general information, not legal advice.
Topics: AI vulnerability discovery, OT patch management, ICS vulnerability management, AI cyber attacks OT, OT vulnerability triage, time to exploit, SANS five ICS critical controls