Every organization has more software updates waiting than it can install today. In June 2026 the US cybersecurity agency CISA issued a new directive that tells federal agencies how to decide which updates come first, and the four questions it uses are just as useful for a ten-person company as for a government department.
What is BOD 26-04, and why does it matter beyond government?
CISA is the Cybersecurity and Infrastructure Security Agency, part of the US Department of Homeland Security. A Binding Operational Directive (BOD) is a compulsory instruction it issues to federal civilian agencies. According to CISA, BOD 26-04, titled “Prioritizing Security Updates Based on Risk,” was issued on June 10, 2026.
The directive applies to Federal Civilian Executive Branch agencies and the federal information systems they operate. CISA’s directive page is written for those agencies and does not set rules for private companies. National security systems and some systems run by defense and intelligence bodies are outside its scope, and contractors are generally excluded unless a contract says otherwise.
So why should a startup, an agency or a software vendor care? Because the directive shows how a national defender thinks about an old problem: when you cannot patch everything at once, patch by risk instead of by the order in which notices arrive. CISA’s Known Exploited Vulnerabilities (KEV) catalog page tells organizations in general to use the catalog “as an input to their vulnerability management prioritization framework.”
What did it replace?
BOD 26-04 supersedes and revokes two earlier directives, according to CISA:
- BOD 19-02, “Vulnerability Remediation Requirements for Internet-Accessible Systems,” dated April 29, 2019.
- BOD 22-01, “Reducing the Significant Risk of Known Exploited Vulnerabilities,” dated November 3, 2021.
The first focused on systems reachable from the internet. The second created the KEV catalog requirement. The new directive merges both ideas into a single decision model, so an agency no longer works from two separate clocks.
Which four questions decide how urgent a fix is?
The core of the directive is four factors. Each one answers a plain question about a specific flaw on a specific system.
| Factor | The question it asks |
|---|---|
| Asset exposure | Can untrusted parties reach the vulnerable system over public networks? |
| KEV status | Is the flaw listed in CISA’s catalog of vulnerabilities known to be exploited? |
| Exploit automation | Can an attacker automate every step needed to exploit it? |
| Technical impact | Does exploitation give partial or total control? |
A few terms need unpacking. A vulnerability is a flaw in software that an attacker can misuse. A CVE (Common Vulnerabilities and Exposures) identifier is the public reference number assigned to a specific flaw, such as CVE-2026-xxxxx. A patch or security update is the vendor’s fix.
On exposure, the directive defines a publicly exposed resource as one “accessible to unauthenticated or untrusted entities via public networks.” If any method of checking finds a system exposed, the value is set to yes.
On impact, CISA separates partial control from total control. Partial control includes limited control, information exposure, or a low opportunity for total control, and a denial-of-service attack (knocking a system offline) counts as partial. Total control means full control over the software’s behavior, including reliably revealing log-in credentials.
CISA says it publishes the exploit-automation assessment through its Vulnrichment Program, which adds metadata to CVE records.
How fast do the deadlines run?
The directive attaches a remediation timeline to each combination of the four factors, laid out in its Table 1. CISA’s page presents that table as an image, so the exact number of days for every combination is not reproduced here. The text does state several rules:
- Items marked “& forensic triage” must be remediated or mitigated within three days, and the agency must also perform forensic triage of the asset, meaning an early investigation into whether the system was already compromised.
- Some lower-risk combinations are marked “fix on system upgrade,” meaning the flaw is fixed the next time the asset receives a scheduled major upgrade or rebuild, unless conditions change.
- The clock starts when CISA adds the CVE to the KEV catalog, or when the agency itself identifies the vulnerability on an asset and updates its reporting dashboard, whichever comes first.
- Timelines are dynamic. Taking a system off the internet changes its exposure value and can lengthen its deadline, while a KEV listing shortens it.
- CISA reassesses the timelines once per fiscal year.
The point is not one deadline for everything. It is that the same flaw can be an emergency on a public server and a routine item on an internal one.
What is the phased rollout?
CISA sets three phases, counted from issuance:
- Phase I, effective immediately. Agencies review their vulnerability management policies, including roles, enforcement and reporting. They monitor KEV updates and mitigate according to KEV timelines, and they keep scanning and quarterly attestation of publicly exposed addresses and domains going.
- Phase II, within 60 days. Agencies update their processes to work from CVE database entries (or an equivalent service) and the KEV catalog.
- Phase III, within 180 days. Agencies remediate each vulnerability “as quickly as possible” and no later than the Table 1 timelines. They also continuously identify and tag internet-reachable assets with details such as organization, environment (production or development), exposure (public or internal) and asset type.
That last requirement hides a lesson. A team cannot prioritize by exposure if it does not know which of its assets face the internet. An accurate inventory is the unglamorous foundation under the whole model.
What does the KEV catalog look like in practice?
CISA describes the KEV catalog as the authoritative source of vulnerabilities that have been exploited in the wild, meaning attackers are using them against real targets. As of the catalog page’s most recent entries, dated October 28, 2026, CISA listed 1,762 results. Entries show a “Date Added” and a “Due Date,” and the page says anyone can nominate an actively exploited vulnerability that is not yet included. The catalog is available as CSV and JSON files, so it can feed into spreadsheets and scanners.
Entries also carry action text that tells stakeholders to apply vendor mitigations and to evaluate each asset’s internet exposure. On the same page, due dates vary from entry to entry. The page shows one flaw added on October 16, 2026 with a due date of October 19, and another added on October 28 with a due date of November 11. Gaps of that kind show the exposure and impact factors at work rather than a single fixed window.
How can a small team apply the same logic?
Nothing here requires government-scale tooling. A small team can translate the four factors into a short routine. The arithmetic below is illustrative, not drawn from CISA.
Worked example. A company has four pending updates:
| Update | Internet-facing? | On the KEV list? | Likely outcome if exploited |
|---|---|---|---|
| Web server library | Yes | Yes | Full control of the server |
| VPN appliance firmware | Yes | No | Service outage |
| Internal file server | No | No | Information exposure |
| Employee laptop browser | Yes (users browse the web) | Yes | Full control of the laptop |
A sensible order: the web server library first, because it is exposed, known to be exploited and gives total control. The laptop browser comes next, since it is also known to be exploited, and should be updated automatically wherever possible. The VPN firmware follows because exposure is high even without a KEV listing, and the internal file server can wait for its scheduled maintenance window. A team that wrote down those four answers would reach the same ranking in a few minutes.
Practical steps that follow from this:
- Keep a living list of systems and mark which face the internet.
- Subscribe to KEV additions, which CISA offers as email alerts.
- Turn on automatic updates for browsers and operating systems so routine fixes never queue up.
- Decide in advance who may approve an emergency patch outside the normal schedule.
- After patching a flaw that was already being exploited, check for signs of compromise, as the directive’s forensic triage rule suggests.
For related groundwork, see cybersecurity basics for small teams and the explanation of zero trust security for small teams. If your systems run mostly on rented infrastructure, what cloud computing means for everyday businesses covers who is responsible for patching what.
Does patching by risk mean ignoring everything else?
No. Risk-based does not mean risk-only. The directive’s “fix on system upgrade” category still schedules a fix; it simply stops treating every flaw as equally urgent. Low-priority items that are never revisited can become tomorrow’s exposed systems, because exposure and KEV status change. A flaw that sits quietly on an internal server can become urgent the day it appears in the catalog or the day the server is connected to the internet.
That is why the directive makes timelines dynamic and requires continuous tagging. Prioritization is a loop, not a one-time sort: re-check the four answers whenever a flaw’s status or a system’s role changes.
Patch by evidence, then keep the list honest
BOD 26-04 is a rule for federal agencies, but its logic travels well. Ask four questions of every flaw: is the system exposed, is the flaw known to be exploited, can the attack be automated, and how much control does an attacker gain. Pair that with a trustworthy inventory and a habit of rechecking, and the update backlog becomes a ranked list instead of a pile.
This article is general information about cybersecurity practice and is not legal, compliance or professional security advice.
Sources: Cybersecurity and Infrastructure Security Agency
