The CISA Known Exploited Vulnerabilities Catalog requires you to patch exploited flaws within 120 days of their addition to the list. This deadline applies regardless of when you detected the issue. It is a federal requirement for US agencies but serves as a global risk benchmark. Prioritise assets based on exposure and exploitability scores to meet this target.
What is the CISA Known Exploited Vulnerabilities deadline?
The CISA Known Exploited Vulnerabilities Catalog mandates remediation within 120 days of the vulnerability’s publication date. This fixed timeline replaces vague advisory periods with a strict operational deadline. The agency publishes new entries regularly, often weekly, meaning your backlog grows constantly. You must track the specific date each item enters the catalog. Failure to patch within this window exposes your infrastructure to known attack vectors. The deadline does not pause for holidays, maintenance windows or staffing shortages. It is a continuous obligation that requires constant monitoring.
Does the 120-day clock start when I find the flaw?
No, the clock starts when CISA adds the item to the public catalog, not when your scanners detect it. This distinction creates a hidden cost for organisations with slow detection cycles. If you discover a vulnerability six months after publication, you are already non-compliant. The requirement assumes proactive inventory management rather than reactive fixing. You cannot claim ignorance as a defence against exploitation. Your security operations centre must align its scanning frequency with the catalog update rhythm. Delaying discovery only shrinks your remediation window further.
How does EPSS affect KEV prioritisation?
The EPSS score estimates the probability that a vulnerability will be exploited in the wild. While CISA mandates patching all listed items within 120 days, EPSS helps you order that work. A high EPSS score indicates active exploitation, demanding immediate attention before lower-scoring items. You should not treat all KEV entries as equal risk. Combining KEV status with EPSS data allows you to focus resources on likely threats. This approach prevents patching fatigue by highlighting the most dangerous flaws first. It bridges the gap between regulatory compliance and practical risk reduction.
| Vulnerability Attribute | Impact on Remediation Timeline | Priority Level |
|---|---|---|
| CISA KEV Status | Mandatory 120-day limit | Critical |
| High EPSS Score | Immediate exploitation likely | Highest |
| Out-of-Support Software | Patching impossible | Requires Workaround |
| Low EPSS Score | Theoretical exploitation risk | Scheduled |
What if the vendor no longer supports the software?
You cannot patch software that has reached end-of-life, yet the 120-day clock still ticks. This edge case forces you to implement compensating controls instead of updates. Network segmentation isolates the vulnerable system from critical assets. Application whitelisting prevents unauthorised code execution on the host. You must document these controls clearly to demonstrate risk acceptance. Simply ignoring the flaw leaves you exposed to automated scanning bots. Compensating controls degrade over time as workarounds are forgotten or bypassed. Regular reviews of these legacy systems are necessary to maintain security.
How do I track due dates across multiple systems?
Manual tracking fails when managing thousands of assets with diverse software stacks. You need an automated asset inventory linked to vulnerability data. Integrate your scanning tools with a central database that flags KEV status. Set alerts for items approaching their 60-day and 90-day marks. This proactive notification system prevents last-minute panic patching. Ensure your inventory includes shadow IT and forgotten servers. Blind spots in your asset list become blind spots in your compliance. Automation reduces human error in date calculations significantly.
See also: What Is EPSS Score: Predicting Exploit Risk for Faster Patching · How a Software Bill of Materials Works: The Mechanism and Limits
Does firmware fall under the same deadline?
Yes, firmware vulnerabilities included in the catalog are subject to the same 120-day rule. Firmware updates are often riskier and slower to deploy than OS patches. You must validate firmware updates in a lab environment before production rollout. The 120-day limit assumes you have tested the update and confirmed stability. Do not let testing delays push you past the compliance deadline. Plan your update cycles to include firmware checks alongside software patches. Firmware flaws can persist for years if ignored, making them prime targets for attackers.
How does this relate to software bill of materials?
A software bill of materials (SBOM) provides the visibility needed to track KEV compliance. Without an SBOM, you cannot know which third-party libraries contain exploited flaws. The SBOM lists every component in your application stack. You match these components against the CISA catalog to identify risks. This process reveals hidden dependencies that scanners might miss. Maintaining an accurate SBOM is a prerequisite for effective KEV management. It transforms unknown unknowns into known risks that can be scheduled. See the guide on software bill of materials (SBOM) for creation methods.
What happens if I miss the deadline?
For US federal agencies, missing the deadline triggers mandatory reporting and remediation plans. For private sector organisations, it increases liability and breach risk. There is no automatic penalty for private companies, but insurers may deny claims. Auditors will note the gap during security assessments. Your organisation accepts the risk of exploitation by missing the window. Attackers use automated tools to exploit known KEV items systematically. Delaying patching makes your network a low-hanging fruit for cybercriminals. Consistent misses indicate a broken security process.
How do I handle false positives in KEV data?
Scanners often report vulnerabilities that do not apply to your specific configuration. You must validate each finding before counting it toward your workload. False positives waste resources and create alert fatigue. Confirm the software version and active features before prioritising. Exclude confirmed false positives from your compliance tracking. Document your exclusion rationale for audit purposes. This validation step ensures you focus on genuine risks. It prevents unnecessary downtime from patching unaffected systems.
Does KEV coverage include cloud configurations?
Yes, misconfigured cloud services that are actively exploited appear in the catalog. Cloud misconfigurations are treated as vulnerabilities when attackers can exploit them. You must treat cloud settings like software versions in your inventory. Regular audits of cloud permissions and storage settings are necessary. The 120-day rule applies to fixing these configuration errors. Ignoring cloud KEV items leaves your data exposed to public theft. See the guide on secure configuration baselines for cloud best practices. Also review OAuth misconfigurations for identity-related risks.
How do I automate the KEV workflow?
Automation connects your asset inventory, vulnerability scanner and ticketing system. Scripts should pull the latest KEV list and compare it against your assets. The system creates tickets for items approaching their deadline. Prioritisation logic uses EPSS scores to rank the tickets. This workflow reduces manual effort and ensures consistency. Test your automation regularly to catch data sync errors. Keep human oversight for complex remediation decisions. Automation handles the volume, while humans handle the nuance.
What is the long-term strategy for KEV compliance?
Long-term compliance requires shifting left in your development lifecycle. Integrate KEV checks into your CI/CD pipelines to catch flaws early. See the guide on GitHub Actions workflow injection for pipeline security. Prevent vulnerable components from entering production in the first place. Maintain a culture of continuous patching rather than periodic sweeps. Review your asset inventory quarterly to remove decommissioned systems. Align your security metrics with the 120-day target. Consistent adherence reduces overall risk posture over time.
Key takeaways
- The 120-day clock starts on the catalog publication date, not your internal discovery date.
- EPSS scores help prioritise which KEV items pose the highest immediate risk to your environment.
- Automated patching fails when software is out of vendor support, requiring compensating controls.
The 120-day deadline is fixed from the catalog publication date, not your detection date. Audit your asset inventory immediately to identify any items already past their compliance window.
Frequently asked questions
Can I extend the 120-day deadline for critical systems?
No, the CISA catalog does not offer extensions. You must implement compensating controls like network isolation if patching would cause downtime. Document these controls to justify the risk.
Does the KEV catalog include zero-day vulnerabilities?
Only after they are publicly disclosed and confirmed as exploited. Zero-days remain secret until disclosure, at which point they may be added to the catalog quickly.
How often does CISA update the catalog?
Updates occur frequently, often weekly. You should monitor the catalog daily to catch new entries early and start your 120-day clock promptly.
Are open-source libraries included in the KEV list?
Yes, widely used open-source components with known exploits are included. You must track these dependencies using an SBOM to ensure compliance.
How this guide was produced: written by the RedTeam Log editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
