CISA KEV Catalog: Prioritize Device Risk

Reviewed September 17, 2026

Medical device manufacturers ship products built from hundreds or thousands of third-party components, and most published CVEs never see real-world exploitation. Chasing every high-CVSS finding wastes limited security engineering time, while the vulnerabilities that actually get exploited cluster into a smaller, known set. The CISA Known Exploited Vulnerabilities catalog exists to cut through that noise, and it has become a central input for postmarket cybersecurity programs reviewed under the FDA's premarket and postmarket expectations. Manufacturers that ignore it, or that cannot show how it feeds their SBOM and VEX process, create a predictable gap that reviewers and hospital security teams both notice. This post explains what the catalog covers, who is bound by it, and how to wire it into a device vulnerability triage workflow.

Why This Matters

The KEV catalog was established by the Cybersecurity and Infrastructure Security Agency in November 2021 under Binding Operational Directive 22-01, which requires federal civilian executive branch agencies to remediate listed vulnerabilities within set deadlines. Medical device manufacturers are not directly bound by that directive, but hospital IT and security teams that operate under it, or that simply adopt its logic, expect vendors to be able to answer whether a KEV-listed CVE affects a purchased device.

The FDA's February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, does not name the KEV catalog explicitly, but its postmarket cybersecurity management plan expectations require a description of how a manufacturer monitors for emerging vulnerabilities and responds to them. Reviewers look for exploit-availability signals as part of that description, and a plan that lists only the National Vulnerability Database or vendor advisories, with no mention of confirmed exploitation data, reads as incomplete.

The practical stakes are twofold. First, a manufacturer without a KEV-aware triage process risks missing the vulnerabilities most likely to be used against fielded devices. Second, a submission or postmarket audit that cannot show a defensible exploit-monitoring process invites the kind of deficiency finding that delays clearance or draws follow-up questions after a device is already on the market.

What Is the CISA KEV Catalog?

The KEV catalog is a continuously updated, publicly available list of CVEs that CISA has confirmed are being actively exploited, with three defining criteria: the CVE is formally assigned, there is reliable evidence of active exploitation, and clear remediation guidance exists, typically a vendor patch. It is published as a free machine-readable feed that any organization can ingest directly into its own tooling.

The catalog is not a vulnerability scanner, a severity score, or an exhaustive list of important vulnerabilities. A CVE with a high CVSS score but no confirmed exploitation will not appear on KEV, while a CVE with a moderate score can appear if attackers are actively using it. That distinction matters because it changes what the catalog is good for.

Who Must Act on the KEV Catalog?

Binding Operational Directive 22-01 legally requires federal civilian executive branch agencies to remediate KEV-listed vulnerabilities on their networks within CISA-set deadlines, usually a matter of weeks. Medical device manufacturers and hospitals are not directly covered by that directive. In practice, hospital procurement and security teams increasingly ask vendors to demonstrate KEV awareness, and manufacturers who cannot answer quickly lose credibility during security reviews.

For manufacturers, the KEV catalog functions as a prioritization signal layered on top of existing postmarket vulnerability management obligations rather than as an independent legal requirement. It tells a security team which of the many CVEs affecting their SBOM deserve attention first, and it gives hospitals a common reference point when they ask a vendor about a specific vulnerability.

How Does KEV Differ from CVSS and EPSS?

KEV, CVSS, and EPSS answer three different questions, and confusing them leads to either wasted triage effort or missed active threats. CVSS scores theoretical severity based on how a vulnerability could be exploited. EPSS forecasts the probability that a CVE will be exploited in the next 30 days. KEV confirms that exploitation has already happened and remediation guidance exists.

How Does KEV Fit Into SBOM and VEX Triage?

An SBOM lists every third-party component in a shipped device, typically with package URL or CPE identifiers, and the matching step joins that inventory against the KEV catalog, the NVD, and EPSS scores. Any KEV match against a shipped component becomes the highest-priority item in the triage queue, regardless of what its CVSS score shows.

See also: SBOM for SaMD and Cloud Components: FDA Guide, Linux vs Windows for Medical Devices: Security Comparison, and FDA PCCP Beyond AI: Cybersecurity & Firmware Uses.

Once a match is identified, the manufacturer produces a VEX (Vulnerability Exploitability eXchange) statement documenting whether the vulnerable code path is reachable in the shipped configuration, whether a fix is available, and what compensating control exists if not. A "not affected" conclusion is a valid and common outcome, but it needs to be documented rather than assumed.

KEV-listed CVEs frequently drive customer communications even when a device turns out to be unaffected, because hospital security teams see the same public feed manufacturers do and ask directly. A postmarket program should be able to issue a short advisory naming the CVE, its KEV status, the affected component, and the VEX-backed position within days, not weeks.

How Do You Build a KEV Triage Workflow?

A defensible workflow follows a consistent sequence from feed ingestion to customer communication, and each step should have a named owner and a target turnaround time. The workflow below is a starting structure that most postmarket programs can adapt to their release cadence.

1. Subscribe to the KEV catalog feed and ingest new entries daily.
2. Match new KEV entries against the active SBOM index for every supported product line.
3. Open a triage record for every match, capturing exploit path, affected version, and owner.
4. Produce or update a VEX statement for each match within a defined service level, commonly seven days.
5. Issue a customer advisory when a device is affected, or when customer security teams are likely to ask regardless.
6. Track time-to-VEX and time-to-advisory as ongoing postmarket metrics.

How Does the FDA Treat KEV in Submissions?

The FDA's postmarket cybersecurity management plan expectations, described in the February 3, 2026 final premarket guidance, require manufacturers to explain how they monitor for emerging vulnerabilities and respond to them, without naming the KEV catalog by name. Reviewers still commonly look for it as a named input, because it is the standard public source of confirmed exploitation data.

The most frequent deficiency pattern involves an SBOM that includes components with KEV-listed CVEs and no accompanying VEX statement addressing them. Reviewers generally do not require full remediation before clearance, but they do expect a documented, technically justified position on every KEV match.

How Blue Goat Cyber Approaches This

We build postmarket vulnerability monitoring programs that treat the KEV catalog as the top-priority signal, ingesting it daily and matching entries against a manufacturer's SBOM index across every supported product. VEX statements are produced against a defined service level, and customer advisory templates are prepared in advance so the time between a KEV update and a customer communication stays short. If your postmarket program needs a defensible, KEV-aware triage process that will hold up in an FDA review, our postmarket cybersecurity services team can help design and operate it.

Frequently Asked Questions

Is the CISA KEV catalog mandatory for medical device manufacturers?

The KEV catalog is legally mandatory only for US federal civilian executive branch agencies under Binding Operational Directive 22-01. It is not directly mandatory for medical device manufacturers, but the FDA's postmarket monitoring expectations make a KEV-aware vulnerability program effectively necessary for a defensible submission and ongoing compliance.

How often is the KEV catalog updated?

CISA updates the catalog as exploitation evidence is confirmed, which can happen multiple times per week. Postmarket programs should ingest the feed daily and triage new matches against their SBOM index within a defined turnaround time rather than checking it periodically.

Do we need a VEX statement for every KEV-listed CVE?

You need a VEX statement for every KEV-listed CVE that matches a component in your shipped SBOM. If a CVE does not match any shipped component, no VEX statement is required, but the matching evidence should still be recorded so the absence of a statement is itself defensible during a review.

How does KEV interact with CVSS in practice?

CVSS provides a severity score, while KEV confirms active exploitation. A CVE with a CVSS score of 9.8 and no KEV listing is theoretically severe but unconfirmed in the wild, while a CVE with a moderate CVSS score on KEV is being actively exploited and warrants immediate triage. Most mature programs prioritize KEV status above any CVSS threshold.

What role does EPSS play alongside KEV?

EPSS estimates the probability that a CVE will be exploited within the next 30 days and is most useful for prioritizing CVEs that have not yet appeared on KEV. A common triage stack works through KEV-listed CVEs first, then high-EPSS items, then remaining high-CVSS items, with a VEX statement addressing each layer that touches the SBOM.

CTA

If your postmarket program needs a KEV-aware triage workflow that produces defensible VEX statements on a consistent schedule, we can help design and run it. Schedule a discovery call to review your current SBOM and vulnerability monitoring process.