CISA KEV vs vendor advisories: how to use both

How the sources complement each other

Two sources, two decisions

CISA’s Known Exploited Vulnerabilities catalog and vendor security advisories answer different questions. KEV identifies vulnerabilities with reliable evidence of exploitation in the wild. Vendor advisories explain security issues in particular products, including affected releases and available remedies. Use KEV to inform urgency and vendor documentation to determine applicability and action. Monitoring only KEV can miss relevant updates; monitoring only vendor notices can obscure an important exploitation signal. Neither source by itself establishes what is installed, exposed, or compromised in your environment.

What KEV inclusion actually means

CISA’s published catalog criteria require a CVE identifier, reliable evidence of exploitation in the wild, and clear remediation guidance. The BOD 26-04 implementation FAQ also identifies significant risk to US government information systems. This is different from a high severity score or a researcher demonstrating that exploitation is possible. Inclusion is evidence about exploitation somewhere, not proof that your organization runs an affected product or has been attacked. An entry’s addition date is not necessarily the date exploitation began. Historical exploitation can support inclusion; a listing does not measure current attack frequency.

Why vendor advisories remain necessary

Vendor advisories cover a broader purpose than known exploitation: communicating product vulnerabilities and the releases, configurations, or components to which they apply. A notice may cover several CVEs, while one CVE can appear in notices for multiple products. Mozilla’s Firefox ESR advisory index, for example, organizes notices by fixed release. Individual Mozilla advisories name products, impact, fixed versions, and vulnerability details. These fields help correlate records, but do not establish the state of a local deployment. Read the specific notice and its revisions rather than relying on a headline alone.

Match reported products and versions to inventory

Treat a matching product name as a lead requiring confirmation. Compare the reported affected product, edition, release branch, package build, platform, and relevant configuration with your inventory. Check whether a component is bundled into another vendor’s product and whether that supplier provides its own update. A distributor may backport a fix without adopting the upstream version number, so use its package guidance rather than a simple numeric comparison. Record confirmed affected, confirmed not affected, or unresolved with supporting documentation. A missing inventory record is uncertainty, not evidence of absence.

Read due dates within the federal directive’s scope

On June 10, 2026, CISA issued BOD 26-04, explicitly revoking and superseding BOD 22-01 and BOD 19-02. It applies to Federal Civilian Executive Branch agency assets in federal information systems, including systems operated on an agency’s behalf, with statutory exclusions for national security and certain defense or intelligence systems. Contractors are not automatically covered unless the governing procurement contract directs it; agencies must review contracts. These are not universal legal deadlines for every business. BOD 26-04 has immediate, 60-day, and 180-day phases. As of this guide’s November 3 review, the 180-day phase is still ahead. Consult the directive and implementation guidance for the applicable phase and asset-specific response requirements.

Do not flatten asset-specific timing into one date

BOD 26-04’s risk-based timeline uses asset exposure, KEV status, exploit automation, and technical impact. Its implementation guidance says agencies make the final exposure determination asset by asset; a catalog due date is not a substitute for that assessment. The directive’s phased rollout also matters when deciding which requirements apply. Preserve the catalog date, the applicable directive phase, and the basis for the response target in separate fields. Where forensic triage is required, distinguish that obligation from the guidance’s recommended step-by-step timing. Avoid copying an agency requirement into a private organization’s policy without identifying it as an internal decision.

Separate mitigation from a permanent fix

A vendor fix usually means installing a corrected release or package for the affected branch. A mitigation instead reduces an exploitation path, for example through a documented configuration change or removal of exposure, and may leave the underlying defect present. Follow the exact vendor and applicable CISA instructions: an improvised workaround is not automatically an accepted mitigation. Track temporary controls, their limitations, an owner, and the follow-up update. Where guidance requires discontinuing unsupported software or additional response actions, a patch ticket alone does not capture the whole requirement.

Absence from KEV does not mean safe

A vulnerability outside KEV can still affect an exposed, important system. Exploitation may be unreported, evidence may not yet meet the catalog’s criteria, or another inclusion condition may be unmet. Do not interpret absence as a negative security finding. Continue reviewing relevant vendor advisories and prioritize using affectedness, exposure, business impact, exploitation information, and available remedies. Likewise, a vendor status such as under investigation should remain unresolved. Confirmed not affected applies to the documented product and circumstances, not automatically to other editions or components sharing a name.

A historical example of vendor specificity

Mozilla’s MFSA 2024-51, announced October 9, 2024, describes CVE-2024-9680 and reports exploitation in the wild. Its Fixed in list names Firefox 131.0.2, Firefox ESR 128.3.1, and Firefox ESR 115.16.1. The same vulnerability therefore had different fixed versions for different release lines. Those are historical examples, never current patch targets. An operator reviewing that notice would first identify the installed channel and branch, then use the matching remedy and applicable exploitation guidance. Reading the advisory does not prove compromise of an individual browser; that question requires local investigation.

Keep a defensible monitoring record

For each relevant notice, retain the CVE identifiers, advisory URL and revision, inventory evidence, affectedness decision, KEV status, required action, owner, and target date. Recheck when either source changes, because product ranges and remediation instructions can be revised. After deployment, confirm the installed build and any required restart or configuration step using your normal management records. Distinguish update completion from investigation of possible prior compromise. A useful outcome is a traceable decision supported by current documentation and local evidence, rather than an alert count presented as proof of security.

Primary sources and methodology

Documentation-based analysis of primary CISA and vendor publications reviewed on 2026-11-03. The directive succession and scope were checked against BOD 26-04 and the revoked BOD 22-01 page; catalog criteria and interpretation were checked against current CISA guidance. The Mozilla example reproduces historical advisory fields. No vulnerability scan, attack experiment, or deployment validation was performed. Local affectedness and organization-specific obligations require separate evidence.

• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 22-01: historical directive; revoked and superseded
• CISA BOD 26-04: successor directive and federal civilian scope
• CISA: current KEV inclusion criteria
• CISA BOD 26-04: implementation guidance and KEV interpretation
• Red Hat: backporting security fixes and version-number limitations
• Mozilla MFSA 2024-51: historical multi-branch remediation example
• Mozilla security advisories for Firefox ESR