The median time to fully remediate a critical vulnerability has risen to 43 days, from 32. Mean time-to-exploit is estimated at seven days. Those two numbers, placed side by side, describe the entire problem.
Most security reporting in mid-market businesses answers the wrong question. It reports how many vulnerabilities exist, how that number has changed, and what proportion are rated critical.
None of those measures tell you whether you would survive. The number that does is how long it takes you to fix something once you know it matters — and almost nobody measures it, because it is uncomfortable and because it belongs to more than one team.
The gap is widening, not closing
The direction of travel across the industry is unambiguous. Median full remediation of a critical vulnerability has moved from 32 days to 43. Only 26 per cent of entries in CISA’s Known Exploited Vulnerabilities catalogue were fully remediated in the most recent measurement period, down from 38 per cent the year before.
Meanwhile, exploitation of vulnerabilities has become the leading initial-access vector, accounting for 31 per cent of breaches, up from 20 per cent a year earlier. Mean time-to-exploit sits at roughly seven days.
A 43-day remediation cycle against a seven-day exploitation window is not a security posture. It is a hope that you are not interesting.
43 days
median time to fully remediate a critical vulnerability — against an estimated seven-day mean time-to-exploit
Regulators have already moved
In June 2026, CISA issued BOD 26-04, replacing the previous flat fourteen-day remediation window with a four-variable risk model: asset exposure, KEV status, exploit automation and technical impact. The resulting windows range from three days at the highest-risk end — with mandatory forensic triage — to deferral until the next scheduled upgrade at the lowest.
This applies to US federal agencies, not UK mid-market businesses. It matters anyway, for two reasons. It signals where sector regulators and enterprise customers are heading, and it embeds a principle worth adopting regardless of obligation: remediation urgency should be driven by exploitability and exposure, not by a CVSS score in isolation.
The KEV catalogue itself now holds 1,665 entries, with 181 added during 2026 — and since March 2026, roughly half of new entries carry the three-day deadline. The volume of genuinely urgent work is rising.
Why mid-market remediation is slow, and it is not laziness
The delay is rarely technical. Patching is usually straightforward. The time goes somewhere else entirely.
Nobody owns the clock. Security identifies. Infrastructure or an outsourced provider applies. A business owner approves the downtime. Each step is reasonable; the queue between them is where the days accumulate, and no single party sees the total.
The change window is monthly. A four-week release cadence sets a floor under remediation time that no amount of urgency penetrates without an exception process — and exception processes that are painful to invoke simply do not get invoked.
Prioritisation is by severity, not exploitability. Teams work down a list ordered by CVSS. A medium-severity vulnerability under active exploitation on an internet-facing asset outranks a critical one on an internal system nobody can reach, and a severity-ordered list will get that backwards every time.
Legacy systems cannot be patched on the same cycle. They need compensating controls instead, and those are usually neither designed nor documented.
The organisations that remediate fastest are not the ones with the best tools. They are the ones where a single named person owns the elapsed time.
What changes the number
In our own delivery work, an 80 per cent reduction in remediation time came from four changes, none of which was a product purchase.
The four changes that move time-to-remediate
- One owner for elapsed time, end to end — not one owner per stage of the queue
- Prioritisation by exploitability and exposure, using KEV status and internet-facing position, rather than severity alone
- A standing emergency change path that is genuinely usable, pre-approved, and used often enough to stay warm
- Compensating controls designed in advance for the systems that cannot be patched quickly, so the answer is not improvised under pressure
Note what is absent from that list. No new scanning platform, no additional headcount, no vendor consolidation. The constraint in most mid-market environments is organisational, which is why buying a better scanner reliably fails to improve the number — it produces a longer list, arriving faster, into the same queue.
The question to ask at the next board meeting
Not how many vulnerabilities do we have. That number is unbounded, always rising, and tells you nothing about resilience.
Ask instead: for the last five vulnerabilities we judged genuinely urgent, how many days elapsed between us knowing and it being fixed — and who owned that clock?
If the answer requires three people to assemble, that is the finding. The metric you cannot produce is the one an attacker is already measuring on your behalf.