For years, a lot of security programs have run on a simple rhythm: Microsoft releases patches on the second Tuesday of the month, IT tests them, and they roll out over the following few weeks. It's predictable, it's manageable, and it made sense when attackers needed time to turn a disclosure into a working exploit.
That assumption no longer holds. Here's what the data says, and what it means for how fast your team needs to move.
The numbers
- Attackers are often there first. Google's Mandiant reports in M-Trends 2026 that the mean time to exploit dropped to an estimated -7 days. In plain English, exploitation is routinely happening before a patch is even released.
- Exploitation is now the top way in. Verizon's 2026 Data Breach Investigations Report found that vulnerability exploitation is the most common initial access vector, at 31% of breaches. It's the first time in 19 years it has passed stolen credentials.
- Defenders are moving the other direction. The median time for full remediation rose to 43 days, up from 32 the year before. And only 26% of vulnerabilities on CISA's Known Exploited Vulnerabilities (KEV) list were fully remediated, down from 38%.
- Day-one exploitation is common. VulnCheck found that roughly 29% of the vulnerabilities with exploitation evidence in 2025 were exploited on or before the day the CVE was published, up from about 24% the year before.
Put those side by side: attackers are measuring their timelines in days (or less), while many organizations are still measuring theirs in weeks.
Why can’t a monthly cycle keep up?
Patch Tuesday is not the problem. Predictable, vendor-supplied patches are a good thing. The problem is treating "the next patch cycle" as the plan for every vulnerability. A monthly cadence treats a low-risk bug and an actively exploited one the same way, and it builds a built-in delay of up to a month before a fix even starts to roll out, on top of testing and deployment time.
If exploitation can begin before the patch exists, every day you add to your own timeline is a day your exposure is open.
Speed matters, but only where it counts
The answer isn't to patch everything immediately. No team can, and trying to leads to broken systems and burned-out staff. The answer is to move fast on the right things and keep the routine cycle for everything else. That's where two of the acronyms from our earlier post earn their keep, this time as speed tools:
- KEV is your "drop everything" list. If a vulnerability is on CISA's Known Exploited Vulnerabilities catalog, it's being used against real organizations right now. The right response is days, not the next cycle.
- EPSS tells you what's likely to be next. It estimates the probability a vulnerability will be exploited in the coming 30 days. A high EPSS score on something that isn't on KEV yet is an early warning that it's worth moving up the queue.
A practical way to use them together: KEV items get an emergency timeline, high-EPSS items get an accelerated one, and everything else rides the normal monthly cycle. You still patch it all, just not at the same speed.
So, what about frontier AI?
Back to the question I keep hearing. Frontier AI models are good at reading code, finding flaws, and working out how several smaller weaknesses can be linked into one attack path. That is what "chaining" means. Industry analysts expect this to shrink the time between a flaw being found and being used, and some trackers now put the average for critical vulnerabilities at hours rather than weeks. Those figures are estimates and methods vary, but the direction is consistent.
It's also worth keeping perspective. The Cloud Security Alliance notes that faster exploitation hasn't yet produced a proportional rise in impact, and many serious incidents still start with stolen credentials, social engineering, or a compromised supplier. AI mostly speeds up and scales techniques attackers already use.
That's good news, because it means the defenses are ones we already know. They just have to run faster:
- Shorten the clock on what's actively exploited. This is the KEV tier above. Days, not the next cycle.
- Plan for chains, not single bugs. A vulnerability that scores "medium" on its own can be one link in a serious attack. Prioritize by how exploitable something really is in your environment, not by severity score alone.
- Break the chain. Segmentation, least privilege, outbound traffic filtering, and phishing-resistant MFA on privileged accounts limit how far an attacker gets even when one link works.
- Assume something will get through. Make sure you can detect it, contain it, and keep operating. Pre-approving containment actions save precious time.
- Change who can say "go." If a change freeze can delay a critical fix for 11 days, the freeze is vulnerable. Decide in advance who can override it for a confirmed active threat.
What to ask your team
If you're a business leader or board member, you don't need to know how to patch a server. A few questions will tell you a lot:
- How long does it take us to remediate a vulnerability that's on the KEV list?
- Do we have a separate, faster path for actively exploited vulnerabilities, or do they wait for the monthly cycle?
- Can we show, with records, when each fix was actually deployed?
How Aiden helps
Most teams aren't slow because they don't know what to fix. They're slow because manually testing, scheduling, and deploying patches across every endpoint takes time. The Aiden Platform automates that work. It automatically patches up to 99% of critical vulnerabilities and configuration drift, with risk-prioritized remediation so the vulnerabilities most likely to be exploited go first, and every fix is logged with a time-stamped record you can show an auditor or a board.
That's how you shorten the distance between "it's being exploited" and "it's fixed in our environment."
Want to know how your own patch timeline stacks up? Let's talk.
Sources
