CISA launched a new nomination form in late 2024 that allows researchers, vendors, and industry partners to submit vulnerabilities directly to the Known Exploited Vulnerabilities (KEV) catalog. Since its creation in November 2021, CISA has controlled what gets added. Now they're opening the gates.
Your security team needs to decide: do you participate in this expanded reporting process, or stick with your current vulnerability management workflow?
Why Consider Submitting to the KEV Catalog?
The KEV catalog drives patching priorities across federal agencies through Binding Operational Directive 22-01. Many private-sector teams also use it as a guide for remediation timelines. When a CVE lands on the KEV list, it signals active exploitation—not just theoretical risk.
Previously, you could only report exploitation evidence through informal channels. Now you can submit directly through a structured form. Submissions must meet three criteria: an assigned CVE number, confirmed evidence of exploitation, and available remediation guidance.
The question is whether your team should actively participate in this process or remain a passive consumer of KEV data.
Benefits of Active Participation
Unique Exploitation Insights: Your honeypots, EDR telemetry, and incident response work may reveal attacks before they hit mainstream security news. If you're catching exploitation attempts against a CVE not yet on the KEV list, submitting it accelerates protection for the entire community.
Enhanced Documentation: The submission criteria—CVE assignment, exploitation evidence, remediation guidance—align with what your team should already track for internal vulnerability management. Preparing a KEV submission creates artifacts useful for executive reporting and compliance documentation.
Influence on Patching Priorities: If your submissions consistently make it onto the KEV catalog, you're shaping what the security community prioritizes. This is crucial when convincing business stakeholders to approve emergency patching windows. "This is on CISA's KEV list" carries more weight than "we think this is important."
Compliance Alignment: While PCI DSS v4.0.1 doesn't explicitly mandate KEV catalog monitoring, the focus on "known exploited vulnerabilities" is increasing. Teams working toward SOC 2 or NIST CSF alignment often cite KEV adherence as evidence of proactive vulnerability management.
Reasons to Remain a Consumer
Limited Resources: Your vulnerability management program may already be stretched. Triaging the NIST National Vulnerability Database feed, correlating with asset inventory, and coordinating patches across dev teams consumes your week. Adding KEV submission workflows could divert resources from direct remediation work.
Legal and Liability Concerns: Submitting a vulnerability with "confirmed exploitation" documents that your environment was targeted or breached. Your legal team will question if this creates disclosure obligations, affects cyber insurance claims, or complicates incident reporting timelines under regulations like GDPR.
Uncertain Curation Speed: The nomination form is new. You don't know how long CISA takes to review submissions, what their acceptance rate is, or how they handle disagreements about exploitation evidence. If your submission sits in a queue for weeks, you've added process without accelerating protection.
Risk of False Positives: Submitting a CVE claiming active exploitation that turns out to be a penetration test or red team activity could waste agency resources and damage your team's reputation. The bar for "confirmed exploitation" is subjective, and you're making a public claim when you submit.
Practical Approach for Security Teams
Most security teams are taking a hybrid approach. They're not building KEV submission into their standard workflow but are flagging edge cases where submission makes sense:
Niche Software Exploitation: When you catch active exploitation against a vendor product that serves a small market segment, CISA may not have visibility. Your submission could trigger catalog inclusion and vendor notification.
Post-Incident Documentation: After forensic work for an incident response, the marginal cost of preparing a KEV submission drops significantly. You've already gathered the exploitation evidence and documented remediation steps.
Zero-Day Discoveries: If your team discovers a zero-day through research or catches one in the wild before public disclosure, the KEV submission process aligns with coordinated vulnerability disclosure practices.
Conclusion: Establish a Submission Threshold
Your team should establish a threshold for KEV submissions, not a blanket policy. Create a decision tree: if you observe exploitation attempts in production (not dev/test environments), and the CVE isn't already on the KEV catalog, and you have packet captures or logs showing the exploitation attempt, then prepare a submission. Assign this to whoever owns your vulnerability disclosure process.
Don't submit based on scanner findings alone. Don't submit because a CVE has a high CVSS score. Don't submit because a vendor published a blog post about exploitation—CISA already monitors those sources.
The value of the KEV catalog depends on signal quality. If every security team submits every CVE their tools flag, the catalog becomes noise. But if teams with genuine exploitation visibility stay silent, the catalog misses critical threats.
Your participation should be targeted and evidence-based. When you have something unique to contribute, submit it. Otherwise, focus on patching the vulnerabilities already on the list.
The nomination form is a tool, not an obligation. Use it when you have information that materially improves the community's threat awareness. Skip it when you'd just be adding administrative overhead to your already-constrained vulnerability management process.
