Summary

In April I posted a five-year retrospective covering the institutional changes around vulnerability disclosure since the 2020 Quest Policy Authority advisory. That post covered the structural side: NVD enrichment, the CVE program funding scare, the EU Cyber Resilience Act, the rise of the KEV catalog. It did not look closely at the question that operators ask first: when a researcher discloses something, how long does it actually take for a patch to appear?

This post tackles that narrower question: has vendor patching cadence changed between 2020 and 2026?

The short answer is yes for some vendors, no for most, and the gap between the two has widened. There is no single industry cadence to quote. There are at least three, and they have diverged.

I draw on three sources below. None of them is a complete dataset.

  1. What vendors publish about their own process. SLA pages, security blog posts, advisory cadence.
  2. What the KEV catalog records about real exploitation timelines.
  3. What I have observed in my own follow-up disclosures since the 2020 Quest writeup. Sample size is small. I am not Project Zero.

What “cadence” actually means

Before any numbers, a definition. The full disclosure pipeline has at least four measurable intervals.

Interval What it measures
Time-to-acknowledge Researcher first contact, vendor confirms receipt and triage
Time-to-fix Acknowledge, code change merged, internal build available
Time-to-ship Internal build, GA release reaching customers
Time-to-disclose Researcher coordination window, public advisory

Public conversations about cadence usually conflate these. A vendor who acknowledges within a day but ships a year later is not the same as a vendor who responds in two weeks and patches in three. Both are common. Both look like “the vendor responded” in casual reporting.

In the rest of this post I will be specific about which interval I am citing. The KEV catalog effectively measures something else again: time from public CVE to documented exploitation, and then a separate federal-agency remediation deadline. I will treat that as its own thing.

What vendors publish

The biggest change since 2020 is that more vendors now publish a security policy page at all. In 2020, finding a vendor’s coordinated disclosure SLA usually meant emailing security@ and waiting to see what came back. In 2026 the larger vendors have committed something to writing. Whether the document is honored is a separate question.

A short, non-exhaustive comparison of what large vendors say about their own cadence:

Vendor / project Public cadence commitment Where to verify
Microsoft Monthly Patch Tuesday for non-emergency fixes; 90 days as the default coordinated disclosure window before independent publication; out-of-band releases for actively exploited issues Microsoft Security Update Guide and the MSRC blog
Apple Fixed-version-only model: security fixes ship in the next supported OS update, not as targeted backports; security content documented per release Apple security releases
Linux kernel No formal SLA; most fixes land within days of report when the report is well-formed; coordinated embargo via linux-distros for issues with cross-distro impact Kernel maintainer correspondence is largely public on lkml
Major cloud / hyperscale Internal first, customer-facing CVEs after mitigation; a meaningful share never receive a public CVE because the customer has no remediation action  
Google Project Zero (researcher side, for context) 90-day disclosure window plus optional 30-day grace if a fix is in flight; immediate disclosure for actively exploited issues Project Zero policy
Bug-bounty platforms No platform-wide SLA; per-program. Most published programs commit to triage within 72 hours and a fix-or-update target somewhere between 30 and 180 days HackerOne directory, Bugcrowd directory

Pre-2020, almost none of this was written down in a way a researcher could cite. The improvement is real, even if the actual time-to-fix has not always followed.

The gap to keep in mind is between what a vendor publishes and what a researcher experiences. Microsoft’s published target is 90 days. The actual time from acknowledgment to a Patch Tuesday release for routine findings often runs longer, because routine findings get queued behind whatever is currently being exploited. Apple’s fixed-version-only model is honest but it means a fix landing in iOS 19.x reaches no users still on iOS 18, by design.

What the KEV catalog measures

CISA’s Known Exploited Vulnerabilities catalog is the closest thing the industry has to a public, structured cadence dataset. It is also commonly misread, so a quick note on what it does and does not measure.

KEV records do not directly track vendor patching cadence. They track exploitation. A KEV entry includes a CVE ID, the date CISA added it to the catalog, and the federal-agency remediation deadline (dueDate). The implicit assumption is that any KEV-listed CVE has a vendor patch available, since federal agencies are required to remediate by the due date. That is mostly true.

What you can derive from KEV records is two narrower numbers.

  1. Time from CVE publication to KEV addition. This is roughly the gap between a vulnerability being disclosed and CISA confirming it is being exploited. It varies from days (recently weaponized 0-days) to years (older vulnerabilities reaching exploitation through commodity tooling).
  2. Federal-agency remediation deadline. CISA typically sets the dueDate 14 to 21 days after the KEV addition, with rare extensions for harder cases. This is a hard deadline for FCEB agencies and a strong signal for everyone else.

KEV has grown from roughly 300 entries at launch in late 2021 to around 1,500 entries by mid-2025. That growth is partially a backlog catch-up, not a real-time exploitation count. CISA’s Binding Operational Directive 22-01 pulled in pre-existing exploited issues during the catalog’s first 18 months.

For our cadence question, the useful KEV signal is this. Once a CVE is on KEV, defenders behave as if a patch is available within two weeks. That is the pressure-cooked, accelerated branch of the cadence story. It applies to about one percent of all CVEs.

What I see in my own follow-up disclosures

The 2020 Quest UC report was not a one-off. I have continued to file disclosures since then. The cadence I see is heavily shaped by which class of vendor the issue lands with, and to a lesser extent by whether the vendor runs a structured bug-bounty program.

A representative sample of patterns I have observed across follow-ups since the Quest writeup, lightly anonymized where the disclosures are not yet public:

Vendor class Acknowledgment Fix shipped Coordination
Fortune-500 software vendor with formal PSIRT Within 48 hours, every time 30 to 90 days for non-critical findings; faster for critical Professional, predictable
Mid-market enterprise vendor running HackerOne or Bugcrowd Within 72 hours, usually 60 to 180 days, depending on roadmap pressure Triage is sharp; fix scheduling is opaque
Mid-market enterprise vendor without a bug-bounty program 1 to 4 weeks, often after a follow-up email Variable. Some patch in weeks. Some go silent and ship a fix without notifying me. Frustrating, similar to 2020
Small or end-of-life product “We will look into it” or no response “End of life, no patch” or no response Identical to 2020
OSS project with active maintainers Within hours when the report is well-formed Days to a few weeks Faster than commercial vendors

The absolute numbers are not the interesting story. The shape is. The Fortune-500 PSIRT process and the OSS-with-active-maintainers process are noticeably faster and more predictable than they were in 2020. The middle band is the same. The long tail is the same or worse.

The single most consistent accelerator I have seen is presence on KEV. On the rare occasion a finding I disclosed went on to be confirmed as exploited and added to KEV, the vendor went from “we will look at this in next quarter’s planning” to “we are shipping the fix this week” inside a few days. That is not a coincidence. KEV listing converts a vendor-internal scheduling problem into a customer-relations problem.

The second most consistent accelerator is a structured bug-bounty program. Not the bounty payout itself, the program’s published triage SLAs and the visible-from-outside report queue. A vendor whose security team has an externally-readable backlog has a different incentive structure to a vendor whose backlog lives inside JIRA.

What has not changed

A few things look identical to 2020.

  1. The middle band. A mid-tier enterprise vendor selling specialised software with no bug-bounty program responds at a similar speed to its 2020 self. Acknowledgment in 1 to 4 weeks. Fix in 1 to 4 months. Maybe a CVE assignment, maybe not. Maybe a public advisory, maybe a silent ship.
  2. The long tail. Small vendors and end-of-life products produce the same outcomes as 2020. The Quest UC report received “no patch, end of life” as a final answer. That answer is still routine for products in the same category.
  3. The disclosure window. 90 days remains the default coordinated-disclosure norm. Project Zero stuck with it. CERT/CC sticks with it. Most independent researchers stick with it.
  4. The vendor-class divergence. A top-tier vendor was already faster than a long-tail vendor in 2020. The gap between them has widened, not narrowed.

What the divergence implies

Three implications, which are the practical lift-out from all of the above.

For researchers. Your leverage matters. A bug-bounty program raises the floor on triage speed and lowers the variance on outcomes. KEV listing, when it happens, raises the ceiling on patch speed by an order of magnitude. Cold-emailing a mid-tier vendor without either of those signals in 2026 looks essentially like cold-emailing the same vendor in 2020. Plan accordingly.

For defenders. Do not assume an industry-wide patching cadence. Plan for the mid-tier case unless you have specific evidence that a CVE is on KEV or that the vendor’s PSIRT has shipped recently. A patched build existing in the vendor’s release engineering queue is not the same as a patched build on your customer fleet.

For policy. The KEV catalog has worked well at compressing the patching cycle for the narrow set of actively-exploited vulnerabilities. It has not changed the cadence for the much larger set of routine findings. The CRA, when it begins to bite for products sold into the EU, is the next plausible accelerator for the middle band. We will see how that goes.

The 2020 Quest disclosure took seven days from first email to public posting. The product was unpatched and stayed unpatched. If I disclosed an equivalent finding against an equivalent product in 2026, the result would be effectively the same. The infrastructure around it would look more modern. The patch outcome would not.

References