For most of cybersecurity's history, finding a vulnerability was the hard part.
It took rare skill, patience and time. The number of serious flaws surfacing in any given year stayed roughly within the range that vendors, defenders and national databases were built to absorb. Everything downstream, disclosure norms, patch cycles, risk frameworks, quietly assumed the same thing: that discovery was the bottleneck. If it took weeks to find a bug and weeks to fix one, the two halves of the system moved in rough synchronization, and a defender who patched on a reasonable schedule stayed ahead of the people trying to break in.
That contract held for over two decades. It is now gone, and most operating models have not noticed yet.
The Synchronization Is Broken
However, AI did not break this system from a standing start. The infrastructure the industry relies on to make vulnerabilities actionable had been straining for years, and the people running it had been saying so, publicly, well before AI-assisted discovery arrived at scale. What AI did was deliver the final blow.
It collapsed the cost of finding vulnerabilities. What used to take an expert days of analysis now takes an automated pipeline minutes, at manageable costs. The effect on timing is drastic. The mean time to exploit a disclosed vulnerability has gone from roughly a month, just a few years ago, to a matter of days, and in the most recent measurements to less than zero: on average, exploitation now begins before a patch is even public. By the time the disclosure reaches a defender, the attack is already underway.
Let that sink in. When a restricted frontier model was tested against recently disclosed Firefox and Windows vulnerabilities, it produced a working proof-of-concept in as little as 31 minutes, working exploits for 18 of 21 tested Windows kernel vulnerabilities within hours, and delivered all eight privilege-escalation chains it was given, each elevating a low-privileged user to full system control, in under 18 hours. A Windows patch, by contrast, typically takes about 7 days to reach 90% of systems. Line those two timelines up and the exposure window stops being theoretical: the exploit exists on day zero, and most of the fleet is still unpatched a week later.
And the cost was trivial, roughly 2,000 dollars per exploit. The barrier to weaponizing a disclosed vulnerability is no longer skill or time. It is a few thousand dollars and an API key, which widens the pool of capable attackers dramatically. The industry term for this has already settled. N-days, vulnerabilities disclosed N days ago with a patch likely available, have become N-hours.
But here is the part that most discussions miss. Discovery accelerated, but response did not.
Let’s walk the timeline from the defender's seat. A vulnerability surfaces. A vendor acknowledges it, weeks. Engineering triages and assigns priority, more weeks pass by. A patch goes through regression testing, compatibility review, and sometimes regulatory validation, weeks to months. Then you, the customer, test that patch in your own environment before deploying it against a maintenance window scheduled long in advance.
None of these steps are wasteful. Regression testing exists because an untested patch can cause the very outage it was meant to prevent. Maintenance windows are planned events with operational coordination and accepted downtime. In industrial environments, deployment is coupled to safety engineering review and, in some sectors, regulatory approval, timelines measured in months. These constraints do not disappear under pressure. They exist for reasons that survive the pressure.
So, discovery now moves at the speed of software, while response still moves at the speed of organizations. The gap between them is not a backlog that better tooling will clear, it is structural. Closing it is non-negotiable, and that raises the real questions: not just "can we patch faster," but "is our entire operating model built to move at the pace the threat now sets." Speed at one step means nothing if the next step can't keep up.
The Support System Was Already Failing
CVE submissions grew 263% between 2020 and 2025. Most of that climb predates AI-assisted discovery at scale — it came from more software, more numbering authorities, more researchers feeding a maturing system. The pipeline was already under mounting pressure year after year, before AI entered the picture at all.
Then it hit the wall. NIST, long the default source for the severity scores and product mappings that make a raw CVE actionable, enriched nearly 42,000 vulnerabilities in 2025, a record, 45% more than any prior year, and concluded it still could not keep up (NIST, Updates NVD Operations to Address Record CVE Growth, April 2026). As of April 15, 2026, it enriches only three categories: vulnerabilities in CISA's Known Exploited Vulnerabilities catalog, software used by the federal government, and critical software under Executive Order 14028. Everything else is labeled lowest priority, with no analyst-added severity score and no product mapping. Industry estimates suggest the prioritized categories cover only 15 to 20% of expected volume.
This is the moment AI-assisted discovery arrives. FIRST's 2026 forecast, originally a record median near 59,000 CVEs, was revised upward to about 68,000 as actual volume outran the projection. The accelerant landed not on a system with room to absorb it, but on one that was already buckling under pre-AI load.
Speed Is the Only Structural Defense
The right response is speed, and there is no real second option. If a working exploit can exist within an hour of a patch dropping, the only durable defense is to close that gap faster than an adversary can weaponize the disclosure. Continuous, near-real-time patching is already becoming the norm in IT, and it will reach IoT quickly. Aggressive patching, at home and at work, should be the new baseline.
Then it hits OT, where the instinct is to assume none of this applies. Plant managers have spent decades telling IT teams that their patch is disrupting uptime, and they had a point. Unplanned downtime in a refinery or a substation carries a real and immediate cost. But "rarely patch" was a defensible strategy only while those systems were air-gapped and exploit development took weeks. It is not defensible when it takes an hour. Speed is non-negotiable here too. The only real question is what speed looks like in an environment that cannot reboot on demand.
It does not look like rebooting a running plant on a vendor's schedule. It looks like protection that keeps pace with the threat without touching the asset. Virtual patching at the edge, where sensors and firewalls can block exploitation of a vulnerable asset as soon as a detection is available, often well before a maintenance window allows the real fix. Simulation and digital-twin techniques that let teams assess a patch's operational impact before deploying it, shrinking the testing cycle rather than skipping it. Documented compensating controls put in place immediately to hold the line until the asset itself can be patched. None of these replaces patching. They are how protection keeps pace with the threat where the machine cannot stop, and the operators who control them will define the next generation of OT security practice.
The old mindset must flip. For years the message was "your patch is disrupting my uptime." It now must become the opposite: patching, and protecting what cannot yet be patched, is how uptime survives. The greatest threat to availability is no longer the reboot. It is the adversary who reaches the vulnerability first.
Fixing the Pipeline Before Scaling Output
We applied this to ourselves before recommending it to anyone else — across three fronts: our research pipeline, our detection, and our intelligence. At Nozomi Networks, we ran into this exact asymmetry from the Vulnerability Research side. As AI made our own vulnerability discovery faster, the constraint moved downstream to validating findings, documenting them to a standard a vendor can act on, and coordinating responsible disclosure with the affected manufacturer. We could find faster than we could responsibly handle what we found.
So, we made a deliberate choice: fix the pipeline before scaling the output. We built AI-assisted tooling across the whole workflow, triage, technical analysis, advisory preparation, rather than simply pointing faster discovery at an unchanged back end. The result was roughly a 60% reduction in operational hours per vulnerability, measured across those stages, compared with 2025.
The point of that number is not speed for its own sake. It is the capacity to move fast at scale. Reducing the hours each finding consumes is what lets us responsibly handle the volume we ourselves help create, instead of drowning in it. Infrastructure first, scale second. But this is only one part of an end-to-end responsible-disclosure workflow, and improving one part alone does not help the industry move faster. AI has to be built to assist every stage of that process, at every level, before the bottlenecks truly clear — and that will take time. We are building for the volume we expect years from now, not the load on our desks today — but the point is bigger than us. Capacity that compounds as the threat does is what the whole industry will need to keep defending at this pace, and we would rather prove it works than wait for someone else to.
Spotting What Has No Name Yet
Efficiency on the research pipeline was the first front. The second is detection itself, and it changes what we can catch.
A signature-based approach can only recognize what has already been seen, named, and cataloged. That model held while new malware arrived at a pace human analysts could document. It does not hold when novel tooling appears faster than any catalog can absorb it, and when the most dangerous samples are precisely the ones no one has classified yet. So, a growing part of our research focuses on using AI to identify malicious code and behavior that carries no known signature, no known hash, and no entry in any database, by reasoning about what something does rather than matching what it already is. The goal is to recognize a threat the first time it appears, not the hundredth, and to feed that recognition straight back into the intelligence our customers depend on.
Seeing the Present Instead of Reading the Past
Detection was the second front. The third is intelligence — knowing a threat is happening to environments like yours, right now, rather than weeks after the fact in a published report.
Most operational threat intelligence is built on incident response, adversary research, and public advisories. Excellent work, all of it, and all of it backward-looking n. By the time a campaign reaches a report, the decisions that mattered were made by someone else, somewhere else, often weeks earlier. The OT intelligence market speaks in the past tense, and critical infrastructure now must operate in the present.
Closing that gap means being inside the environments where attacks happen, while they happen. That is the structural advantage we have built. Across thousands of active IoT/OT deployments worldwide, anonymized telemetry flows continuously back into our research infrastructure. It is not generic: it covers asset inventory and how it shifts over time, endpoint behavior down to process and command execution, wireless communications across industrial protocols and the live state of vulnerabilities as new CVEs are correlated against the firmware actually running in real plants.
Alongside it, automated systems harvest signals from open and underground sources, our own honeypots capture attacker behavior against industrial-protocol decoys, and partners such as Mandiant add external corroboration and attribution depth.
None of these layers is unique on its own. Honeypots exist, partner feeds exist, vulnerability databases exist. The difference is the foundation: sensors inside real industrial networks, producing ground truth that cannot be bought, scraped or replicated without comparable deployed presence.
Iran-nexus activity against OT has been one of the most consistent geopolitical threats of the past two years. The CyberAv3ngers campaign that compromised dozens of programmable logic controllers across water utilities in the United States, Ireland, and beyond is well documented now, in retrospect. What matters operationally is that this kind of activity does not arrive as one event. It arrives as a measurable shift in attack volume against a specific class of device, in a specific geography, often tracking broader geopolitical tension. Seeing that shift while it builds, rather than reading it in an advisory two weeks later, is the whole difference between informed prioritization and reactive scrambling.
This is where seeing the present pays off. When the AI layer detects a new attack pattern forming across the fleet, the finding does not wait in a queue for the next report cycle. It becomes protection our customers receive immediately: detection content and the context around it, pushed out while the campaign is still unfolding rather than after it has run its course. The customer does not have to discover the threat themselves, interpret it and then react. They are covered as it happens. In a landscape where exploitation outruns disclosure, that immediacy is the whole point. It is where response velocity is won or lost.
You can see how we turn real-world OT and IoT telemetry, proprietary research, and threat intelligence into actionable detection and protection capabilities for industrial environments through the Nozomi Networks platform.
The Question to Bring to Your Next Meeting
Speed is the defense, but speed is not something you buy off a shelf. It is something an organization is either built to deliver or not. The fastest scanner in the world is worthless if a finding then sits in a queue waiting for someone with the authority to act. One question exposes whether you have built the capability to move at the speed the threat now demands.
If a major vendor disclosed 20 to 30 vulnerabilities in their product tomorrow, how many could you realistically mitigate within 90 days, and by what process?
"We're not sure" is not a failing grade. It is a signal that the operating model has not been calibrated to current discovery speed. Calibration rests on a small set of foundations, in order.
- Inventory and environmental context, because you cannot assess impact against assets you do not know you have, which in industrial estates means continuous, largely passive discovery rather than a one-off scan.
- A decision process that scales, with cross-functional coordination across security, operations, and finance, documented compensating controls for what cannot be patched on current timelines, and clear escalation paths.
- The right metric: time from known vulnerability to risk managed, broken down by asset class, where "risk managed" means a patch deployed or a verified compensating control in place, not a vague aspiration.
Only once these exist does further acceleration, on discovery or on investigation, translate into actual security rather than additional, unactionable workload.
Putting these foundations into practice requires more than a list of CVEs. One way to operationalize this approach is through a purpose-built platform such as the Nozomi Networks platform. Nozomi Networks helps asset owners continuously discover OT and IoT assets, correlate vulnerabilities with the software and firmware deployed in their environments and prioritize remediation using a multifactor asset risk score. You can see this approach in action for yourself in a demo of the Nozomi Networks platform
The discovery-response gap is the defining feature of this landscape, not a passing inconvenience. Research will keep getting faster, and adversaries will keep weaponizing disclosure in hours. Engineering rigor and operational constraints are real, but they are obstacles to outpace, not excuses to slow down. The advantage will not show up in tool benchmarks. It will show up in how fast an organization can decide and act under constraint, and how clearly it can defend that reasoning to a board or a regulator.
