COMMENTARY: The June directive from the Cybersecurity and Infrastructure Security Agency (CISA) on vulnerability remediation cites AI compressing the time between patch release and exploitation -- and the catalog it points defenders at keeps growing.The known exploited vulnerabilities (KEV) catalog held 1,705 entries on Sept. 10, 2026, spanning 283 vendors and 719 product listings, and any one organization runs just a small share of them.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]So how is KEV remediation going?Verizon's 2026 Data Breach Investigations Report puts full KEV remediation at 26% for 2025, down from 38%, with median time to resolution having increased to 43 days from 32.The same report finds the best performers close 30% to 40% of KEV instances in the first week after detection and then flatten. That first week represents the observed ceiling. What a team controls is which entries consume it, and CISA already publishes most of the data that sets the order. The sort requires a four-step funnel: each pass narrows the queue before the next decision.Here's how I'd apply that order: filter by inventory, sort by the directive's own inputs, treat the top tier as an investigation, then use exploitation recency to break what's left.The first question is about presence, not severity. The KEV catalog took on 221 entries in 2026 through Sept. 11, about six a week. The feed names vendors and products, but carries no CPE identifier, so the match to an asset inventory runs through a mapping the team builds and then maintains. Product strings drift, cloud assets come and go, acquisitions arrive with their own naming. That upkeep helps shrink the queue. Once the mapping runs, each week's additions arrive filtered to software the organization owns, and analysts stop scoring entries for products nobody deployed.Sort what survives using CISA's own decision pointsBinding Operational Directive (BOD) 26-04 took effect June 10, revoking BOD 22-01 and ending the federal requirement to prioritize by CVSS.CISA's rationale cites AI compressing the gap between patch release and exploitation. Four inputs set the clock: public exposure, KEV status, whether an exploit can be automated, and technical impact. A publicly-exposed KEV flaw that hands over total control gets three days plus a forensic check. Most other combinations get 14. Of the 88 entries added since the directive took effect, 67 carry three-day deadlines, and 21 do not.CISA publishes the automatability and impact answers through its Vulnrichment program and leaves them out of the KEV feed, so building the sort means merging two sources. Exposure is the operator-held input, and it moves the deadline in both directions as an asset comes off or goes onto the internet.Work the top tier as an investigation with a patch at the endForty-nine of those 88 entries carry a forensic-triage flag. For an exposed edge device, assume the exploitation window opened before the fix landed: hunt for evidence of exploitation, review authentication activity, rotate the credentials and tokens the device held, and confirm attackers left no persistence.In the Firebox flaw CISA flagged this month, WatchGuard documented theft of the device configuration and the local user database. Patching in January does not recover the credentials stolen in December.KEV answers one binary question: whether a vulnerability has been exploited. It does not say when. Verizon's model of roughly 1,000 vulnerabilities observed daily over six years finds exploitation probability falling as time since the last observed exploitation grows, and 991 KEV entries showed detectable activity in the preceding 12 months.Where local exploitation telemetry exists, it answers that faster than any catalog will. Among entries with comparable exposure and impact, an older flaw the sensors still see outranks a newer listing that has gone quiet.The ransomware column will not settle it either. CISA's commit history records 112 silent flips to “Known” since January 2025, with a median of about 360 days after listing. That field represents a receipt for a past attack, not a warning about the next one.CISA can make this sort cheaper without making KEV bigger. Three changes would do most of the work:
Keeping up with the whole catalog was never the job. Since June, entries landing on the federal three-day clock have averaged five a week across the full catalog, and the inventory filter cuts it again for any one organization. Rank what survives by exposure and consequence, work the top tier as an incident, and let the rest wait its turn.Collin Hogue-Spears, senior director of solution management, Black DuckSC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
- Add a date to the ransomware field and publish every change to it through a change feed: Roughly half of those flips landed more than a year after the entry appeared; none carried an alert and finding them at all has meant diffing daily snapshots of a federal data source.
- Put the decision data in the KEV feed itself: The directive commits CISA to publishing automatability and technical impact for every KEV entry, and the feed's 12 fields carry neither, so every defender rebuilding the federal sort pays that merge cost separately.
- Publish an exploitation-recency signal: A last-observed date, or any indicator that exploitation remains active, separates historical KEV status from a campaign still producing telemetry today. The same data-quality pass retires the entries added in late 2025 that still send readers to BOD 22-01, revoked in June.
