CISA KEV Catalog: A Practical Vulnerability Management Guide

What the CISA KEV Catalog Actually Is

The Known Exploited Vulnerabilities (KEV) catalog is a public list maintained by the United States Cybersecurity and Infrastructure Security Agency. CISA established the catalog in November 2021 alongside Binding Operational Directive (BOD) 22-01. The directive applied to Federal Civilian Executive Branch (FCEB) agencies, but the catalog itself is available to everyone, and most enterprise vulnerability management programmes now read it as a primary input regardless of whether they sit inside government.

The inclusion criteria are deliberately narrow. CISA adds a vulnerability to the catalog only when three conditions are met. The vulnerability has an assigned CVE identifier. There is reliable evidence that the vulnerability has been actively exploited in the wild, not just proof-of-concept code. There is a clear remediation action available, typically a vendor patch or a documented workaround. The narrow criteria are why KEV is a small list (typically a few thousand entries) rather than a comprehensive vulnerability database. Every entry on it earned its place through observed exploitation.

Each KEV entry carries a small set of fields: the CVE ID, the vendor and product, a vulnerability name, the date the vulnerability was added to the catalog, a short description, the required action, the due date for FCEB remediation, the date the action is required by, the notes, and (since May 2022) a flag indicating whether the vulnerability has been used in known ransomware campaigns. The full catalog is published as both a JSON document and a CSV file at the CISA KEV homepage. There is no rate-limited API key dance, no authentication, and no commercial licensing layer to navigate. The catalog is a public artefact.

What BOD 22-01 Actually Requires

BOD 22-01 is often misread as a generic deadline rule. It is not. The directive places three specific obligations on FCEB agencies, and the obligations are worth reading literally because most enterprise interpretations soften them in ways that erode the discipline.

The first obligation is review. FCEB agencies have to review and update internal vulnerability management procedures within sixty days of the directive issuance to align them to KEV-driven prioritisation. The obligation here is to the procedure, not just the patch list: KEV becomes a documented input to the programme.

The second obligation is remediation timing. FCEB agencies must remediate KEV-listed vulnerabilities by the due date assigned to that entry. For vulnerabilities added after BOD 22-01 was issued, the default timeline is two weeks for vulnerabilities with CVE assignment dates from 2021 onward, with extended deadlines for older entries. The actual due date is published per entry. The directive also expects a tracked exception mechanism for systems that cannot be patched in time, with named compensating controls.

The third obligation is reporting. Agencies report status to CISA through the Continuous Diagnostics and Mitigation (CDM) programme. For enterprises outside FCEB, reporting is internal: leadership read, compliance evidence, and audit-committee briefings. Either way, the evidence has to come from somewhere the work happens. The whole-programme alignment to KEV is the harder commitment than the patching cadence: programmes that align procedures to KEV inherit the evidence trail; programmes that just rush a patch on a hot CVE never produce a defensible record.

Why KEV Beats Pure CVSS for Prioritisation

CVSS 3.1 measures intrinsic technical severity. A high CVSS score means a vulnerability could, in theory, cause significant damage if exploited. That is useful, but it does not say anything about whether the vulnerability is being exploited today. Prioritising by CVSS alone produces queues where every Critical and High looks equally urgent, which is the same as having no priority at all. Internal VM teams who run on pure CVSS spend most of their week chasing the wrong thirty findings while the actual attack surface stays exposed.

KEV adds the missing axis: observed exploitation. Anything in KEV is being used by a real attacker against a real target. That is a different signal class from severity, and it should outrank severity in the queue. A KEV-listed Medium with a vendor patch available is a more urgent action than a Critical CVSS that has never been weaponised. Most enterprise programmes that move from CVSS-only prioritisation to KEV-anchored prioritisation report the same effect: the queue gets shorter and the work gets sharper.

For internal security leaders, the simplest defensible policy is a two-tier rule. KEV-listed vulnerabilities run on a tighter SLA than the rest of the queue, often two weeks for production-facing assets and one to two months for internal-only assets. Everything else runs on the standard policy SLA tied to severity, asset tier, and exposure. The two-tier rule is easy to explain to leadership, easy to audit, and easy to operate. Our vulnerability prioritisation workflow covers the full six-signal model (CVSS, EPSS, KEV, asset criticality, exposure, compensating controls) for programmes that want to go beyond the two-tier rule, the threat intelligence driven prioritisation workflow covers the operational pipeline that ingests KEV additions and other CTI signals into the queue with provenance, and our prioritisation framework guide covers the upstream theory.

KEV vs EPSS: Different Questions, Different Answers

EPSS, the Exploit Prediction Scoring System maintained by FIRST, estimates the probability that a vulnerability will be exploited in the wild over the next thirty days. EPSS scores update daily. They are derived from observed exploitation telemetry, vulnerability metadata, exposure signals, and weighted features. EPSS produces a percentile (0 to 100) and a probability (0 to 1) for almost every CVE in the ecosystem. It is a forward-looking signal.

KEV is a backward-looking signal. A KEV entry says exploitation has happened. EPSS says exploitation is likely. The two are complementary rather than redundant. A vulnerability can be in KEV with a moderate EPSS percentile (it has been exploited but exploitation is not currently widespread). A vulnerability can have a very high EPSS percentile but not yet be in KEV (the prediction is strong but observation has not crossed CISA's evidence threshold). The defensible policy uses both: KEV as a hard tier-up trigger, and EPSS as a tie-breaker among non-KEV findings to surface the next likely targets.

A working rule of thumb that keeps the queue calibrated is: KEV always wins, EPSS percentile above ninety promotes a non-KEV finding into the elevated tier, and EPSS percentile below ten lets a non-KEV severity-only finding stay on the standard timeline unless asset criticality or exposure overrides it. The exact thresholds belong in your policy, not in a vendor default. Calibrate them against observed remediation throughput and exception volume rather than against how busy the queue feels. Our EPSS score explained guide covers the probability vs percentile mechanics, defensible threshold choices, and the four-week rollout for adding EPSS to a programme that already runs on KEV.

Ingesting the KEV Catalog into Your Programme

The catalog is published as JSON and CSV at the public CISA KEV URL. Most programmes pull it on a daily schedule and reconcile it against findings on each run. There is no rate limit and no authentication, but CISA recommends caching responsibly and respecting the published update cadence. A daily pull is sufficient for almost every enterprise; some programmes pull twice a day during active mass-exploitation events (Log4Shell, MOVEit, Citrix Bleed, Ivanti Connect Secure) when the catalog can grow by multiple entries inside a single working week. When a new KEV entry against the deployed estate triggers an out-of-cycle response, run the work as a structured engagement using the zero-day and emergency vulnerability response workflow so the exposure assessment, the named-owner assignment, the verified closure, and the leadership briefing read off one record rather than across a hastily-created Slack channel and a war-room spreadsheet.

The reconciliation step matters more than the pull. Every finding that carries a CVE identifier should be checked against the latest KEV catalog and tagged in the operating record so the prioritisation workflow can read it as a queryable field. The check has to be re-run when the catalog updates as well as when scanners produce new findings, because a non-KEV finding from yesterday may become a KEV finding tomorrow without any change in the underlying scan output. Most programmes that run KEV reconciliation only at scan time miss the catalog-side updates entirely and end up reading a stale tag for weeks.

Watch the failure modes. Findings without a CVE identifier cannot be matched to KEV directly, which is a long tail in scanner output (configuration findings, weak header findings, custom application findings). Findings with multiple CVEs need to be matched against any of the listed CVEs, not just the first. Findings with vendor-specific identifiers (KB numbers, advisory IDs) need a translation layer because KEV uses CVE keys. Address these in the ingestion pipeline rather than at the priority decision, so the per-finding KEV tag is reliable when the queue manager reads it.

For programmes that operate a software bill of materials pipeline alongside their scanner stack, the SBOM-derived findings need the same KEV reconciliation treatment as scanner-led findings. Our SBOM guide covers how the SBOM walks into the same vulnerability sources, how each component-version pair becomes a CVE the KEV reconciliation tags, and how VEX assertions handle the false positives that the SBOM-derived queue surfaces.

KEV is keyed by CVE ID, which means the upstream CVE Numbering Authority programme is the producer side of every signal the catalog flags. A KEV entry only exists once a CNA has issued and published the CVE record; a CVE that is REJECTED or DISPUTED in the upstream record can produce confusing reads when it appears in scanner output that has not refreshed against the latest CVE List. Our CVE Numbering Authority explainer covers the CNA hierarchy, the CVE ID lifecycle, the ADP container CISA uses to attach KEV-related annotations directly to CVE records, and the failure modes that cause stale CVE references to show up in a KEV-aligned queue.

Setting KEV-Aligned Remediation SLAs

BOD 22-01 sets two-week deadlines for most post-2021 KEV entries with assigned actions. Enterprise programmes do not have to mirror the federal deadlines exactly, but they do have to set a deadline anchored to KEV inclusion if they want a defensible policy. The deadline conversation that surfaces in most leadership reviews is: how fast does the policy expect us to be, and what happens when we miss the window. Both parts have to live in the policy itself, not in a champion's memory.

Exceptions, Compensating Controls, and Risk Acceptance

A KEV entry that cannot be remediated inside the policy window is the hardest conversation a VM programme has. Sometimes the vendor has not shipped a patch yet, the patch breaks a downstream system, the affected component is on a frozen release train, the asset is a legacy system that cannot accept the change, or operational constraints prevent the maintenance window. None of these are valid reasons to leave the finding unhandled. They are reasons to document a decision and apply a compensating control.

The defensible discipline is straightforward. The asset owner submits an exception request with the reason, the proposed compensating control, the residual risk position, and a hard expiry date. A named approver at the right tier (security leadership for high-residual exceptions, asset owner's director for medium-residual) signs off, the exception is logged in the org-wide ledger, and the finding stays open with the exception attached so the programme can read both the deferral and the underlying KEV state. When the patch lands or the compensating control retires, the exception is closed and the finding either retires too or returns to the standard remediation queue.

Compensating controls for KEV entries have to be specific. A statement like "the asset is behind the WAF" is not a compensating control; it is a sentence. A working compensating control names the specific signature, rule, configuration change, network segment, or detection that mitigates the specific exploitation path. CISA's entry text is a starting point: most KEV entries describe the attack chain enough to reason about which controls actually break it. Document the reasoning in the exception, not just the conclusion.

For internal security and GRC teams, our vulnerability acceptance and exception management workflow covers the full per-decision and org-wide ledger discipline. The risk acceptance form template and the security exception register template are the per-decision and ledger artefacts the workflow produces. KEV-driven exceptions tend to be short-dated (often 30 to 90 days) compared to standard exceptions, because the underlying risk is actively being exploited and the window for the compensating control to hold is narrower.

Capturing Defensible KEV Audit Evidence

Auditors do not look for slogans about KEV alignment. They look for a reproducible record. Build the record as a side effect of doing the work, not as a separate compliance artefact, and the audit conversation collapses into a query against the live record rather than a multi-team scramble.

The minimum evidence set has six artefacts. The first is the per-finding KEV tag on the live record so an auditor can filter findings by KEV status. The second is the timestamped lifecycle of every KEV finding (detected, triaged, prioritised, assigned, remediated, retested, closed) with the named user who performed each transition. The third is the evidence file (patch confirmation screenshot, retest log, version output) attached to the engagement record. The fourth is the exception register entry for any KEV finding that missed the policy window, with the compensating control, residual risk, named approver, and expiry date. The fifth is the framework mapping (KEV inclusion typically maps to the implementation of NIST 800-53 RA-5, ISO 27001 Annex A 8.8, PCI DSS Requirement 6.3, SOC 2 CC7.1) so the same evidence pack works across multiple audits. The sixth is the periodic KEV reconciliation record showing that the catalog has been pulled and the operating record updated on the agreed cadence.

SecPortal's findings management feature tracks each finding with a CVSS 3.1 vector, owner, evidence, and remediation status, so the per-finding KEV tag is a queryable field on the same record the operator works from. The activity log keeps the timestamped chain of state changes by user across findings, engagements, scans, documents, comments, and team changes, with plan retention of 30, 90, or 365 days. The compliance tracking feature maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST and exports the evidence pack as CSV when the auditor asks for it. None of those features replace the GRC owner reading the evidence, but they make the evidence easy to produce on demand rather than reconstructing it after the fact.

Continuous KEV Coverage Through Scheduled Scans

KEV is a moving target. The catalog grows when CISA observes new exploitation, and the entries that apply to your estate change as new assets come online, as software is patched, and as configurations shift. A KEV programme that runs only on quarterly scans cannot keep up; the coverage gap between scans is exactly when the next exploited entry is added.

The discipline that holds is a scheduled cadence faster than the audit cycle and proportional to the asset tier. Internet-facing assets benefit from at least weekly external scanning paired with a biweekly authenticated scan; internal-facing assets often run on a monthly authenticated cadence; code scanning runs on every change to source via repository connections. The cadence is not the only discipline; the diff between runs is what surfaces new findings against the latest KEV state. A scan that produces only a list of current findings without comparison to the previous run hides the new-on-this-run signal that KEV alignment depends on.

SecPortal's continuous monitoring feature covers daily, weekly, biweekly, and monthly scheduled scans across external, authenticated, and code scanners with a scan diff endpoint that returns new, fixed, and unchanged findings between runs, so the new-this-run subset is queryable rather than reconstructed. Our scan scheduling and baseline cadence guide covers the asset-tier cadence model and the framework cadence floors (PCI DSS 11.3 quarterly plus change-triggered, ISO 27001 Annex A 8.8 risk-based, SOC 2 CC7.1 monitoring expectation) that the cadence has to clear.

KEV in the Reporting Cadence: Operator, Programme, Leadership

KEV state is a reporting metric across at least three audiences. The reads do not duplicate, but they are not the same view either. Build the cadence so each audience reads the slice they actually need from the same underlying record.

Common KEV Programme Failure Modes

Mapping KEV to Compliance Frameworks

KEV-driven prioritisation lines up with the language several frameworks already use, even when they do not name the catalog directly. Make the mapping explicit in the policy and the evidence pack stretches across multiple audits.

A Six-Week Rollout for an Internal Programme

For internal security teams adding KEV alignment to an existing VM programme, the rollout below has worked across several enterprise contexts. It is deliberately conservative: a programme that survives quietly is more valuable than a programme that launches loudly and stalls in the second month.

1. Week one: document the KEV ingestion source, the daily pull cadence, and the per-finding tagging rule. Update the existing prioritisation policy to include the two-tier KEV uplift (KEV always wins, EPSS percentile above 90 promotes non-KEV). Get sign-off from the security lead and the GRC lead.
2. Week two: wire the ingestion. Backfill KEV tags against the existing finding inventory using the most recent catalog. Surface the KEV-tagged subset in the operator queue. Identify the KEV findings that already exceed the new SLA and triage them as a one-time backlog clearance.
3. Week three: tighten the SLA. Deploy the new KEV-aligned remediation SLA (14 days internet-facing, 30 days internal-facing) for new KEV findings and for any KEV findings not already past the deadline. Update the exception register template to require named compensating controls for KEV deferrals, with hard expiry.
4. Week four: roll out the cadence. Schedule weekly external and biweekly authenticated scans on internet-facing assets if not already in place. Tie scan diff into the KEV reconciliation so new findings on the latest catalog surface inside the cadence rather than at quarter-end.
5. Week five: wire the reporting. Add the KEV closure rate, breach rate, and exception register health to the monthly programme review and the quarterly leadership read. Capture the framework mapping (NIST 800-53 RA-5/SI-2, ISO 27001 Annex A 8.8, PCI DSS 6.3, SOC 2 CC7.1) in the policy so the audit-evidence pack is portable.
6. Week six: review. Run a calibration pass on the first month of KEV closures, exception decisions, and SLA breaches. Tune the EPSS tie-breaker thresholds. Promote the policy from pilot to standard, and schedule the next quarterly recalibration.

Where the Programme Sits in the Wider Security Org

KEV-driven vulnerability management is one workflow inside a wider internal security organisation. It sits next to the daily operational discipline of the VM team, the engineering-side AppSec function, the GRC owner's evidence cadence, and the leadership reporting cadence the CISO produces.

For the find-track-fix-verify operator function, the workflow is the natural pairing with SecPortal for vulnerability management teams. For the CISO or security director sponsoring the programme, the SecPortal for CISOs page covers how KEV outcomes roll up into leadership reporting. For the GRC owner who has to translate KEV state into evidence, SecPortal for GRC and compliance teams covers the audit-side discipline. For the operations leader carrying the recurring SecOps cadence, SecPortal for security operations leaders covers the cadence that ties the operator queue to the leadership view.

Pair the programme with adjacent enterprise reading. The vulnerability management program guide covers the upstream and downstream workflow KEV plugs into. The CVSS scoring explained post covers the technical severity axis KEV is paired with. The vulnerability management program scorecard scores programme maturity across governance, detection, prioritisation, remediation, and verification. The security control drift research covers the wider GRC discipline KEV evidence sits inside.

Run Your KEV Programme on a Single Record

KEV alignment is mostly a recordkeeping problem in disguise. The catalog is small, the tier-up rule is simple, and the SLA is straightforward. What stops most programmes from getting clean KEV evidence is that the per-finding KEV tag, the lifecycle audit trail, the exception register, the framework mapping, and the leadership read all sit on different records, so producing the evidence pack means reconciling four or five sources at audit time. SecPortal is built around a single engagement record: findings management with CVSS calibration, the activity log for the timestamped chain of state changes across findings, engagements, scans, and team changes, compliance tracking with ISO 27001 / SOC 2 / Cyber Essentials / PCI DSS / NIST mappings and CSV export, continuous monitoring for the cadence, and AI-powered report generation when leadership wants the executive summary.

None of these features pull KEV automatically: the catalog is yours to ingest. What the platform does is keep the KEV tag, the lifecycle, the evidence, the exceptions, and the framework mapping on the same record so the audit conversation collapses into a query rather than a multi-team scramble.