How AI Is Compressing the Time Between Vulnerability and Exploit

Security teams responsible for operational technology (OT), IoT, and Internet of Medical Things (IoMT) devices work on patch timelines they don’t fully control. A fix for an infusion pump or a programmable logic controller (PLC) depends on the manufacturer releasing it, validating it, and scheduling downtime that production lines and clinical units can absorb. Most programs have planned around these constraints on the assumption that attackers also need time to turn a disclosed vulnerability into a working exploit.

That assumption is weakening. The standard measure for this is mean time to exploit (MTTE), the average time between a vulnerability’s disclosure or patch release and its first observed exploitation in the wild. When MTTE was measured in months, a slow patch cycle carried a manageable amount of risk. The world was less networked back then too, reducing attack vectors. As AI lowers the time and cost of developing exploits, MTTE is shrinking further, and connected device teams need containment in place before the patch arrives.

The Exploit Window Was Already Closing

Mandiant has tracked MTTE across the vulnerabilities it monitors for several years, and the trend runs in one direction. Its data shows the average falling from 63 days in 2018 and 2019 to 44 days by early 2021, 32 days in 2022, and 5 days in 2023. The M-Trends 2026 report puts the current figure at an estimated -7 days, which means exploitation now routinely begins before a patch is released.

A negative MTTE changes what a patch cycle can accomplish. When the average exploited vulnerability is in use before a fix exists, even a program that patches immediately starts behind.

This decline began before frontier AI models were widely available. CrowdStrike notes that the pattern predates these models and assesses that their adoption is likely to compress exploitation timelines further by speeding up vulnerability discovery and exploit development. The existing trend is the baseline, and AI adds pressure in the same direction.

What AI Changes About Exploit Development

Building a reliable exploit has historically required specialized skill and time. That effort limited how quickly attackers could act on new disclosures, and AI-assisted tooling is reducing both requirements.

The first confirmed cases are now public. Google Threat Intelligence Group has identified a threat actor using a zero-day exploit that it believes was developed with AI, the first such case it has documented. Recorded Future’s H1 2026 research describes how AI-assisted vulnerability research can shorten the time defenders have to mitigate by accelerating exploit-path analysis and weaponization and by helping skilled operators produce and refine proof-of-concept code more quickly.

The evidence so far points to acceleration of a trend already underway. AI removes friction from steps attackers already take, including analyzing an advisory or patch, identifying an exploitable path, writing proof-of-concept code, and testing it against target configurations. Each reduction in that friction takes time out of the window defenders rely on.

Why OT and IoMT Absorb the Most Exposure

For standard IT systems, a shrinking MTTE puts pressure on a patch process that can at least move quickly when it has to. OT and IoMT environments rarely have that option. Patches for industrial controllers and medical devices come from the manufacturer, require validation to confirm the update doesn’t change device behavior, and need a maintenance window that the operations or clinical team agrees to. Some devices run on software the manufacturer no longer supports, so no patch is coming at all.

[Related: OT Security: The 2026 Guide to Protecting Operations]

SANS notes that OT assets routinely stay in service for 20 years or more, and that OT environments often run with known vulnerabilities for long periods, managed through compensating controls to avoid disrupting a critical process. On the medical device side, research presented at USENIX Security 2025 found that coordinating patches across hospital departments, customers, and software vendors often produces delays. None of the nine health delivery organizations in that study had a process for regularly checking device manufacturers for available security updates, because doing so would require substantial additional resources.

The attacker’s timeline continues to compress while the defender’s timeline for these devices stays roughly where it is. The distance between the two is where connected device exposure accumulates, and that distance grows each time MTTE drops.

Containment That Doesn’t Wait for a Patch

When a patch can’t arrive in time, the practical priority becomes limiting what an exploitable device can reach while it waits.

Least privilege segmentation restricts each device to the connections it needs to function. Consider an infusion pump that communicates only with its management server and the interface engine, or a PLC restricted to its human-machine interface (HMI) and engineering workstation. Either offers an attacker far less to work with, even when the vulnerability on that device hasn’t been disclosed yet. This is the zero trust principle described in NIST SP 800-207, applied at the device level: access is granted per connection, based on need, and network location alone confers no trust.

[Related: How Segmentation Contains a Hospital OT Ransomware Attack]

Because segmentation works independently of disclosure timing, it holds up as MTTE continues to fall. It also gives patching the time it needs. A contained device can wait for its maintenance window while within a much smaller blast radius due to microsegmentation. Patching or targeted mitigations can close the vulnerability when possible.

Moving at the Pace the MTTE Window Requires

Most security leaders already count segmentation among their priorities, and many have a network access control (NAC) platform in place. Far fewer have turned that NAC into operational segmentation. Policies get written but never applied, often because the teams responsible for uptime won’t approve a change that could interrupt a production line or a patient monitor. That caution is reasonable, and a shrinking MTTE makes the delay it causes more costly.

[Related: Why Nearly 80% of Segmentation Projects Fail to Operationalize]

Asimily’s Segmentation Orchestration closes that gap across the connected asset attack surface: Internet of Things (IoT), OT, IoMT, and IT. It sits on top of existing NAC infrastructure, including Cisco ISE, Aruba ClearPass, Extreme, and Arista. The network remains the enforcement point.

• ATT&CK Analysis determines whether a vulnerability is actually exploitable on a specific device in its specific environment. That lets containment efforts prioritize the small share of devices carrying real risk.
• Policy Auto-Recommendation and Policy Creation show teams where to start and generate policy in the correct format for each NAC, with no dependency on engineers trained on one specific platform.
• Policy Simulation lets a policy operate against real, observed network traffic before anything is enforced, revealing any communications that would have tripped the enforcement rules. Operations teams get the evidence they need to approve the demonstrably well-tested and safe change.
• Continuous Segmentation tracks whether policies still match the network as devices are patched, moved, added, and replaced, and adapts so enforcement keeps pace with the environment.

[Related: Reduce Risk Faster with Asimily & Your NAC]

Where to Start

A shrinking MTTE rewards teams that act on their highest-exposure devices first. A practical starting point is the set of devices where exploitability is confirmed, and the patch timeline runs longest, typically legacy OT controllers and medical devices awaiting manufacturer updates. Containing those devices now reduces the exposure that builds in the gap, however quickly AI-assisted exploit development advances from here.

See how Segmentation Orchestration works