Every organization that runs software faces the same problem: far more security flaws are published than any team can fix at once. This article explains how the US Cybersecurity and Infrastructure Security Agency (CISA) separates flaws that are being used in attacks from those that are merely possible, and how a directive issued in June 2026 turns that into deadlines for federal agencies.
Why patching everything at once is not realistic
Public software flaws are tracked with CVE identifiers, short labels such as “CVE-2026-xxxx” that let defenders, vendors and researchers refer to the same problem. A CVE entry says a flaw exists. It does not say that anyone is using it, how easily it can be reached, or how much damage it would allow.
Severity scores help, but a high score describes how bad a flaw could be in the abstract, not whether attackers are going after it this week. A team that sorts only by score can spend weeks on flaws nobody exploits while a lower-rated one that criminals are actively using sits in the queue. Risk-based vulnerability management tries to fix that by adding evidence of real-world use and the context of the affected system.
What is the Known Exploited Vulnerabilities catalog?
The Known Exploited Vulnerabilities (KEV) catalog is CISA’s public list of flaws with reliable evidence of exploitation in the wild, meaning use against real systems rather than in a lab. CISA describes it as the authoritative source for such vulnerabilities and says organizations should use it as an input when prioritizing fixes.
According to CISA, a flaw is added only when it meets three tests:
| Test | What CISA says it requires |
|---|---|
| A CVE ID | The flaw must already have a CVE identifier. |
| Active exploitation | There must be reliable evidence of attempted or successful exploitation. Scanning, security research and proof-of-concept code alone do not count, and neither does mere exploitability. |
| A clear fix | A defined remediation exists, such as a vendor update. If a product is end-of-life or cannot be updated, CISA says it should be removed from networks. Workarounds are treated as temporary. |
The third test matters. A flaw with no fix and no clear action cannot be assigned a meaningful deadline, so it does not qualify, however dangerous it may be.
Anyone can nominate an actively exploited flaw that is not yet listed, through a form on CISA’s site. The catalog is also published in machine-readable formats, which lets scanners and ticketing systems consume it automatically.
How big is the list, and how fast does it move?
As of October 23, 2026, the catalog page showed 1,754 entries. On the first page of results, entries had been added between October 8 and October 20, 2026, which suggests a steady flow of additions rather than occasional bursts. Most of those first-page entries carried a due date three days after they were added, and two entries added on October 20 had due dates of October 23 (three days) and November 3 (14 days).
The same page flags whether an entry requires forensic triage under the new directive. Of the 20 entries on the first page, 14 did, according to the page as read for this article. None of those 20 was marked as known to be used in ransomware campaigns; the field read “Unknown,” which means unconfirmed rather than ruled out.
These are snapshots of a live list, so counts and dates will have changed by the time you read this.
What does BOD 26-04 change?
A binding operational directive is a compulsory instruction CISA issues to federal civilian executive branch agencies. On June 10, 2026, CISA issued Binding Operational Directive (BOD) 26-04, “Prioritizing Security Updates Based on Risk.” It supersedes and revokes two earlier directives: BOD 19-02, on internet-accessible systems (April 29, 2019), and BOD 22-01, which created the KEV catalog (November 3, 2021). CISA says the KEV criteria carry over.
In CISA’s words, the aim is to prioritize high-risk vulnerabilities for timely action and to defer action on low-risk ones. That second half is notable. A rule that explicitly lets some flaws wait is a statement that perfect coverage is not the goal.
The directive covers agency assets in any federal information system, including systems run by another party on an agency’s behalf. Agencies must inventory systems hosted in third-party environments, including those under the federal cloud authorization program FedRAMP. Contractors are generally excluded unless their contract says otherwise, though agencies must review those contracts. National security systems and certain defense and intelligence systems are outside its scope.
Which four factors decide how fast a fix is due?
The directive sets remediation timelines, in calendar days, using four questions:
- Asset exposure: Is the vulnerable system publicly exposed to the internet?
- KEV status: Is the flaw on the KEV catalog?
- Exploit automation: Can an attacker automate every step needed to exploit it?
- Technical impact: Does exploitation give the attacker partial or total control of the system?
CISA says it publishes the KEV status, exploit automation and technical impact values for each CVE, largely through its Vulnrichment program, while agencies judge exposure using CISA’s internet exposure guidance.
The combination of answers maps to a deadline in a table in the directive. That table is published as an image on CISA’s page, and the day counts for each combination could not be confirmed from the text, so they are not listed here. The text does say that the most urgent categories require remediation or mitigation within three days, followed by forensic triage, and that some lower-risk categories are handled under “fix on system upgrade,” meaning the next scheduled major upgrade or rebuild.
Worked example: how one change alters a deadline
Consider two otherwise identical flaws in the same server software. In the first, the server sits on the open internet. In the second, an agency has moved it behind internal access controls. The directive says timelines are dynamic and that removing an asset from the internet changes its exposure value and can lengthen its deadline. Conversely, if CISA later adds the flaw to KEV, the deadline can shorten. The clock starts on the earlier of two events: CISA adding the CVE to KEV, or the agency identifying the flaw on an asset and updating its reporting dashboard.
Why forensic triage is part of the deadline
For the most urgent entries, patching is not treated as the end of the job. If a flaw was being exploited before a fix was applied, an attacker may already have gained a foothold that survives the update. The directive therefore requires agencies to remediate or mitigate within three days and then triage the asset to determine whether it was compromised, following CISA’s forensic triage guidance.
This echoes advice for every organization. Closing the door matters, but so does checking whether someone has already walked through it. The explainer on how ransomware attacks unfold describes how attackers often use a single exposed system as a starting point and then move quietly inside a network.
What is the compliance timeline?
CISA set the directive’s requirements in phases:
| Phase | Deadline | Main requirement |
|---|---|---|
| One | Effective immediately | Update policies, monitor KEV additions and mitigate per KEV timelines, report KEV status through the federal monitoring dashboard, and attest public-facing addresses quarterly. |
| Two | Within 60 days (about August 9, 2026) | Update vulnerability management processes to address CVE and KEV data. |
| Three | Within 180 days (about December 7, 2026) | Meet the full remediation timelines, tag all externally reachable assets, and report all IP addresses, including private ranges. |
The dates are counted from June 10, 2026: 60 days later is August 9, and 180 days later is December 7. The third phase, then, is roughly six weeks away. CISA also says it will reassess the timelines once per fiscal year.
Does this apply to anyone outside the federal government?
Legally, no. The directive binds federal civilian agencies, and it does not directly bind contractors, businesses or consumers. But the KEV catalog itself is public, and CISA recommends that all organizations use it. Many security teams treat a KEV listing as a signal to move a fix to the front of the queue, whatever sector they are in.
A practical reading for a small organization looks like this:
- Know what is exposed to the internet, since exposure is one of the biggest drivers of urgency.
- Check the KEV list against software you run, especially for remote-access tools, firewalls, VPNs and file-transfer products.
- Treat a listing as a reason to patch quickly and to look for signs of earlier compromise.
- Keep sign-in defenses strong in case a flaw is used to steal credentials; the guide to multi-factor authentication methods covers which approaches hold up best.
What remains uncertain?
Several limits are worth keeping in mind. The KEV catalog records only exploitation that has been reliably reported, so a flaw’s absence does not prove it is safe. Exploit automation and technical impact values are assessments, and they can be revised. The effects of the directive’s full timelines will not be clear until Phase III takes hold, and CISA has not, in the pages reviewed, published results showing how agencies perform against them. Whether a leaner, risk-ranked approach reduces breaches more than broad patching is an open empirical question.
A shift from counting flaws to ranking them
The KEV catalog and BOD 26-04 reflect a simple idea: attention is finite, so spend it where attackers are demonstrably active and where a compromise would cost the most. For federal agencies that is now a rule with deadlines. For everyone else it is a free, public signal that can sharpen decisions about which update to install first.
This article offers general information and is not a substitute for professional security advice.
Sources: Cybersecurity and Infrastructure Security Agency
