Framework

CISA KEV Catalog
the Known Exploited Vulnerabilities framework

The CISA Known Exploited Vulnerabilities (KEV) Catalog is the authoritative public list of CVEs the Cybersecurity and Infrastructure Security Agency has observed in real-world attack activity. Established under Binding Operational Directive 22-01 in November 2021, the catalog publishes inclusion criteria, mitigation timelines, and a continuously updated entry feed that federal civilian executive branch agencies are mandated to remediate and that the broader internal security community uses as a curated exploitation signal. This page covers the BOD 22-01 mandate, the inclusion criteria, the catalog structure, the cross-walk to NIST CSF 2.0, ISO 27001, SOC 2, PCI DSS, NIS2, DORA, and CIS Controls, the audit evidence an internal KEV programme runs against, and where the KEV catalog sits next to CVSS, EPSS, NVD, and the wider vulnerability intelligence regime.

Get Started Free

No credit card required. Free plan available forever.

The CISA KEV Catalog explained

The CISA Known Exploited Vulnerabilities (KEV) Catalog is the authoritative public list of CVEs the Cybersecurity and Infrastructure Security Agency has observed in real-world attack activity. The catalog was established under Binding Operational Directive 22-01 on 3 November 2021, and it has grown into the single most useful exploitation-evidence signal a vulnerability management programme can read. It is short, it is authoritative, it is updated continuously, and every entry has been seen in attack telemetry rather than theorised in a research paper.

For internal security teams, AppSec functions, vulnerability management programmes, GRC owners, and CISOs, the KEV catalog is the answer to the question every prioritisation framework eventually asks: which of the thousands of CVEs published each year are actually being used. The catalog is not a control framework like NIST CSF 2.0, ISO 27001, or CIS Controls; it is a curated catalog plus a federal directive plus a published timeline. The framework value is in the structural discipline the catalog enforces and the cross-walk into every major cybersecurity regime operators already read against.

This page covers the BOD 22-01 mandate, the inclusion criteria, the catalog structure, the cross-walk to NIST CSF 2.0, ISO 27001, SOC 2, PCI DSS, NIS2, DORA, and CIS Controls, the audit evidence an internal KEV programme runs against, and where the catalog sits next to CVSS, EPSS, NVD, SSVC, vendor advisories, and the wider vulnerability intelligence regime. The page assumes a reader who is operating a vulnerability management programme and wants the catalog read structurally rather than as a list of CVEs.

Inclusion criteria the catalog enforces

CISA publishes explicit inclusion criteria the catalog enforces. The criteria deliberately keep the list short, defensible, and prioritisation-grade. Every entry has been seen used; programmes that read the inclusion criteria as the operating contract get a small queue rather than a long, ambiguous list.

Assigned CVE identifier

A vulnerability enters the KEV catalog only after a CVE identifier is assigned through a CNA. CISA does not maintain a parallel identifier scheme; entries inherit the CVE record, the NVD enrichment, the CWE classification, and the CPE applicability. Programmes that read the catalog in conjunction with NVD treat the KEV entry as the curated subset and the NVD record as the structural reference. Pre-CVE issues, vendor advisories that never reached CNA assignment, and proof-of-concept findings without CVE coverage do not enter the catalog.

Reliable evidence of in-the-wild exploitation

CISA explicitly requires reliable evidence that the vulnerability has been exploited in real attack activity. The evidence threshold deliberately excludes proof-of-concept exploits, theoretical attack chains, and researcher demonstrations. The published criteria distinguish between observation of exploitation (the bar that KEV requires) and observation of scanning, theorising, or speculative weaponisation (the bar that KEV does not consider sufficient). The discipline of the inclusion criterion is what gives the catalog its prioritisation grade: every entry has been seen used.

Clear remediation action available

CISA only adds a CVE to the catalog when a clear remediation action exists: a vendor-supplied update, a documented mitigation, or an end-of-life recommendation that names the upgrade path. Entries without an actionable response do not enter the catalog because the BOD 22-01 mandate is a remediation directive, not a notification directive. The Required Action field on each entry is the operating contract the published timeline reads against.

Continuous catalog maintenance

The catalog is curated continuously. CISA adds entries when new in-the-wild exploitation is observed, sometimes multiple entries per week, with occasional bursts of additions after major incidents (Log4Shell, MOVEit, the Microsoft Exchange chain, Citrix Bleed, and similar events). Entries do not typically get de-listed; the catalog grows over time. Programmes that ingest the JSON feed on a daily cadence detect new additions before the published due dates compound into firefighting.

BOD 22-01 mandate and scope

Binding Operational Directive 22-01 is the structural authority behind the KEV catalog. The directive is binding for federal civilian executive branch (FCEB) agencies and explicitly recommended as best practice for everyone else. For non-FCEB programmes operating in regulated sectors, the published timelines have become the audit-defensible reference point because no comparable public mandate carries equivalent specificity. The six structural points below name what the directive actually requires.

  • Issued 3 November 2021 by the Cybersecurity and Infrastructure Security Agency under the authority granted by 44 USC 3553 and 6 USC 659. The directive is binding for federal civilian executive branch (FCEB) agencies and explicitly recommended as best practice for all other organisations.
  • Establishes the KEV catalog as the authoritative federal-civilian vulnerability remediation prioritisation list. The directive replaces the prior practice of FCEB agencies prioritising against CVSS scores alone, on the rationale that CVSS measures impact but not exploitation likelihood and that an exploitation-confirmed signal is the more defensible prioritisation input.
  • Requires FCEB agencies to remediate KEV entries within the published due dates. For new entries, the due date is typically 14 days after addition to the catalog. For entries added before BOD 22-01 issuance, the directive set a six-month due date from issuance. The published due date per entry is the FCEB compliance reference and the audit-defensible reference point for non-FCEB programmes.
  • Requires FCEB agencies to establish a process for ongoing KEV catalog review, automated detection where supported, and remediation tracking. The directive treats KEV review as a recurring operational discipline rather than a one-time exercise, with the process required to operate continuously against the published feed.
  • Requires FCEB agencies to report progress to CISA through the CDM (Continuous Diagnostics and Mitigation) Agency Dashboard and to address inability to remediate within the due date through a documented exception process. The reporting obligation makes the operating record the audit artefact rather than the assertion.
  • For non-FCEB programmes, BOD 22-01 carries the status of strongly recommended voluntary baseline. Most US federal-adjacent partners (state, local, tribal, and territorial governments, contractors, critical infrastructure operators, and many private-sector organisations that operate under sector-specific guidance) treat the published timelines as the audit-defensible reference point because no comparable public mandate has equivalent specificity.

Catalog structure and feed cadence

The catalog is published at the CISA website and at a machine-readable JSON endpoint plus a CSV feed. Each entry carries the fields below. Programmes that ingest the JSON feed on a daily cadence catch new additions before the published due dates compound into firefighting; programmes that read the catalog only at audit time discover the operating posture has been reactive rather than continuous.

  • CVE identifier: The assigned CVE record the catalog entry references. The CVE record is the join key to NVD enrichment, vendor advisories, and CPE applicability resolution. Programmes that ingest the catalog through the JSON feed read the CVE field as the primary key.
  • Vendor or project: The vendor or project that owns the affected product. The vendor field carries the upstream patching responsibility and the customer-facing advisory the remediation action references.
  • Product: The affected product name. Where multiple products from one vendor are affected by the same CVE, the catalog typically carries a single entry with the product list rather than multiple entries; the per-product applicability is read from the underlying CVE and NVD record.
  • Vulnerability name: A short human-readable name the catalog assigns for the entry. The vulnerability name supports readability in the catalog and is the label most leadership-side communication references.
  • Date added: The date CISA added the entry to the catalog. The date added drives the due date calculation under BOD 22-01 (typically 14 days after the date added for entries added recently).
  • Short description: A short description of the vulnerability and the context of the in-the-wild use. The description frequently references the vendor advisory and the observed campaign context, which is what makes the entry actionable in the operating record.
  • Required action: The remediation action CISA names. The action is typically apply the vendor update, follow a published mitigation, or follow vendor-published end-of-life guidance. Programmes read the required action as the operating contract per entry rather than improvising the remediation path.
  • Due date: The date by which FCEB agencies must complete the required action. For non-FCEB programmes, the due date is the audit-defensible reference point against which the per-entry mitigation status is read.
  • Known ransomware campaign use: A flag indicating whether CISA has observed the vulnerability used in ransomware campaigns. The flag was added to the published feed in 2023 and provides an additional within-KEV prioritisation axis for programmes that read ransomware-active entries as higher-priority within the existing KEV queue.
  • Notes: A free-text notes field that carries additional context per entry (specific campaign references, mitigation nuance, end-of-life caveats). Programmes that operate KEV at scale read the notes field as part of the per-entry triage.

KEV next to CVSS, EPSS, NVD, and SSVC

KEV is one input in the vulnerability intelligence stack, not a replacement for the rest. The defensible operating queue reads four signals together: KEV as the binary exploitation gate, EPSS as the broader probability signal, CVSS as the severity-of-impact ranking, NVD as the CVE-and-CWE structural reference. Programmes that read KEV alone produce a tight queue but miss high-EPSS CVEs that have not yet landed on KEV; programmes that read CVSS alone produce a wide queue with no exploitation evidence; the four-signal read produces the defensible operating queue.

KEV vs CVSS

CVSS measures the potential severity of a vulnerability if exploited (the impact axis). KEV measures whether the vulnerability has been exploited in the wild (the exploitation axis). The two answer different questions and read together rather than against each other. A CVSS 9.8 critical that is not on KEV may still warrant prioritisation on impact alone; a CVSS 6.5 medium that is on KEV warrants prioritisation on exploitation evidence regardless of impact score. The defensible operating queue reads both signals: KEV as the exploitation gate and CVSS as the impact ranking inside the gated queue.

KEV vs EPSS

EPSS (Exploit Prediction Scoring System) publishes a probability-of-exploitation-within-30-days score across the entire CVE population, updated daily. KEV is the curated, evidence-anchored set of CVEs already confirmed exploited. EPSS is the predictive signal for what is likely to be exploited; KEV is the confirmation signal for what has been exploited. Programmes that read EPSS as the leading edge and KEV as the trailing edge produce a queue that catches high-EPSS CVEs before they hit KEV and continues to prioritise KEV entries after the EPSS score has stabilised.

KEV vs NVD

NVD (National Vulnerability Database) carries the CVE record, the CVSS base score, the CWE classification, the CPE applicability, and the reference list. The KEV catalog is a curated subset of NVD entries flagged with the exploitation evidence. Programmes that operate the two together use NVD as the structural reference per CVE and KEV as the per-CVE exploitation flag. The NVD-to-KEV join is the CVE identifier; there is no separate KEV identifier scheme.

KEV vs SSVC

SSVC (Stakeholder-Specific Vulnerability Categorization) is the decision-tree prioritisation methodology CISA publishes for programmes that want a structured decision model. SSVC reads Exploitation, Automatable, Technical Impact, and Mission and Wellbeing axes; KEV is one of the inputs to the Exploitation axis. Programmes that adopt SSVC use KEV as the strongest Exploitation signal feeding the decision tree, with EPSS and CVSS feeding the other axes. SSVC and KEV are complementary rather than competing.

KEV vs vendor security advisories

Vendor security advisories are the source of truth for affected products, patches, and mitigations. KEV references the affected vendor and product but does not replace the advisory; the Required Action field typically points at the vendor advisory or update KB. Programmes operating a KEV programme also ingest vendor advisories from their estate (Microsoft MSRC, Cisco PSIRT, Oracle CPU, VMware advisories, Apache notices, etc.) so the patch deployment evidence reads against the vendor source rather than the catalog summary.

KEV vs threat intelligence feeds

Commercial and open-source threat intelligence feeds publish indicators of compromise, adversary tactics, and exploitation observations across a broader signal landscape than KEV. KEV is the CISA-curated, publicly available, free, exploitation-confirmed CVE subset. Programmes that operate threat intelligence platforms read KEV as one of multiple exploitation-evidence sources and use the additional feed coverage for sector-specific or geography-specific intelligence the catalog does not aim to cover.

A practical KEV programme adoption pattern

The catalog is designed to be operated continuously rather than reviewed periodically. The cadence below is the operating pattern most KEV programmes converge on when the catalog is treated as a feed rather than a snapshot. The cycle compounds: each step inherits structure from the prior step, so the audit pack at the end of the cycle is the residue of the operating work rather than a separate compilation.

  1. 1Establish the daily catalog ingestion cadence. Pull the published JSON feed (catalog-of-known-exploited-vulnerabilities.json) on a daily schedule. Capture the new additions per day, the new ransomware-campaign-use flags, and the due-date schedule. The daily cadence catches catalog growth before the FCEB due-date pressure compounds into firefighting and gives non-FCEB programmes the same operating posture the directive expects of federal agencies.
  2. 2Match each catalog entry against the operating estate. Run authenticated scanning, external scanning, code scanning, and asset inventory queries to surface the affected vendor and product combinations from the catalog against the operating estate. The affected-or-not classification per entry is the input to the queue; entries that do not match the estate carry a no-applicability record so the audit conversation includes the catalog-wide read rather than only the matched subset.
  3. 3Calibrate the per-entry remediation timeline against the published due date. For FCEB-aligned programmes, the published due date is the operating contract. For non-FCEB programmes, the published due date is the audit-defensible reference point; programmes that adopt the FCEB cadence treat each entry as a 14-day remediation commitment, programmes that adopt a longer cadence document the policy decision and the rationale (sector practice, vendor patch availability, change-window constraints). The policy decision sits on the operating record.
  4. 4Tier the within-KEV prioritisation by ransomware-campaign-use, EPSS score, and asset criticality. Within the KEV queue, the ransomware-campaign-use flag, the EPSS score, and the asset criticality of the affected systems produce the within-queue ordering. Programmes that read KEV as a flat queue miss the within-queue prioritisation the catalog metadata supports; programmes that tier the queue produce a defensible operating order that survives leadership scrutiny.
  5. 5Operate the exception register against the published timeline. Entries that cannot be remediated within the timeline (vendor patch unavailable, change-window constraints, end-of-life systems with planned decommissioning, compensating-control posture) enter a structured exception register with the documented compensating control, the named risk owner, the timeline for the structural fix, and the review cadence. Exceptions are a programme reality; what makes them defensible is the structural record rather than the absence of one.
  6. 6Produce the audit evidence as a side effect of the operating cadence. The catalog ingestion log, the per-entry applicability classification, the dated remediation evidence, the exception register, and the leadership reporting cadence read together as the BOD 22-01-aligned evidence pack. The same pack reads against the ISO 27001 A.8.8 control, the SOC 2 CC7.1 and CC7.2 criteria, the PCI DSS 6.3.3 and 11.4 requirements, the NIS2 Article 21 measures, the DORA Article 9 framework, and the CIS Controls Safeguards. The audit pack is the residue of the operating work rather than a separate compilation.

Failure modes a KEV programme tends to surface

The catalog is forgiving on the choice of tooling, the per-entry tier-up rule, and the prioritisation order within the queue. It is unforgiving about a small number of patterns that turn the KEV programme cosmetic rather than operational. The patterns below recur across KEV adoptions and are the ones that erode the year-over-year continuity the audit read expects.

  • Treating the catalog as a snapshot rather than a feed. Programmes that ingest the catalog quarterly or annually miss new additions for weeks at a time and discover the published due dates have already passed when the next review runs. The catalog is a continuously updated feed; the ingestion cadence has to match.
  • Reading the catalog as a flat queue. KEV entries vary on the ransomware-campaign-use flag, the EPSS score, the affected-asset criticality, and the available remediation path. Programmes that work the queue in date-added order miss the within-queue prioritisation the catalog metadata supports and the operating posture loses defensibility under leadership scrutiny.
  • Conflating KEV with CVSS-critical. Programmes that treat KEV as a synonym for CVSS-critical produce a queue that misses CVSS-medium entries with confirmed exploitation evidence and over-prioritises CVSS-critical entries without exploitation evidence. The two signals are complementary, not interchangeable.
  • No record of not-applicable entries. Programmes that only document the matched entries cannot answer the audit question on whether the catalog has been read against the operating estate or only against the visible subset. The not-applicable record is the structural evidence that the catalog review is comprehensive rather than partial.
  • Unstructured exception handling. Entries past the published due date that are documented as "exception" with no compensating control, no risk owner, and no timeline produce a backlog of undefended exceptions that the audit reads as a process failure. The exception register is the discipline that turns the operating reality into defensible evidence.
  • Treating KEV as the entire prioritisation programme. KEV is one input in the vulnerability intelligence stack, not the whole programme. Programmes that work only the KEV queue and stop produce a defensible posture against confirmed-exploitation CVEs and a blind spot against high-EPSS CVEs that have not yet landed on KEV, internal threat intelligence that flags sector-specific exposure, and severity-driven CVEs that have not been seen exploited but carry catastrophic impact. The four-signal read produces the defensible operating queue.
  • Leadership reporting that names KEV without producing the evidence. Programmes that include KEV programme status in the leadership deck without the supporting structural record (ingestion log, per-entry classification, dated remediation evidence, exception register) produce a narrative posture that survives one audit cycle and erodes in subsequent cycles when the underlying record is asked for.

Evidence a KEV programme produces

The KEV evidence pack reads well when it is built as a side effect of the operating work rather than reconstructed at audit time. The minimum set below maps to the records that examiners, sector regulators, and audit committees most often read against, and the same artefacts feed parallel reads under BOD 22-01, ISO 27001, SOC 2, PCI DSS, NIS2, DORA, and CIS Controls when the underlying record is structured.

  • Catalog ingestion log. A timestamped record of each pull of the published JSON feed, the per-pull catalog delta, and the resulting new entries surfaced. The ingestion log is the structural evidence that the catalog review is continuous rather than a one-off exercise; the audit read against BOD 22-01 process discipline reads this log directly.
  • Per-entry applicability classification. Per-KEV-entry record of the affected vendor and product, the scan or asset inventory query that surfaced the applicability decision, and the per-asset finding records the entry generated. The applicability classification covers both matched and not-applicable entries so the catalog-wide read is documented rather than implied.
  • Per-finding KEV tag and CVSS calibration. Each per-asset finding the catalog produces carries a KEV tag, the CVE identifier, the CVSS 3.1 vector and score, the EPSS score where available, the asset criticality, and the ransomware-campaign-use flag. The structured per-finding record is what makes the queue queryable and the leadership reporting numerical rather than narrative.
  • Dated remediation evidence per entry. For each per-asset finding the catalog generated, the dated remediation evidence (patch applied, configuration change deployed, system decommissioned, version upgrade confirmed) with the verification method (retest scan, configuration check, change-record reference) and the per-asset closure timestamp. The dated evidence is the BOD 22-01 due-date compliance record.
  • Exception register with compensating controls. Entries that did not meet the published timeline enter a structured exception record with the rationale, the compensating control, the named risk owner, the timeline for the structural fix, the review cadence, and the leadership endorsement where the exception exceeds policy authority. The exception register is the structural answer to the audit question on entries past the due date.
  • Leadership reporting cadence. The recurring (typically monthly) leadership-side report on KEV programme status: catalog size, applicable entries, remediated entries, exception entries, overdue entries, ransomware-flagged entries, and the trend across the prior reporting cycles. The reporting cadence makes the KEV programme a leadership-visible operating discipline rather than a queue buried in a vulnerability dashboard.
  • Cross-framework evidence pack. The same per-entry record exported as the BOD 22-01 evidence pack, the ISO 27001 A.8.8 evidence pack, the SOC 2 CC7.1 evidence pack, the PCI DSS 6.3.3 evidence pack, the NIS2 Article 21 evidence pack, the DORA Article 9 evidence pack, and the CIS Controls 7 evidence pack. The cross-framework export is what stops programmes rebuilding the same evidence multiple times per audit cycle.

How the KEV catalog relates to adjacent regimes

The KEV catalog sits in a dense regulatory and framework neighbourhood. The relationships below are the ones programmes encounter most often when they read the KEV catalog against the rest of the cybersecurity baseline regime. The relationships matter because programmes that operate each regime in isolation rebuild the same evidence multiple times per cycle.

KEV vs CISA CPGs

The CISA Cybersecurity Performance Goals (CPGs) are a voluntary, prioritised cybersecurity baseline. CPGs Goal 2.O explicitly names KEV catalog mitigation as the operating discipline the IDENTIFY function expects. KEV is a single-input catalog; the CPGs are a 38-goal baseline that includes the KEV mitigation goal among many others. Programmes that operate the CPGs read the KEV programme as the operating record for Goal 2.O; programmes that operate only the KEV programme cover Goal 2.O cleanly but are not running the full CPG baseline.

KEV vs NIST CSF 2.0

NIST CSF 2.0 is the broader cybersecurity outcome framework with six functions and 22 categories. KEV is one input in the IDENTIFY function (ID.RA Risk Assessment, especially ID.RA-08 vulnerability response). Programmes adopting CSF 2.0 use KEV as the structured exploitation-evidence input feeding the IDENTIFY function and the GOVERN-defined risk appetite (GV.RM) that defines the per-entry remediation timeline policy.

KEV vs ISO 27001:2022

ISO 27001:2022 Annex A 8.8 (Management of technical vulnerabilities) reads against a KEV-tracking discipline as a defensible operating control. The ISO 27001 audit reads the catalog ingestion record, the per-entry classification, the dated remediation evidence, and the exception register as the operating evidence for the A.8.8 control. Programmes that hold the same record under both regimes avoid maintaining parallel evidence packs.

KEV vs SOC 2

SOC 2 Trust Services Criteria CC7.1 (Detection of events) and CC7.2 (Response to events) read the KEV programme as the structured response cadence the criterion expects. The SOC 2 audit reads the same operating record the BOD 22-01 evidence pack carries: catalog ingestion log, per-entry classification, dated remediation evidence, exception register, leadership reporting cadence. The cross-framework cross-walk is direct.

KEV vs PCI DSS 4.0

PCI DSS 4.0 Requirement 6.3.3 (vulnerabilities ranked and patched on a published timeline) and Requirement 11.4 (continuous monitoring) read against a KEV-tracking discipline at the cardholder data environment scope. The PCI DSS audit reads the per-CDE-asset KEV evidence as the structured input to the 6.3.3 prioritisation discipline and the 11.4 monitoring cadence.

KEV vs NIS2 and DORA

NIS2 Article 21 (cybersecurity risk-management measures) and Article 23 (reporting obligations) and DORA Article 9 (ICT risk management framework) and Article 17 (ICT-related incident management) read the KEV programme as a structured part of the operational risk-management posture for essential and important entities (NIS2) and financial entities (DORA). The European regimes recognise KEV implicitly through the structural risk-management requirement; the operating record the BOD 22-01 evidence pack produces satisfies the framework-anchored evidence read in both regimes.

KEV vs CIS Controls v8.1

CIS Controls v8.1 Control 7 (Continuous Vulnerability Management) reads the KEV programme as the structured exploitation-evidence input to the Safeguards 7.5 (Perform Automated Vulnerability Scans of Internal Enterprise Assets), 7.6 (Perform Automated Vulnerability Scans of Externally-Exposed Enterprise Assets), and 7.7 (Remediate Detected Vulnerabilities). The Safeguards read the per-entry record as the operating evidence rather than the assertion.

Where SecPortal fits in a KEV programme

SecPortal is the operating layer for the KEV cycle, not a replacement for the CISA publication or for the catalog itself. The platform handles the KEV-side workstreams (per-entry applicability classification, per-finding KEV tagging, per-entry remediation tracking, exception register, leadership reporting) so the per-entry record stays structured rather than reconstructed at audit time. The same workspace that hosts the engagement record hosts the external scanning, authenticated DAST, code scanning, and pentest evidence the per-entry applicability resolution depends on, so the line from catalog entry to per-asset remediation evidence stays traceable. The catalog ingestion itself is yours to run; SecPortal holds the operating record once the catalog has been read against the estate.

  • Findings management with CVSS 3.1 scoring, CWE tags, and structured per-finding fields that carry the KEV tag, the CVE identifier, the EPSS score where ingested, the affected asset reference, the ransomware-campaign-use flag, and the per-entry remediation status. The structured per-finding record is what makes the catalog operatable rather than a CSV import.
  • Bulk finding import from Nessus, Burp Suite, OWASP ZAP, Semgrep, and CSV-source feeds with CVE-aware column mapping so the catalog-side join is structural rather than manual. The bulk import pathway is how the existing scanner estate (not just the SecPortal-native scanning) participates in the KEV programme.
  • External scanning across 16 modules and authenticated DAST with credential storage, feeding the perimeter and authenticated-web surfaces of the operating estate so the per-KEV-entry applicability read against the estate is continuous rather than periodic.
  • Code scanning (SAST and SCA via Semgrep on connected GitHub, GitLab, and Bitbucket OAuth) so the first-party and dependency surfaces of the operating estate feed the per-CVE applicability resolution alongside the operational scanning.
  • Scheduled scans (daily, weekly, biweekly, monthly) that establish the recurring scanning cadence the per-KEV-entry applicability resolution depends on so the operating record reflects the live state of the estate rather than a stale snapshot.
  • Continuous monitoring that pairs the cadence with the trend and regression record so the KEV programme reads as a continuous operating discipline rather than a series of one-off scans.
  • Finding overrides with an eight-field exception decision (rationale, compensating control, named owner, expiry, review cadence, scope, approver, evidence attachment) so the exception register against the published KEV due date is structural rather than free-text.
  • Retesting workflows paired retest-to-original-finding so the per-KEV-entry remediation evidence carries a dated verification record rather than an attestation.
  • Activity log with CSV export (30-day, 90-day, or 365-day retention by plan) capturing every state change to a finding, an engagement, a scan, an exception, and a configuration so the catalog ingestion cadence and the per-entry lifecycle is reconstructable from the operating record.
  • Compliance tracking across 21 frameworks (ISO 27001, SOC 2, PCI DSS, NIST CSF 2.0, NIS2, DORA, CIS Controls, and the rest) so the same per-entry record reads as the BOD 22-01 evidence pack, the ISO 27001 A.8.8 evidence pack, the SOC 2 CC7.1 and CC7.2 evidence pack, the PCI DSS 6.3.3 and 11.4 evidence pack, the NIS2 Article 21 evidence pack, and the DORA Article 9 evidence pack without rebuilding the underlying data per audit.
  • AI report generation that turns the operating record into a board-ready KEV programme status report, a per-cycle remediation evidence narrative, and a leadership-side risk summary without rewriting the underlying record.

The IDENTIFY-side reading the KEV catalog expects against the operating estate connects to named workflow records on the workspace. The vulnerability prioritisation workflow translates the KEV exploitation signal and the CVSS-plus-EPSS severity into the per-finding queue the catalog drives. The vulnerability SLA management workflow carries the timeline discipline the published KEV due date reads against. The vulnerability acceptance and exception management workflow records the structured exception register for KEV entries past the published timeline with the compensating control and the named risk owner. The remediation tracking workflow carries the per-asset dated remediation evidence the BOD 22-01 audit pack reads against.

For internal teams running the KEV programme, the internal security teams workspace bundles the platform with the engagement structure the audit cadence reads against. For vulnerability management functions operating the catalog queue at scale, the vulnerability management teams workspace covers the lifecycle work that produces the operational signal the per-entry remediation evidence reads against. For CISOs and security leaders carrying the leadership-side cadence, the CISOs and security leaders workspace covers the program-level reporting model that sits on top of the KEV operating record.

For deeper operational reading on the disciplines the KEV catalog reads against, the CISA KEV catalog vulnerability management guide covers the operational rollout pattern programmes use to stand up the catalog ingestion, the per-entry tagging, and the leadership reporting cadence over a six-week window. The vulnerability intelligence operating model covers how KEV combines with EPSS, NVD, vendor advisories, and threat reporting into one written decision rule the per-finding queue reads against. The CISA Cybersecurity Performance Goals framework page covers Goal 2.O (Mitigation of Known Exploited Vulnerabilities) and the broader prioritised baseline KEV sits inside. The EPSS score explained guide covers the predictive exploitation-probability signal that pairs with KEV in the four-signal read. The SSVC categorisation guide covers the CISA-published decision-tree prioritisation methodology KEV feeds as the strongest Exploitation axis input. The vulnerability management program scorecard scores programme maturity across governance, detection, prioritisation, remediation, and verification with KEV-aligned scoring on the prioritisation axis.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Inclusion criteria the catalog enforces

CISA publishes three explicit inclusion criteria the catalog enforces. A CVE enters the catalog only when the vulnerability has an assigned CVE ID, reliable evidence of in-the-wild exploitation exists, and a clear remediation action is available (a vendor-supplied update, a documented mitigation, or an end-of-life recommendation). The catalog deliberately excludes vulnerabilities that have been theorised or proof-of-concept demonstrated but not observed in attack telemetry, which is what keeps the list short, defensible, and prioritisation-grade. Programmes that read the inclusion criteria as the operating contract end up with a small queue rather than a long, ambiguous list.

BOD 22-01 mandate and scope

BOD 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities) was issued by CISA on 3 November 2021 and applies to federal civilian executive branch (FCEB) agencies. The directive requires agencies to remediate KEV entries within timelines CISA publishes per entry (typically 14 days for entries added with a recent due date, longer for entries added earlier), to establish processes for KEV review and tracking, and to report progress to CISA. The directive is binding for FCEB agencies; for private sector organisations, CISA explicitly recommends the same posture as voluntary best practice and most US federal-adjacent partners (state, local, tribal, territorial, contractors, and critical infrastructure operators) treat the published timelines as the audit-defensible reference point.

Catalog structure and feed cadence

The catalog is published at cisa.gov/known-exploited-vulnerabilities-catalog and at a machine-readable JSON endpoint (catalog-of-known-exploited-vulnerabilities.json) plus a CSV feed. Each entry carries the CVE identifier, the vendor and product, the vulnerability name, the date added, a short description, the required action, the due date, and a notes field that frequently references ransomware campaign use. The catalog is updated continuously when CISA observes new in-the-wild exploitation, with multiple additions per week typical and occasional bursts after major incidents. Programmes that ingest the JSON feed on a daily cadence catch new additions before the FCEB due date pressure compounds.

KEV next to CVSS, EPSS, and NVD

KEV is one input in the vulnerability intelligence stack, not a replacement for the rest. NVD carries the CVE record, the CVSS base score, the CWE classification, and the CPE applicability. EPSS publishes a probability-of-exploitation score across the entire CVE population. CISA KEV is the curated, evidence-anchored subset confirmed in-the-wild. A defensible operating model reads the four together: KEV as the binary exploitation signal, EPSS as the broader probability signal, CVSS as the severity-of-impact signal, NVD as the CVE-and-CWE reference. Programmes that read KEV alone produce a tight queue but miss the EPSS-high CVEs that have not yet landed on KEV; programmes that read CVSS alone produce a wide queue with no exploitation evidence; the four-signal read produces the defensible operating queue.

KEV in the NIST CSF 2.0 cross-walk

NIST CSF 2.0 does not name the KEV catalog directly, but the IDENTIFY function (ID.RA Risk Assessment, especially ID.RA-08 vulnerability response and ID.RA-01 inventory of vulnerabilities) and the PROTECT function (PR.PS Platform Security, especially PR.PS-02 software update management) read directly against a KEV-tracking discipline. The structural place a KEV programme lives in a CSF 2.0 Profile is the GOVERN-defined risk appetite (GV.RM) determining the remediation timeline policy, the IDENTIFY-side tracking against the published catalog, the PROTECT-side patch deployment, and the DETECT-side continuous monitoring confirming the patch landed. The mapping is not implicit; it is the structural relationship CISA CPGs goal 2.O makes explicit.

KEV in ISO 27001 and SOC 2 audit reads

ISO 27001:2022 Annex A 8.8 (Management of technical vulnerabilities) and 8.16 (Monitoring activities) read against a KEV-tracking discipline as a defensible operating control. SOC 2 Trust Services Criteria CC7.1 (Detection of events) and CC7.2 (Response to events) read the KEV programme as the structured response cadence the criterion expects. Auditors that have seen a KEV programme run typically ask for the catalog ingestion record, the per-KEV-entry status (mitigated, exception-with-compensating-control, not applicable), the dated remediation evidence per entry, and the audit-grade exception register for entries that cannot meet the published timeline. The audit evidence is structural rather than narrative.

KEV in PCI DSS, NIS2, and DORA reads

PCI DSS 4.0 Requirement 6.3.3 (vulnerabilities ranked and patched on a published timeline) and Requirement 11.4 (continuous monitoring) read against a KEV-tracking discipline at the cardholder data environment scope. NIS2 Article 21 (cybersecurity risk-management measures) and Article 23 (reporting obligations) read the KEV programme as a structured part of the operational risk-management posture for essential and important entities. DORA Article 9 (ICT risk management framework) and Article 17 (ICT-related incident management) read the KEV programme as one of the named operating controls in the broader ICT risk regime financial entities operate against. The framework-anchored read is direct in all three regimes.

Related features

Vulnerability management software that tracks every finding

Compliance tracking without a full GRC platform

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Monitor continuously catch regressions early

Finding overrides that survive every scan cycle

Verify fixes and track reopens on the same finding record

Bulk finding import bring your scanner data with you

Every action recorded across the workspace

AI-powered reports in seconds, not days

Scheduled scans on a real, audit-grade cadence

Run a KEV-aligned vulnerability programme on one defensible record

Hold the catalog ingestion log, the per-KEV-entry findings, the remediation evidence, the exception register with compensating controls, the framework cross-walk, and the leadership cadence on one workspace, then produce the same evidence across BOD 22-01, NIST CSF 2.0, ISO 27001, SOC 2, PCI DSS, NIS2, DORA, and CIS Controls. Start free.

Get Started Free

No credit card required. Free plan available forever.