CISA KEV Catalog: The Vulnerabilities You Must Fix Now

In mid-October 2023, CISA added CVE-2023-4966 (Citrix Bleed) to the Known Exploited Vulnerabilities catalog. Within days, organizations that had treated it as a routine medium-severity information disclosure flaw --- because that is what CVSS initially suggested --- discovered that ransomware groups had been exploiting it for weeks to hijack authenticated sessions on NetScaler appliances across thousands of networks. The organizations that monitored KEV had already patched. Everyone else spent the weekend in incident response.

That is the value proposition of the KEV catalog in a single anecdote: it tells you which vulnerabilities are being exploited right now, not which ones theoretically could be.

Why This Matters Now

Of the 240,000+ CVEs in the National Vulnerability Database, roughly 1,200 have earned a spot on CISA's Known Exploited Vulnerabilities catalog. That is less than 0.5%. These are not theoretical risks or proof-of-concept demonstrations. These are vulnerabilities where CISA has confirmed observed attacks against real systems in the wild.

Three developments make KEV more important today than when it launched in 2021:

BOD 22-01 enforcement has matured. Federal agencies are now audited against KEV remediation timelines. Inspector General reports cite open KEV findings by name. The directive has teeth.

CISA BOD 26-04 extended risk-based patching requirements and explicitly references KEV as the highest-priority input to vulnerability management programs across the federal enterprise.

Commercial adoption has accelerated. Cyber insurance applications, SOC 2 audits, PCI DSS v4.0 targeted risk analyses, and board-level reporting all increasingly reference KEV compliance. What started as a federal mandate is becoming an industry standard.

The KEV catalog is arguably the single most valuable free artifact in vulnerability management: a curated, continuously updated, zero-false-positive list of the vulnerabilities attackers are using today.

What the KEV Catalog Is

The Known Exploited Vulnerabilities catalog is maintained by CISA (Cybersecurity and Infrastructure Security Agency), the U.S. federal government's civilian cybersecurity agency. Launched November 3, 2021, alongside Binding Operational Directive 22-01, it is published as both a machine-readable JSON feed and a human-readable web page, updated continuously.

Each KEV entry contains:

Field	Description
CVE ID	Standard CVE identifier
Vendor/Project	Affected software vendor or project
Product	Specific affected product
Vulnerability Name	Human-readable description
Date Added	When CISA added the entry
Required Action	What must be done (typically "Apply updates per vendor instructions")
Due Date	Remediation deadline for federal agencies under BOD 22-01
Known Ransomware Campaign Use	Whether used in ransomware operations
Notes	Additional context or caveats

BOD 22-01: The Federal Mandate

Binding Operational Directive 22-01 ("Reducing the Significant Risk of Known Exploited Vulnerabilities") requires all Federal Civilian Executive Branch (FCEB) agencies to remediate each KEV entry by the due date CISA assigns to it --- typically about three weeks from the date of addition to the catalog.

Remediation Timelines

The original directive set two weeks for CVEs assigned in 2021 or later and six months for older CVEs
Each KEV entry now carries its own due date, typically about three weeks out for new additions; CISA can set tighter deadlines for high-urgency zero-days
Due dates apply from date of addition, not from original CVE publication date. A vulnerability from 2019 added to KEV in 2025 gets a fresh remediation deadline.

Scope

BOD 22-01 directly binds all civilian federal agencies except DoD and Intelligence Community (which operate under separate, equally stringent directives). However, the practical scope extends further:

Federal contractors face KEV requirements through DFARS 252.204-7012, CMMC, and FedRAMP
State and local governments are encouraged to follow KEV guidance
Private sector has no legal obligation, but KEV has become a de facto industry standard for "must-fix" prioritization

How Entries Are Selected

Not every exploited vulnerability makes KEV. CISA applies three criteria, all of which must be met:

Criterion 1: CVE ID assigned. The vulnerability must have a formal CVE identifier. Exploited bugs without CVEs cannot be added.

Criterion 2: Active exploitation confirmed. CISA must have reliable evidence of attacks against real targets --- not just the existence of exploit code. Sources include government sensors, FBI reporting, NSA intelligence, private-sector threat intelligence partnerships, incident response engagements, and vendor confirmations. A proof-of-concept on GitHub does not qualify unless observed exploitation follows.

Criterion 3: Clear remediation action available. A vendor-supplied patch or documented mitigation must exist. CISA does not add vulnerabilities with no path to remediation (though this criterion has been applied flexibly for high-urgency zero-days where the vendor has just released a fix).

This three-gate process means the false positive rate is effectively zero. If a CVE is in KEV, it is being exploited against real organizations.

KEV by the Numbers

As of mid-2026:

Total entries: Approximately 1,200+ CVEs
Vendors represented: 200+ distinct vendors
Oldest entries: CVEs dating to 2010 and earlier (legacy vulnerabilities still actively exploited)
Ransomware flag: Approximately 20-25% of entries are confirmed used in ransomware campaigns
Addition pace: Roughly 150-200 new entries per year after the initial 2021 bulk load

Top Vendors in KEV

The most-represented vendors reflect attacker targeting preferences, not product quality:

Microsoft --- Windows, Exchange, Office, Active Directory
Apple --- iOS, macOS, WebKit
Google --- Chrome, Android
Cisco --- IOS, ASA, networking products
Fortinet --- FortiOS, FortiGate (CVE-2024-21762 added February 2024)
VMware --- vCenter, ESXi
Ivanti --- Connect Secure, EPMM, Sentry
Apache --- Log4j (CVE-2021-44228), HTTP Server
Citrix --- NetScaler (CVE-2023-4966, Citrix Bleed)

The pattern is clear: network edge devices (VPN appliances, firewalls, remote access gateways) are disproportionately represented. Attackers target perimeter infrastructure because it is internet-facing, often unmonitored by EDR, and provides immediate lateral movement capability once compromised.

Why KEV Matters Beyond Federal Compliance

The Highest-Signal Prioritization Input Available

CVSS tells you how bad a vulnerability could be theoretically. EPSS predicts how likely exploitation is statistically. KEV tells you exploitation is happening right now against real organizations. There is no higher-confidence signal in vulnerability management. When a CVE appears in KEV, the question shifts from "should we prioritize this?" to "how fast can we deploy the patch?"

The Most Curated Must-Fix List in Existence

KEV is not a raw data dump. Every entry has been validated against three criteria by an organization (CISA) with visibility into government intelligence, private-sector partnerships, and active incident response engagements. No other public vulnerability feed offers this level of curation with this confidence level.

Increasingly Referenced in Commercial Standards

KEV is appearing in contexts far beyond federal compliance:

Cyber insurance applications ask about KEV remediation practices and open KEV finding counts
SOC 2 auditors reference KEV as a reasonable benchmark for prioritization rigor
PCI DSS v4.0 emphasizes targeted risk analysis for remediation prioritization --- KEV fits naturally
Board-level reporting uses "open KEV findings" as a metric because non-technical stakeholders immediately understand "these are vulnerabilities being actively exploited and we have not fixed them"
Third-party risk assessments from partners and customers reference KEV compliance posture

The Contrarian Take: KEV Is Necessary but Radically Insufficient

Here is the uncomfortable truth about KEV: by the time CISA adds a vulnerability to the catalog, exploitation has already been happening --- often for days or weeks. KEV is confirmatory intelligence, not predictive intelligence. Organizations that treat KEV as their primary prioritization signal are, by definition, always behind the exploitation curve.

The real value of KEV is as a floor, not a ceiling. If you have open KEV findings, your program has a serious problem. But if you only remediate KEV entries aggressively, you are ignoring the vulnerabilities that will be in KEV next week. Pair KEV with predictive signals --- EPSS scores above 0.10, exploit code appearing on GitHub, vendor emergency advisories --- and you catch the next Citrix Bleed before CISA confirms it, not after.

Integrating KEV into Vulnerability Management

Step 1: Automated KEV Matching

Consume the JSON feed (https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) and match against your open vulnerability findings by CVE ID. Flag matches for immediate escalation. Most vulnerability management platforms consume this feed natively; if yours does not, the integration is straightforward --- it is a well-structured JSON array updated in real-time.

Step 2: Define KEV-Specific SLAs

KEV findings deserve the most aggressive remediation SLAs in your program:

Scenario	Target
KEV on internet-facing production system	48 hours
KEV on internal production system	7 days
KEV on non-production system	14 days
KEV with ransomware flag, any system	48 hours

These are more aggressive than the federal due dates because those timelines are designed for the least-capable agencies managing the most complex environments. Mature organizations should move faster.

Step 3: Executive Reporting

KEV findings make excellent executive metrics because they require no technical translation:

"We have X open findings for vulnerabilities CISA confirms are being actively exploited"
"Our average remediation time for actively exploited vulnerabilities is Y days"
"Z percent of our actively exploited findings are on internet-facing systems"

Any board member, auditor, or regulator understands the significance immediately.

Step 4: Vendor Management

Use KEV as a lens for third-party risk: ask vendors about their KEV remediation posture during assessments, track KEV entries affecting your supply chain, and escalate vendor communications when their products appear in the catalog.

Step 5: Automated Alerting

Set up real-time alerts for new KEV additions that match your software inventory, entries flagged for ransomware use (escalate regardless of other context), and entries for perimeter devices you operate (VPN, firewall, remote access).

KEV, EPSS, and CVSS: The Decision Framework

The three systems answer different questions and are strongest combined:

System	Question Answered	Signal Type	Update Frequency
CVSS	"How severe is this technically?"	Severity rating	Static (rarely updated)
EPSS	"How likely is exploitation?"	Probability prediction	Daily
KEV	"Is this being exploited now?"	Confirmed exploitation	As events occur

Practical decision flow:

In KEV? Remediate immediately regardless of CVSS or EPSS. Active exploitation trumps all other signals.
EPSS above 0.10? Escalate. Meaningful exploitation probability even without KEV confirmation.
CVSS 9.0+ with low EPSS and no KEV? Schedule for near-term remediation. High severity without exploitation signals still warrants attention.
CVSS 7.0-8.9 with low EPSS? Standard remediation queue. Monitor EPSS for changes.
Everything else: Risk-based SLAs, standard queue.

This flow catches virtually all actively exploited vulnerabilities in steps 1-2 and handles the bulk of findings efficiently in steps 3-5.

Key Takeaways

KEV entries represent confirmed active exploitation --- not theoretical risk, not PoC code, but observed attacks.

Roughly 1,200 of 240,000+ CVEs are in KEV (<0.5%). This curated list has effectively zero false positives.

BOD 22-01 mandates remediation by each entry's CISA-assigned due date (typically about three weeks); mature organizations should target 48 hours for internet-facing assets.

KEV is a floor, not a ceiling. Pair it with EPSS and exploit intelligence to stay ahead of the next addition.

Commercial adoption is accelerating: insurance, SOC 2, PCI DSS, and board reporting all reference KEV.

Frequently Asked Questions

If a vulnerability is not in KEV, does that mean it is safe?

No. KEV only includes vulnerabilities where CISA has confirmed active exploitation against all three criteria. A vulnerability could be exploited by targeted threat actors in limited operations and not appear in KEV because CISA lacks visibility into that specific campaign. KEV captures broad exploitation trends; it does not have complete global visibility.

Can entries be removed from KEV?

Removals are rare. CISA has removed a small number of entries --- typically when the underlying CVE was later disputed or the exploitation evidence did not hold up. Absent that, once added, a vulnerability remains. The rationale: a vulnerability exploited in the past may be exploited again as exploit code circulates and new vulnerable installations are discovered. The catalog is effectively append-only.

How does KEV relate to DISA STIGs?

STIGs define configuration baselines. KEV identifies exploited vulnerabilities. A system can be fully STIG-compliant and still have open KEV findings if the STIG has not been updated to address a newly exploited flaw. Both should be part of a comprehensive security program, but they serve fundamentally different functions. See our DISA STIG automation coverage for more on the relationship.

Should we automate KEV remediation?

Where possible, yes. Automated patch deployment for KEV entries --- with staged rollouts and automated rollback on failure --- reduces the window of exposure. Prioritize automation for standard software (OS patches, browser updates, common applications). Custom or business-critical applications may require manual validation, but the goal should be automated deployment as the default with manual override as the exception.

How quickly are new vulnerabilities typically added to KEV after exploitation begins?

It varies significantly. Some zero-days are added within days of exploitation discovery (CVE-2024-21762 was added within a week of Fortinet's advisory). Others, particularly those exploited quietly by advanced threat actors, may take weeks or months before CISA confirms the activity. This lag is precisely why KEV should be paired with predictive signals like EPSS rather than used as a standalone prioritization input.

How Advisedly Helps

Advisedly ingests the CISA KEV catalog in real-time and automatically cross-references every entry against your asset inventory, flagging matches with escalated SLAs and executive-ready reporting. Combined with TRACE Score prioritization that fuses KEV status, EPSS probability, CVSS severity, and asset context, Advisedly ensures that actively exploited vulnerabilities never sit unnoticed in a backlog of 50,000 findings. New KEV additions trigger immediate alerts mapped to your specific environment --- so you know within minutes whether a newly confirmed exploitation campaign affects your infrastructure, not days later when someone reads a news article.

Ready to fix what matters first? Contact us at begin@advisedly.ai to see how KEV-integrated prioritization transforms your remediation calculus.