Inside your company, two clocks are running at the same time, and only one is visible. The first starts when a vendor publishes a flaw and someone on your team opens the ticket. The second starts when another person, anywhere in the world, finishes writing the code that exploits that same flaw. For years, the two clocks ran more or less in step. This year, they stopped doing so.
The breach report from Verizon for 2026 left a figure worth reading slowly: vulnerability exploitation is now the number one entry vector, with 31% of breaches. It is the first time in nineteen editions of the report that stolen credentials lose that top spot. In the same period, the median time to apply a patch rose from 32 to 43 days.
What do those 43 days really mean?
A median is not an average. A median of 43 days means that half of organizations take even longer, and that half includes companies with teams, budget, and tools. It is not a problem of negligence. It is a problem of operational physics: the number of flaws published each month grows, the inventory of what needs patching grows, and maintenance windows are still the same two early mornings a month as always. Anyone who wants the complete framework of the process can first read about vulnerability management; here I go straight to why it gets stuck.
There is a second figure from the same report that, in my opinion, is more uncomfortable than the first. Of the vulnerabilities in the actively exploited flaws catalog from CISA, that is, those known with certainty to be in use right now by someone against someone, the proportion that organizations fully remediate fell from 38% to 26%. That catalog is the short list. If the short list is being met at a quarter, the problem is not fine-grained prioritization; it is capacity.
The exposure window is not a single number
When a committee talks about “days to patch,” it is almost always measuring one stage of the journey and not the full journey. In practice, the clock is split into four stages, and each one is lost for different reasons.
1. From the advisory to finding out. The vendor publishes. Your team finds out through a bulletin, through the provider, or through the scanner on its next run. Entire days are lost here, depending on how often the scan runs and who reads the advisories.
2. From learning about it to knowing whether it applies to you. Do you have that product? In what version? Exposed to the internet or internal? This stage drags on when the inventory is not reliable, which is almost always.
3. From knowing to being able to act. The system owner shows up, the change shows up, the window shows up. If the asset is critical and does not have high availability, the patch waits for the weekend. Sometimes for the end of the month.
4. From applying to verifying. The most forgotten stage. A patch that is applied but not verified, or applied on 80 out of 100 machines, leaves the hole open just the same and also reassures the committee, which is worse.
Why does it take longer now if there are more tools than ever?
Because almost everything added in recent years helps with stage 1 and stage 2, which are the cheap ones, and does not touch stages 3 and 4, which are the expensive ones. A new scanner will give you more findings, not more maintenance windows.
Add to that where the attacker is hitting. Edge devices, VPN concentrators, perimeter firewalls, and remote access portals are precisely the ones that do not support an agent, that cannot be restarted during business hours, and that are sometimes managed by a third party. It is the worst possible combination: what is most exposed is also the slowest to touch. If your company relies on providers to manage part of that infrastructure, that agreement should have a written response time, because today it probably does not.
How do you shorten the window without breaking production?
I do not know of any company that has reduced its patching time by buying something. The ones that reduced it changed operating rules. These are the ones I have seen work most often.
Six decisions that do move the needle
- Separate the CISA catalog from the rest. Everything on that list that exists on your network is treated as an incident, not as a maintenance ticket. With its own deadline and its own escalation.
- Set deadlines by exposure, not by severity. A medium-severity flaw in an internet-facing service is more urgent than a critical one in an internal system with no outbound path. CVSS alone does not order the queue.
- Stop negotiating the window case by case. Fixed windows, scheduled and approved once a year. Each individual negotiation costs days.
- Name an owner per asset, not per team. If the owner is “infrastructure,” the patch has no owner. If it is a named person, it does.
- Measure stage 4 and publish it. Percentage of verified patch coverage, not the number of patches applied. They are two very different numbers, and the second looks better than it is.
- Review the edge separately. VPN concentrators, firewalls, and remote portals with their own inventory, their own owner, and their own deadline, shorter than for everything else.
None of the six costs money. All of them cost arguments, which in practice is what is truly scarce.
And when the patch simply cannot go out in time?
It will happen. There are systems that cannot be touched, vendors that take time to release the fix, and applications that break with the update. When that happens, the nature of the work changes: it is no longer about closing the hole, it is about making sure that using it does not come free.
That is where containment measures that can be applied within hours come in: blocking rules at the perimeter, segmentation of the asset, restricting who can reach it, and reinforced control on the endpoint. A well-tuned EDR platform does not close the vulnerability, but it turns silent exploitation into noisy exploitation. It is exactly the same reasoning we apply with the ransomware: if you cannot prevent entry, make sure the entry makes noise.
And someone has to be listening to that noise at three in the morning on a Saturday, which is when it usually happens. A SOC operating 24/7 does not replace patching, nor does it claim to. What it does is buy your company the margin that today is taking 43 days to achieve through the formal route.
If you want to know in which stage the days are slipping away, start by measuring all four separately for a month. The answer is almost never where you think.
The patch waits for the maintenance window. The exploit waits for nothing.
