CISA known exploited vulnerabilities: a dated signal for underwriters

CISA's known exploited vulnerabilities (KEV) catalog is the U.S. government's list of software and hardware flaws that attackers have been seen exploiting, kept by the Cybersecurity and Infrastructure Security Agency, which calls it "the authoritative source of vulnerabilities that have been exploited in the wild" (CISA). Each entry carries a CVE identifier, the product, the required action, the date CISA added it and whether it is known to have been used in ransomware campaigns. On 27 October 2026 the catalog held 1,760 entries. For cyber underwriting, the date is the valuable part: matched to the version an outside-in scan finds on an insured's internet-facing systems, it turns "Do you patch critical vulnerabilities within 14 days?" into a question with a dated answer. Botminds' Cyber Underwriting Risk Assessment makes that match on every submission and puts the result beside the signed patching answer.

This guide explains what the catalog contains and how it grows, the directive that governs it since June 2026, how fast CISA expects listed flaws to be fixed, and how an underwriter can use the listing date without over-reading it. The worked example is a fictional sample submission: a freight company whose edge VPN appliance carried a listed flaw.

What is the CISA known exploited vulnerabilities catalog?

It is a public list, maintained by CISA since November 2021, of vulnerabilities that meet three conditions. In CISA's words: "The vulnerability has an assigned Common Vulnerabilities and Exposures (CVE) ID"; "There is reliable evidence that the vulnerability has been actively exploited in the wild"; and "There is a clear remediation action for the vulnerability, such as a vendor-provided update" (CISA, KEV criteria). The catalog is published as a web page and as a machine-readable feed, so it can be matched automatically against scan results.

Each entry has a fixed set of fields: the CVE ID, vendor and product, a short description, the required action, the date added, a due date for federal agencies, whether the flaw is known to have been used in ransomware campaigns, whether CISA requires a forensic check after patching, and notes. For an underwriter the date added and the ransomware flag are the fields that change a decision.

What is a known exploited vulnerability, and what does not count?

A known exploited vulnerability is one with reliable evidence that an attacker ran malicious code through it on a system without the owner's permission. CISA counts attempted as well as successful exploitation, and is explicit about what does not qualify: scanning, security research and proof-of-concept code. "Having a publicly available PoC is not a requirement for a vulnerability to be included in the KEV catalog", and a public proof of concept alone does not put a flaw on the list.

That is a narrower test than severity. CISA's FAQ for the original directive, written in 2021 and now archived, explained why it matters: "less than 4% of the total number of CVEs have been publicly exploited", while many flaws rated critical "have never been seen exploited in the wild" (CISA, BOD 22-01 FAQ). A scan report that lists dozens of high-severity findings tells an underwriter much less than one that lists a single internet-facing flaw on the catalog.

How often is the KEV catalog updated?

Whenever CISA has the evidence, which in practice means several times a week: in 2026 CISA added entries on 125 different days, a median of three days a week. The 2021 FAQ said "CISA updates the KEV Catalog within 24 hours of known exploitation evidence", and the current directive tells CISA to "Update the catalog as quickly as possible". The catalog opened with 311 entries in its first two months and has grown by 186 to 555 entries a year since.

Age is not a bar to listing. "If there is accurate reporting of active exploitation, any vulnerability, despite its age, can qualify for KEV Catalog addition", the FAQ says, and an addition "does not indicate that CISA is observing current active exploitation." An underwriter should read the date added as the date the government told everyone, not as the date attacks began.

What is BOD 22-01, and what replaced it in 2026?

BOD 22-01 was the binding operational directive of 3 November 2021 that created the KEV catalog and told federal agencies to fix listed flaws by set deadlines. It no longer applies. On 10 June 2026 CISA issued BOD 26-04, Prioritizing Security Updates Based on Risk, which "supersedes and hereby revokes" BOD 22-01 and the older BOD 19-02 on internet-accessible systems (CISA BOD 26-04). The catalog continues: as CISA's own page puts it, BOD 26-04 "carries forward the KEV catalog criteria from BOD 22-01".

What changed is how urgency is set. BOD 26-04 decides each remediation timeline from four questions: whether the asset is publicly exposed, whether the flaw is on the KEV catalog, whether exploitation can be automated, and whether exploitation gives an attacker partial or total control. Two of those, exposure and KEV status, are exactly what an outside-in scan matched to the catalog answers about an insured.

How fast should known exploited vulnerabilities be patched?

For federal agencies, in days, and sometimes with a forensic check. Under BOD 26-04 the shortest timeline is three days, and for some flaws it comes with a forensic triage: "the agency must complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised." CISA's implementation guidance sets target times for the triage, from scoping within the first two hours of a KEV addition to an escalation decision within 48 to 72 hours (CISA implementation guidance, updated August 2026).

The catalog itself shows how often the short band is used. Of the 143 entries CISA added between 11 June and 27 October 2026, 115 carry a due date three days after the date added, 93 of them with a forensic triage required, and 28 carry a 14-day due date. Those are federal deadlines. A private company is not bound by them, but they are the clearest public statement of what "promptly" means for a listed flaw, and they make a 14-day patching promise on an application easy to test.

Does KEV apply to private companies?

Not as a legal requirement; as a recommendation, emphatically. CISA's page on using the catalog says: "Although not bound by BOD 26-04, every organization, including those in state, local, tribal, and territorial (SLTT) governments and private industry can significantly strengthen their security and resilience posture by prioritizing the remediation of the vulnerabilities listed in the KEV catalog as well." It adds that CISA "strongly recommends all stakeholders include a requirement to immediately address KEV catalog vulnerabilities as part of their vulnerability management plan."

For an insurer, that recommendation is a usable standard. An application can ask whether the insured monitors the KEV catalog and in how many days it remediates listed flaws on internet-facing systems, and the scan can test the answer. That is a sharper question than "Do you patch critical vulnerabilities promptly?", because both sides of it have dates.

How do insurers use the KEV list? Listing date against signature date

The useful comparison is three dates: when CISA listed the flaw, when the insured signed the application, and when the scan found the flaw still present. In the sample at the top of this page, the edge VPN appliance's flaw was listed on 21 August, the application signed on 18 September promised patching within 14 days, and the scan of 9 October still found the vulnerable firmware. At signing the flaw had been listed for 28 days, twice the promised window, so the patching answer was contradicted on the day it was given, not merely overtaken by events afterwards.

The order matters for fairness as well as for risk. A flaw listed the day after the application was signed is a question for the broker and a reason to rescan, not a misrepresentation. The listing date is what lets an underwriter tell the two apart without arguing. Why the scan can see this at all, and what it cannot see, is in the guide to cyber insurance security scan tools.

A known-exploited finding beside the patching answer it contradicts

The ransomware flag in the KEV catalog, and how much weight it bears

Each entry answers "Known To Be Used in Ransomware Campaigns?" with "Known" or "Unknown". On 27 October 2026, 361 of the 1,760 entries were marked "Known". For an underwriter weighing ransomware exposure, a listed flaw with the ransomware flag on an internet-facing system is the strongest single scan finding an underwriter is likely to see, and a reason to make the fix a condition of binding rather than of renewal.

"Unknown" does not mean safe. It means CISA has no confirmed report of ransomware use; it says nothing about other attacks. Of the 143 entries added since June 2026, eight carry the ransomware flag, and most of the rest still carry a three-day federal deadline.

What the KEV catalog cannot tell a cyber underwriter

The catalog describes vulnerabilities, not companies. It cannot say whether an insured runs the affected product, whether that system is exposed to the internet, or whether a fix has been applied; those come from the scan, the penetration test and the insured. It cannot see internal systems, where many exploited flaws in servers and workstations live, and a scan matched to the catalog is limited to versions that announce themselves.

It also lags reality in both directions. A flaw can be exploited for weeks before CISA has reliable evidence, and a vulnerability whose CVE is still reserved cannot be listed. The catalog is the best dated public signal an underwriter has, not a complete one. Pairing it with the MFA evidence in does cyber insurance require MFA covers the other common way in, stolen credentials on exposed remote access.

How Cyber Underwriting Risk Assessment uses KEV dates

The solution's scan matcher reads the carrier's outside-in scan as recorded, and where a finding names a product version on the catalog, it carries the listing date into the evidence. The control grader then puts that evidence beside the signed patching answer and grades the critical patching control: contradicted when the flaw was listed longer ago than the promised window when the application was signed, a question for the broker when the listing came after the signature. The subjectivity writer drafts the fix from the carrier's library, with the asset filled in and a rescan before binding.

The underwriter decides what the contradiction means, and can edit or override it with a reason. How patching questions should be worded on the application in the first place is in cyber insurance application questions.

The scan finding as recorded: an edge VPN appliance with a known-exploited flaw

Questions people ask

How many vulnerabilities are in the CISA KEV catalog?

1,760 on 27 October 2026, by our count of CISA's data feed, with 276 of them added during 2026. CISA publishes the catalog as a web page and as a machine-readable JSON feed, which is what matching tools use.

What is the difference between CVSS severity and KEV?

CVSS scores how severe a flaw could be; KEV records that attackers have actually used it. CISA's 2021 FAQ noted that attackers chain "high", "medium" and even "low" rated flaws, and that many critical-rated flaws have never been exploited, which is why it told agencies to put KEV entries first.

What is the KEV due date?

It is the deadline for U.S. federal civilian agencies to remediate the flaw under BOD 26-04, counted from the date added. Since June 2026 most new entries have carried a three-day due date. Private organisations are not bound by it, but it is a useful benchmark for a patching promise.

Should a KEV finding block a cyber quote?

That is the carrier's guide to decide. A listed flaw has a known fix, since a clear remediation action is a condition of listing, so a pre-bind subjectivity with a rescan is a proportionate answer; a flaw that cannot be fixed, on an end-of-life appliance, is a different conversation.

What is BOD 26-04?

It is CISA's binding operational directive of 10 June 2026, Prioritizing Security Updates Based on Risk. It revoked BOD 22-01 and BOD 19-02, kept the KEV catalog, and sets federal remediation timelines from exposure, KEV status, automatability and technical impact.