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.
A 9.8 on an internal test server may matter less this week than a 7.5 on your VPN gateway that criminals are already exploiting.
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.
- 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.
- 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.
- 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.
- 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.
| Priority | When it applies | Recommended target window | Extra step |
|---|---|---|---|
| 1 · Emergency | On the KEV, internet-facing, and gives an attacker significant control | 3 days, or isolate the system until fixed | Check for signs of compromise after patching |
| 2 · Urgent | On the KEV but not internet-facing, or a high EPSS score on an exposed system | 14 days | Confirm compensating controls while waiting |
| 3 · Planned | No exploitation evidence, but a high-severity flaw on a business-critical asset | Next maintenance cycle, 30 to 60 days | Track in the risk register |
| 4 · Routine | Low exploit likelihood, low exposure, limited impact | Normal update or upgrade cycle | Review if the KEV or EPSS status changes |
These windows are my recommended starting points for private organizations, not legal requirements. Set your own based on capacity and risk appetite, then write them into policy.
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.
| Action | SMEs | Larger organizations | Owner |
|---|---|---|---|
| Know your front door | List every internet-facing device and service (firewall, VPN, email gateway, website platform, remote-support tools) with make, model and who updates it. Ask your IT provider for this list in writing. | Reconcile the asset inventory against an external attack-surface scan and tag every asset as internet-facing or not. | IT lead or managed service provider; CISO for larger firms |
| Set a KEV trigger | Subscribe to CISA's free KEV alerts. Treat any match against your front-door list as an emergency. | Feed the KEV catalog and EPSS scores into your vulnerability management platform automatically, and write the tiered windows into policy. | Security operations |
| Patch, then check | After patching an exposed device, change admin passwords, review accounts for anything unfamiliar, and check logs. | Build compromise checks into the Emergency tier playbook, with evidence preservation and a clear escalation path to incident response. | Security operations and incident response |
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?"
The bottom line
Severity tells you how bad a flaw could be. Risk tells you how likely it is to hurt you now. Organizations that make that shift fix fewer things faster, spend less effort on noise, and give their leaders a truthful picture of exposure.
Know your front door. Set a KEV trigger. Patch, then check.
Need help building a risk-based vulnerability program? SenasoftConsult supports SMEs, public bodies and enterprises with vulnerability management policy design, risk assessments and board reporting.
Free one-page checklist
Get the Three Safeguards Checklist
Every step from this guide on one printable page, in two versions: one for small and mid-sized organizations, one for larger ones. Includes the NIST CSF 2.0 mapping and the one question to ask your board.
We'll email you the checklist and add you to Senasoft Insights, our monthly briefing. Unsubscribe any time by replying "unsubscribe". Privacy notice.
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)