Operationalising the KEV Catalogue: Turning known exploited vulnerabilities into immediate action
By Sriram Kakarala, Chief Product Officer, Scalefusion
Security vulnerabilities exist wherever software runs, across applications, operating systems and connected devices. Some remain theoretical and are never acted on, but others are actively exploited by attackers, and it is this second group that organisations need to treat as an immediate priority. Knowing which vulnerabilities have already been exploited gives security and IT teams a clear signal of where attention is needed.
The Known Exploited Vulnerabilities (KEV) Catalogue, maintained by the Cybersecurity and Infrastructure Security Agency (CISA), is a public, curated list of confirmed exploited vulnerabilities, giving organisations clarity on active exploitation. Federal agencies must remediate these vulnerabilities within fixed deadlines while commercial and private organisations are not obligated to do the same.
However, knowing what is being exploited is only the starting point. The catalogue may be public, but an organisation’s own exposure to what it contains is not. Federal deadlines for closing those vulnerabilities are mandatory, yet closure rates against them are rarely measured. The intelligence arrives in a structured form, but not as executable work.
The advantage lies in prioritising exploited vulnerabilities over merely known ones, and acting fast enough to verify closure.
Why KEV starts a different remediation clock
Threat intelligence is often shared within limited circles, but KEV is different. When CISA adds a Common Vulnerabilities and Exposures (CVE) entry to its catalogue, defenders and attackers gain the information at the same time. Since the catalogue records demonstrated exploitation, it guides defensive priorities while also showing opportunistic attackers where successful attacks have already occurred.
This changes the remediation deadline. A conventional patch window is usually shaped by an organisation’s calendar and change process, but a KEV window is shaped by adversary behaviour. Scanning activity for a CVE can rise after public confirmation of exploitation, while the threat surface area widens by the hour, not the quarter.
KEV remediation is therefore adversarially time-boxed: the clock is shaped by activity outside the organisation, not by when its internal process is ready to respond.
The exposure clock starts before the internal ticket
Organisations can see a gap between a vulnerability’s KEV publication and the start of remediation, which attackers can exploit. The sequence: exploitation occurs, evidence is corroborated, CISA publishes the entry, a scanner matches it to fleet inventory, and a ticket is assigned.
Exposure begins at the first step; remediation SLAs typically begin only at the last. A recent analysis of scanning and exploitation activity across 18 edge and network vendors found that roughly half of attacker activity surges were followed by a vendor disclosure within three weeks. The median gap was 11 days between the first sign of exploitation and the public advisory that supposedly starts the clock, by which point CISA had usually already listed the vulnerability in KEV.
An organisation can therefore report full KEV compliance against its internal deadline while the exposure may already have begun; measuring verified closure gives a clearer picture of the actual response.
Vulnerability management is a throughput problem
Security programmes are good at measuring what arrives, but they also need to measure what leaves. Two numbers determine whether a vulnerability programme can keep pace: arrival rate and closure rate. Arrival rate measures how many exposures enter the remediation queue each week, while closure rate measures how many are verifiably remediated in the same period. If closure stays below arrival, the backlog grows; prioritisation changes the order of the queue, not its capacity.
This creates a distinction between detection and remediation. Detection is a demand-side function, while remediation is a supply-side function. Organisations have spent years investing in detection, which has increased the volume of identified work, while remediation capacity has not grown to match it. That imbalance, not the detection itself, is what needs to be addressed.
Where remediation throughput breaks
Closure rate is constrained by three points. The first is mapping: the KEV Catalogue lists CVEs, while the fleet actively runs the exposed applications, software versions, and operating system (OS) builds. Thus, translating between them requires live inventory, not an occasional snapshot.
The second is authorisation. The team that identifies an exposure may not control the affected device, and every handoff between security and IT adds time while the exposure stays open.
The third is verification. A deployed patch and a closed vulnerability are different claims; closure requires checking the device again to confirm its state has changed.
The tools involved may each work as designed, but the delay accumulates between them. Throughput is therefore an endpoint operations discipline, not simply a security reporting discipline.
What immediate KEV action requires in practice
Acting on KEV at the required speed means reducing the gap between finding and fixing. Continuous discovery should identify OS and third-party vulnerabilities against current device state.
Threat-informed prioritisation combines KEV, the Exploit Prediction Scoring System (EPSS) and device risk scores, so limited remediation effort targets confirmed exploitation over theoretical severity. SLA-driven policy attaches a deadline and owner per severity class in advance.
Remediation allows administrators to patch from the console that identified the issue, using the agent already present on the device and avoiding another handoff. Automated grouping turns a CVE into a device cohort, a practical unit of work for administrators.
Verification then confirms the resolved state and closes the loop. When a patch is unavailable, containment becomes the immediate action: isolating a non-compliant endpoint requires the capability to control the device, which is the practical difference between observing an exposure and ending it.
Why remediation is moving from tickets to policy
The window between disclosure and weaponised exploitation has been narrowing for years. If exploitation can occur faster than an organisation’s change-approval cycle, that approval process itself becomes part of the exposure window.
This creates a case for moving from ticket-driven response towards policy-driven action: instead of deciding what to do each time a qualifying vulnerability appears, an organisation establishes the response in advance.
This does not mean automatically patching everything. It means prioritising remediation within defined rings, staged and reversible, decided once, in advance.
The organisations that stay ahead are those that have already decided what happens when a vulnerability is found, not those still deciding after exposure has begun.
What the KEV Catalogue does not solve
KEV is narrow by definition, not by design; it works as intended, flagging vulnerabilities with proven exploitation that organisations must prioritise. It is a lagging indicator because inclusion means exploitation has already been observed. It is not exhaustive because targeted or unreported exploitation will not appear in the catalogue.
For that reason, KEV should be treated as a baseline for confirmed exploitation rather than a complete picture of exposure. Closing every KEV entry within the deadline shows an organisation can execute against confirmed exploitation. It does not show every exposure has been addressed. The catalogue is therefore a critical security signal, but it cannot replace a broader vulnerability management strategy.
Final Thought
The KEV Catalogue has already made one of the most important pieces of vulnerability intelligence freely available. The harder problem is operationalising that across the fleet: prioritising exploited over known vulnerabilities, identifying devices, assigning ownership, acting within a window, and verifying closure.
The most useful measure is therefore not how many KEV vulnerabilities an organisation has identified, but the median time from KEV publication to verify closure, and whether that number is falling. That measure evaluates how quickly and effectively an organisation turns confirmed exploitation into verified closure, the outcome that matters.