The vulnerability most likely to hurt you this week is rarely the one with the highest score. It is the one attackers are already using against systems like yours, on assets the internet can reach.

The U.S. federal government has now made that principle policy. On June 10, 2026, CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk. It gives federal agencies as little as three days to fix the most dangerous exploited flaws, and it sets deadlines by risk rather than by severity alone. The directive binds only federal civilian agencies, but its logic applies to every organization, from a ten-person firm to a national operator.

The problem with patching by score alone

Severity-only patching measures how bad a flaw could be, not how likely it is to be used against you. Most vulnerability programs sort findings by their CVSS score, the zero-to-ten severity rating published with most vulnerabilities. CVSS is valuable, but its base score describes the flaw in general. It says nothing about whether anyone is exploiting it, or whether the affected system is even reachable.

That gap creates three predictable failures:

• Effort goes to the wrong places. Teams spend scarce maintenance windows on high-scoring flaws in isolated systems while lower-scoring flaws on exposed devices wait.
• Everything looks urgent. When thousands of findings score "high" or "critical," the label stops guiding decisions, and staff burn out chasing volume.
• Leaders get the wrong metric. "We closed 2,000 vulnerabilities this quarter" sounds reassuring but says little about real exposure.

What risk-based prioritization means

Risk-based prioritization asks a better question: how likely is this flaw to hurt us, here, now? Four signals answer it, and all of them are freely available or within your control.

1. Known exploitation. CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of real-world exploitation. If a flaw is on the KEV, attackers are not speculating about it; they are using it.
2. Exploit likelihood. The Exploit Prediction Scoring System (EPSS), maintained by FIRST, estimates the probability that a published vulnerability will be exploited in the next 30 days. Scores are updated daily and are free through FIRST's data feed and API. EPSS helps rank the large majority of flaws that are not yet on the KEV.
3. Exposure. Can the affected system be reached from the internet? Firewalls, VPNs, remote-access gateways and email gateways face the internet by design, which is exactly why attackers target them.
4. Impact and criticality. What would an attacker gain: partial access or total control? And how important is the asset to operations, safety or sensitive data?

BOD 26-04 uses a closely related set of four variables for each asset and vulnerability pair: public exposure, KEV status, whether exploitation can be automated, and technical impact. Industry analyses describe the model as building on CISA's Stakeholder-Specific Vulnerability Categorization (SSVC), a decision model that weighs these factors instead of relying on a severity score alone. Severity still matters; it simply becomes one input rather than the deciding one.

The patch clock is getting shorter

The attacker, not the regulator, sets the real deadline. CISA has tied BOD 26-04 in part to a threat landscape in which AI-enabled tools help attackers find and exploit vulnerabilities faster, often by script against every exposed device on the internet at once.

The directive responds with graduated deadlines instead of one flat window:

• About three days for the worst combinations, such as exploited, automatable flaws on internet-facing systems. For the highest-risk cases, agencies must also perform forensic triage: checking whether they were already compromised, not just applying the patch.
• About two weeks for most other known-exploited vulnerabilities.
• Longer windows for lower-risk combinations, and deferral to the next system upgrade when none of the risk factors apply.

BOD 26-04 also revokes and replaces two earlier directives: BOD 22-01, which created the KEV catalog, and BOD 19-02, which governed internet-accessible systems. Agencies had to update their processes by August 2026 and must meet the new timelines by December 7, 2026.

In my professional judgment, this will not stay a federal-only standard. The KEV catalog itself became a common reference point for commercial vulnerability programs, insurers and auditors after BOD 22-01. I expect a similar path here, so a policy that says "we patch critical issues within 30 days" will increasingly look slow for exploited flaws on exposed systems.

A practical prioritization model

Any organization can adopt a four-tier model that mirrors the federal logic without its compliance burden. Work through the questions in order; the first "yes" sets the priority.

Two rules keep the model honest. First, re-score continuously: a vulnerability can jump from Routine to Emergency the day CISA adds it to the KEV. Second, document every exception. If a system cannot be patched in time, record who accepted the risk, which compensating control applies, and when the decision expires.

Putting it into practice

Start with three moves this month. Each has a version for small and mid-sized organizations (SMEs) and one for larger ones.

For governance alignment, this approach maps directly to the NIST Cybersecurity Framework 2.0. ID.RA-01 covers identifying and recording vulnerabilities, ID.RA-05 calls for using threats, vulnerabilities, likelihoods and impacts to prioritize risk response, and PR.PS-02 expects software to be maintained, replaced and removed commensurate with risk.

Measure what matters

Replace vulnerability counts with metrics that reflect real exposure:

• Open KEV items on internet-facing systems, and how long each has been open. This is the single best board-level indicator.
• Mean time to remediate by priority tier, compared with your target windows.
• Percentage of internet-facing assets with a named owner, as a measure of inventory quality.
• Open risk exceptions past their expiry date, as a measure of governance discipline.

The board question changes accordingly. Instead of asking "How many vulnerabilities do we have?", ask "How many known-exploited vulnerabilities sit on our internet-facing systems right now, and for how long?"

Sources

• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk (issued June 10, 2026; supersedes BOD 19-02 and BOD 22-01)
• CISA, BOD 26-04 Implementation Guidance
• CISA, Known Exploited Vulnerabilities Catalog
• FIRST, Exploit Prediction Scoring System (EPSS)
• NIST, Cybersecurity Framework 2.0 (CSWP 29)
• Tenable, CISA BOD 26-04 FAQ (tier structure and SSVC basis)
• Industrial Cyber, CISA BOD 26-04 directs agencies to prioritize exploited vulnerabilities (AI-enabled threat context)

That decision is about to become a legal obligation for a large share of U.S. critical-infrastructure organizations. On October 1, 2026, the final rule implementing the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) reached the White House for its last major review before publication. The reporting clocks themselves are already written into the law: 72 hours to report a covered cyber incident, and 24 hours to report a ransom payment. What remains open is the detail of who is covered and what counts.

My advice is simple: do not wait for the final text to do the work that every version of the rule will require. The organizations that meet a 72-hour deadline are the ones that settled their decision rights, reporting map and ransom position before the incident, not during it.

Where the rule stands

The final rule is in its last step before publication, and reporting is not yet mandatory. Here is what is established, and what is not.

The April 2024 proposal is the best guide to where the rule is heading, but it is not the final text. CISA estimated that the proposal could reach about 316,000 entities, using a size test plus sector-specific criteria, so smaller organizations in critical sectors should not assume they are out of scope. When the final rule is published, read the coverage tests and the incident definition first.

Why "reasonable belief" changes the job

The 72 hours do not start when the investigation is finished. They start when the organization reasonably believes a covered incident has occurred. In practice, the gap between "this looks bad" and "we understand the scope" is often several days, so the rule pulls a legal decision forward into the period of greatest uncertainty.

Consider a composite example. On a Saturday night, a managed detection provider flags unusual remote logins to a jump server that staff use to reach operational systems. By 1 a.m., the on-call engineer has confirmed that an account was misused and that files were staged for transfer. Operations are still running. Is this a reportable incident? At 1 a.m., nobody can know for certain.

In a well-governed organization, the engineer does not decide whether to report. The engineer escalates against a short, written threshold, and a named incident lead records a decision: "As of this time, we do, or do not yet, have a reasonable belief that a covered incident occurred, for these reasons." That timestamped entry is the most valuable record the organization will create that weekend. It anchors the clock if the answer is yes, and it documents good-faith reasoning if the answer is not yet.

The first report will also be incomplete, and that is expected. The proposed rule provided for supplemental reports as new information emerges. The goal at 72 hours is an accurate account of what is known, what is not yet known, and what is being done. Teams that wait for certainty are the teams that miss the deadline.

Where organizations fall short

In my experience with incident response and governance reviews, readiness for a short reporting clock breaks down in five predictable places:

1. Nobody owns the decision. The incident response plan says "notify leadership" but never says who decides that a legal clock has started, so the question passes between security, legal and communications for a day.
2. The playbook was written for a different regime. Many plans were built around data breach notification, which turns on exposed personal information. CIRCIA turns on operational and systemic impact. A playbook that only asks "was personal data exposed?" will miss the operational trigger.
3. Vendor contracts are silent. The proposed rule treated unauthorized access through a third party, such as a cloud or managed service provider, as a possible reportable impact. If a contract only requires notice "promptly," the vendor's pace may set your clock.
4. Reporting duties are scattered. One incident can trigger several obligations at once. In July 2026, the U.S. Government Accountability Office counted 117 cybersecurity regulations across 37 federal agencies, 80 of them with potentially duplicative reporting requirements. Without a single map, teams discover these duties one at a time, under pressure.
5. Evidence disappears. Logs roll over, and a well-meaning administrator rebuilds a server before anyone captures what happened. The proposed rule included a duty to preserve incident data, so recovery and preservation must be planned together.

Three safeguards to put in place now

None of these depend on the final wording of the rule, and each can start this month.

What boards should ask this quarter

The NIST Cybersecurity Framework 2.0 gives boards a useful vocabulary for this oversight. Its Govern function covers legal and regulatory obligations (GV.OC), roles and authorities (GV.RR), oversight (GV.OV) and supply chain risk (GV.SC). In my view, GV.RR, roles and authority, is where reporting readiness succeeds or fails. Three questions cover most of it:

1. Who decides that a reporting clock has started, and are they authorized to decide at 2 a.m. without convening a meeting?
2. Can management show us a single map of every reporting duty we would face after a serious incident, with deadlines?
3. What is our documented position on ransom payments, and who would file the report within 24 hours if a payment were ever made?

If management cannot answer all three clearly, the organization is not ready, whatever the final rule says.

If you are outside the United States

CIRCIA is a U.S. law, but short reporting clocks are now the international norm. The EU's NIS2 Directive requires an early warning within 24 hours of becoming aware of a significant incident and a fuller notification within 72 hours. The GDPR requires personal data breaches to be reported to the supervisory authority within 72 hours where feasible. In Ghana, the Cybersecurity Act, 2020 (Act 1038) requires owners of critical information infrastructure to report cyber incidents to the relevant CERT, within 24 hours. The three safeguards above apply under every one of these regimes, and organizations operating across borders should build one reporting map that covers them all.

Sources

• CISA, Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) (72-hour and 24-hour clocks; reporting not required until the final rule takes effect)
• OIRA, Pending EO 12866 Regulatory Review: CIRCIA Reporting Requirements, RIN 1670-AA04 (received October 1, 2026)
• Federal Register, CIRCIA Reporting Requirements proposed rule (April 4, 2024)
• Executive Order 12866, Regulatory Planning and Review (section 6(b)(2) review period)
• Covington & Burling, Inside Privacy: CISA Submits Final CIRCIA Rule for OMB Review (October 8, 2026)
• GAO-26-108606, Cybersecurity Regulations: Potentially Duplicative Reporting Requirements (July 22, 2026)
• NIST Cybersecurity Framework 2.0 (CSWP 29)
• NIS2 Directive, Article 23 (24-hour early warning, 72-hour notification)
• GDPR, Article 33 (72-hour breach notification)
• Cybersecurity Act, 2020 (Act 1038), Ghana
• Modern Ghana: Protection of Ghana's critical information infrastructure in the Cybersecurity Act (commentary on critical information infrastructure duties)