Vulnerability Prioritization in 2026: EPSS, KEV and BOD 26-04

Most vulnerability queues are ordered by severity score, which is why they never stop growing. This guide shows how to base vulnerability prioritization on real exploitability, using exploit prediction scores, the Known Exploited Vulnerabilities catalog and asset exposure. In June 2026, the Cybersecurity and Infrastructure Security Agency (CISA) replaced its flat patch deadlines with a risk-based model, leaving severity-first patching behind.

‍

Why Severity Scores Create a Permanent Vulnerability Backlog

Ranking by CVSS score builds a queue no team can clear, because severity measures damage potential, not the likelihood of attack.

A scanner returns every High and Critical finding, and the team treats that list as the work queue. New findings then arrive faster than old ones close. When everything is critical, sequencing becomes arbitrary, and an actively exploited vulnerability can sit behind theoretical ones.

The data shows the model losing ground. The Verizon 2026 Data Breach Investigations Report found only 26% of CISA KEV vulnerabilities were fully remediated in 2025, down from 38% the year before. Median time to full remediation rose from 32 days to 43.

Risk-based vulnerability management is the alternative: rank work by exploitation evidence and real exposure, then fix in that order. Even at their best, organizations fix only 30% to 40% of KEV instances in the first week, so the question is which ones. That ordering is also what separates assessments that actually lead to remediation from reports nobody acts on. Prioritization is a capacity allocation problem, not a scoring problem.

‍

What Changed: CISA BOD 26-04 Replaced BOD 22-01

On 10 June 2026, CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," which supersedes and revokes both BOD 22-01 and BOD 19-02. CISA's stated reason is that attacker use of AI may further shrink the gap between a patch's release and its exploitation.

The directives it replaced set flat deadlines. BOD 19-02 gave critical internet-facing vulnerabilities 15 days, and BOD 22-01 gave every KEV entry a fixed deadline with no deferral.

BOD 26-04 prioritizes high-risk vulnerabilities and explicitly defers low-risk ones, which is what lets a backlog actually shrink. Deadlines now come from four questions, informed by CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) framework:

• Asset Exposure: is the vulnerable asset publicly exposed?
• KEV Status: is the CVE in the KEV catalog?
• Exploit Automation: can an adversary automate every step of exploitation?
• Technical Impact: does exploitation give partial or total control?

CISA publishes answers to the last three for every CVE ID through its Vulnrichment program, which makes the model usable outside government. Organizations answer the exposure question themselves, using CISA's Internet Exposure Reduction Guidance.

Three rules are easy to miss. Deadlines are dynamic: take an asset off the internet and its clock relaxes, while a new KEV listing tightens it. If any scan shows an asset is reachable by untrusted users over the internet, it counts as publicly exposed, wherever it sits. The clock starts at whichever comes first: CISA adding the CVE to the KEV catalog, or the organization finding the vulnerability on its own asset.

In CISA's initial analysis at one large civilian agency, only 1% of vulnerability instances landed in the three-day tier. Over 60% were deferred to the next system upgrade.

The directive binds US federal civilian executive branch agencies only. For UK and UAE organizations, its value is a published, defensible framework to point an auditor to.

‍

What Is the Difference Between CVSS, EPSS and KEV Scores?

CVSS scores how severe a vulnerability would be, EPSS predicts how likely it is to be exploited, and CISA KEV records that it already has been. They answer different questions, so they work together rather than competing. FIRST, which maintains both CVSS and EPSS, notes that the two are empirically uncorrelated.

CVSS (Common Vulnerability Scoring System)

CVSS measures severity, not risk. It rates how much damage a vulnerability could do on a scale of 0 to 10. FIRST's own CVSS v4.0 FAQ states that base scores are not risk and should not be used alone for patch prioritization.

EPSS (Exploit Prediction Scoring System)

EPSS is the probability, from 0 to 1, that exploitation activity against a vulnerability will be observed in the wild in the next 30 days. Scores update daily and are free through CSV download or API, with no registration. EPSS is not a complete risk score, because it knows nothing about your environment or your compensating controls.

CISA KEV (Known Exploited Vulnerabilities catalog)

The KEV catalog is the list, maintained by the US Cybersecurity and Infrastructure Security Agency (CISA), of CVEs with confirmed exploitation in the wild. It records history rather than predicting the future, and held 1,721 entries on 23 September 2026. To be added, a vulnerability needs a CVE ID, evidence of active exploitation and clear remediation guidance.

Recency matters. The Verizon 2026 DBIR found that the chance of renewed exploitation roughly halves at 30 days, again at 90 days and again at about nine months after the last observed activity. After about a year, an entry with no new activity looks much like one that was never exploited.

The practical rule: treat any KEV-listed CVE in your environment as exploited regardless of its EPSS score, and use recency to decide which KEV entries go first.

Asset exposure and reachability

Exposure decides whether any of these scores apply to you. FIRST's guidance on using EPSS names three checks:

• Presence: do you actually run the vulnerable software?
• Reachability: can an attacker get to it past network exposure, authentication and existing controls?
• Consequence: what would exploitation of that asset cost?

A vulnerability you do not run, or that no attacker can reach, needs no urgent work however high it scores.

Exposure is also easy to create by accident. CISA warns that misconfigured systems are often publicly accessible without their owners knowing. In cloud environments, that is the gap cloud security posture management is built to close.

Not sure which of your open findings actually need action first? If your Defender findings have outgrown what your team can clear, CyberQuell's security assessments with a step-by-step remediation plan give you a clear order of work instead of another report.

‍

The Vulnerability Prioritization Matrix CISA Now Uses

BOD 26-04 sets remediation deadlines from a 16-row decision tree that combines four yes-or-no variables, with no reference to CVSS score.

Adapted from CISA BOD 26-04, Appendix A, Table 1, as published in machine-readable form by the CERT/CC SSVC project.

Five rows carry a three-day deadline. Three of them also require forensic triage: every combination where the CVE is in KEV, exploitation gives total control, and the asset is either publicly exposed or the exploit is automatable. Triage checks whether the asset is already compromised, because patching alone will not remove an attacker who is already inside. KEV status on its own does not trigger the fastest clock. A total-control KEV entry on an internal asset that cannot be exploited automatically gets 14 days.

The bottom two rows authorize not patching on a schedule at all. If an asset is not exposed, the CVE is not in KEV and exploitation cannot be automated, the fix waits for the asset's next scheduled major upgrade or rebuild, whatever the technical impact.

This is a decision tree, not a tally. A total-control flaw on an exposed asset gets 14 days. The same flaw on an internal asset, where attackers could automate exploitation, gets 60.

Total control means the exploit gives an attacker full control of the vulnerable software's behaviour, or full disclosure of all information on the system. Partial control means limited control or information exposure, or only a small, chance-based opening for total control.

For a 50 to 500 employee organization, the table works outside government with three adjustments:

• Make your own exposure determination from scan data and your asset inventory.
• Add a consequence layer: a total-control flaw on a domain controller or finance system outranks the same flaw on a test server.
• Document the mapping so an auditor can follow how each deadline was set.

‍

What Is a Good EPSS Score, and What Threshold Should You Use?

There is no universal threshold. FIRST deliberately does not publish "critical" or "high" EPSS bands, because where to draw the line depends on your remediation capacity and risk tolerance.

Translating from a CVSS Critical workflow

Intuition misleads here because exploitation is rare. In any 30-day window, only 1.5% to 3% of published CVEs show exploitation activity. A 50% threshold sounds sensible, but it would deprioritize 98.8% of all published vulnerabilities.

FIRST's guidance on using EPSS (checked 23 September 2026) gives a better starting point:

• If you act on CVSS Critical today, the equivalent effort is roughly the 90th EPSS percentile, a score of about 0.04. It produces a similar-sized queue, filled with vulnerabilities the threat data actually supports.
• If you act on CVSS High and above (roughly the top 48% of CVEs), the equivalent score is around 0.008.

From there, tune the threshold against what your team can actually patch, using FIRST's coverage, effort and efficiency measures. Write down whether your threshold is a probability or a percentile. "EPSS above 0.10" as a probability selects a small fraction of CVEs. As a percentile, it selects 90% of them.

Why you should never multiply EPSS by CVSS

FIRST calls this mistake "score laundering." EPSS is a calibrated probability, while CVSS is a ranking with no empirical calibration. Multiply them and the result has no interpretable meaning. It is no longer a probability, and it does not combine what the two systems measure. Some vendor guides still recommend it, so check how any "risk score" in your tooling is built.

‍

How to Run Vulnerability Prioritization in Microsoft Defender Vulnerability Management

If your organization has Microsoft 365 Business Premium, Defender for Business, Defender for Endpoint Plan 2 or Defender for Servers, EPSS is already in your console. All of them include Defender's core vulnerability management. Defender for Endpoint Plan 1 and Microsoft 365 E3 do not, so those tenants need the standalone Defender Vulnerability Management licence.

EPSS is built into the vulnerability view

• Open any CVE and the EPSS score sits in the Vulnerability details tab. It is also available through the Vulnerability API.
• Above 0.9, the Threats column tooltip flags the score as urgent. Scores below 0.001 display as 0.
• Filter the Threats column for an associated active alert, an available or verified exploit, or an exploit kit.

The internet-facing tag answers CISA's exposure question

Defender flags a device as internet-facing when it is reachable from the internet over TCP, or host-reachable over UDP. The tag carries into vulnerability management, so you can filter weaknesses and security recommendations to internet-facing devices only. That is BOD 26-04's Asset Exposure variable: the one input CISA leaves to you.

Treat the tag as a floor, not a verdict. A tagged device is exposed, but an untagged one is not proof of the opposite. The tag currently covers only Windows devices onboarded to Defender, so anything Defender does not manage needs another discovery source.

The updated exposure score (public preview)

Microsoft is rolling out a new exposure score model. It weighs each CVE using EPSS, internet-facing status and asset criticality, rather than mainly CVSS. The bands stay the same: 0 to 29 low, 30 to 69 medium and 70 to 100 high. During rollout, tenants may see either model, so check which one yours shows before comparing trends.

What Defender does not give you

Defender does not apply CISA's table or surface Vulnrichment's automatable and technical-impact decisions. That means it cannot tell you which BOD 26-04 deadline a finding falls under.

One way to close the gap is to load CISA's Vulnrichment and KEV data into a Microsoft Sentinel watchlist. Then join it to Defender's vulnerability data using advanced hunting in the Defender portal. Run the join there, because Defender's vulnerability tables are not ingested into Sentinel's own workspace.

Known limits to account for

• Defender does not yet distinguish 32-bit from 64-bit systems when matching CVEs to devices. Microsoft lists this as a known cause of false positives.
• Exports from the vulnerabilities page cap at 6,000 records and 64 KB.
• After a fix is applied, Defender typically takes 24 to 48 hours to reflect it.

Remediation then runs through Microsoft Intune. From a security recommendation, request remediation and, with the Intune connection enabled, create an Intune security task with a due date that matches your deadline. Closure is proven when Defender stops reporting the exposed device, not when a ticket closes. For help setting this up across your estate, see CyberQuell's security assessment and remediation services.

‍

How Exploitability-Based Prioritization Fits ISO 27005, NIST and Cyber Essentials

Risk frameworks require a documented estimate of threat likelihood, and EPSS supplies a calibrated one that can be evidenced to an auditor. FIRST sets out where it fits:

• ISO 27005:2022 separates threat likelihood from vulnerability exploitability. EPSS informs threat likelihood.
• NIST SP 800-30 requires a likelihood determination. EPSS informs the attacker-activity half; your own controls supply the other half.
• NIST CSF 2.0 names likelihood as an input to risk response prioritization, at ID.RA-04 and ID.RA-05.

If your likelihood ratings currently rest on expert judgement, EPSS gives you a stronger evidence base. It is trained on observed exploitation data and tested against vulnerabilities and time periods it never saw in training.

What This Means for Cyber Essentials

Cyber Essentials sets a floor that no prioritization model can override. The NCSC requires fixes within 14 days of release in three cases:

• the vendor rates the issue critical or high risk
• the CVSS v3 base score is 7 or above
• the vendor gives no severity information

Since the April 2026 update, missing this deadline is an automatic assessment failure.

So for in-scope devices, exploitability decides the order inside those 14 days, not whether a fix can wait. Use it freely for everything else: fixes below CVSS 7, and systems outside your certified scope.

‍

Who Should Use This Approach

This model fits organizations already running Microsoft Defender's vulnerability management that are carrying a CVE backlog they cannot clear. The best fit is a business of 50 to 500 employees whose queue grows faster than it shrinks, and which needs to justify deferral decisions to an auditor or insurer. That is where vulnerability remediation prioritization earns its effort: it turns an unmanageable list into a defensible order of work. It is overkill for a small estate where patching everything every month is genuinely achievable. If that describes you, keep patching and skip the scoring model.

‍

Final Thoughts

Vulnerability prioritization now comes down to one choice. Keep sequencing by severity and accept a queue that grows every month, or move to exploitability and accept that some vulnerabilities will be deferred on purpose, with a rationale an auditor can follow. If you want help making that switch in Microsoft Defender, book a call with CyberQuell to talk through our security assessment and remediation services.