The patching rule that beats "just do the criticals"

Almost every security standard tells you to patch by severity. Cyber Essentials says fix anything scored 7 or above within 14 days. Most vulnerability tools sort by the same number. It is the obvious rule, it is written into the frameworks, and on the evidence it is a very expensive way to spend a small business's limited patching time.

We analysed 400,837 public vulnerabilities against CISA's Known Exploited Vulnerabilities catalogue (KEV), the list of flaws confirmed as being used in real attacks. The question was simple: if you can only act on some vulnerabilities, which selection rule catches the most of the ones that actually get exploited?

The numbers

Five rules, tested against 1,733 confirmed-exploited vulnerabilities. Recall is the share of exploited flaws the rule catches. Precision is the share of what it hands you that was ever exploited.

Start with the bottom row. "Just do the criticals", the rule most small businesses actually follow when the list gets long, is the worst performer in the table. It hands you 54,012 things to do and catches barely a third of what gets exploited.

Now compare it with the second row. Patching everything with an EPSS score of 0.1 or above means working through 17,217 items to catch 74%. That is a third of the workload for twice the coverage. If you are going to cut the list down, cut it by likelihood, not by severity.

The top two rows are a closer call. Patching everything scored 7 or above catches 89% of exploited flaws, more than any other rule here, but the list is 198,716 items long and 99.2% of it was never exploited by anyone. The EPSS list is less than a tenth of the size and gives up about 15 percentage points of coverage.

Neither list is precise. Of the 17,217 items the EPSS rule selects, about one in 13 was ever confirmed as exploited. That is roughly ten times better than the severity rule, and still mostly things nobody attacked.

What EPSS is, and why you probably have not heard of it

CVSS, the Common Vulnerability Scoring System, scores how bad a flaw would be if someone exploited it. It is a severity rating. It says nothing about whether anyone will.

EPSS, the Exploit Prediction Scoring System, is a different measure entirely. It is a probability, between 0 and 1, that a given vulnerability will be exploited in the wild in the next 30 days. It is maintained by FIRST, the same body behind CVSS, it is free, and it is published for most vulnerabilities that matter.

An EPSS of 0.1 means roughly a one in ten chance of being attacked in the next month. That is the threshold in the table above, and it is deliberately low. Raise it to 0.5 and your list drops to 4,306 items, of which about one in five was exploited. The price is coverage: you now catch only half.

The reason severity and probability diverge so sharply is that they answer different questions. A flaw can be genuinely catastrophic in theory and require physical access to a device nobody owns. The severity score is high. The realistic chance of it being used against you is near zero.

The honest caveats

Three, and we would rather state them than have you find them.

EPSS is trained partly on exploitation evidence that overlaps with KEV, the list we measured against. Some of its advantage in this table is therefore circular. It is a genuine forward-looking prediction rather than a lookup of the answer, so this inflates the effect rather than manufacturing it, but it does inflate it.

EPSS coverage changes the result a great deal. In this analysis 95% of vulnerabilities carry an EPSS score. When we first published, our data covered about half, and we noted that this would flatter the EPSS rules. It flattered them far more than we allowed for. The correction note at the end sets out what changed.

KEV is a floor, not a census. It is what one agency has confirmed and published, mainly for US federal remediation. Plenty of exploitation never reaches it, so every recall figure here is measured against an undercount.

Grant all three and the EPSS list is still less than a tenth of the size of the severity list, and still beats the criticals-only rule on both size and coverage.

What to do with this

• Do not throw out the severity rule if you are certifying against something. Cyber Essentials asks for CVSS 7 and above inside 14 days, and an assessor will check that, not this article. Meet the standard.
• Use EPSS to order the work inside it. The framework tells you what must be done. Nothing stops you doing the likely-to-be-exploited ones first. On a list of nearly 200,000, order is the entire game.
• If you must cut the list, do not cut it to "criticals only". That rule is the worst one we tested. A likelihood threshold gives you a shorter list and catches more.
• Check EPSS before you panic about a headline score. A 9.8 with an EPSS of 0.001 is not tomorrow's emergency. A 6.5 with an EPSS of 0.6 might be.
• Ask your provider which they sort by. If your IT supplier or managed service sorts your patch queue by CVSS alone, that is worth a conversation. It is not wrong, it is just very expensive.
• Do not treat KEV as a to-do list either. Most of what is in it is enterprise and specialist software a small business does not run.

How Steelwise can help

Working out which of this actually applies to what you run, and what a sensible patching rhythm looks like for a business without a security team, is the kind of thing we do in a security review. Get in touch.

About the data. Figures come from our analysis of 400,837 distinct public vulnerabilities sourced via StackFlag, which is a Steelwise product, queried on 4 October 2026. The underlying data is public: the National Vulnerability Database, CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.02, 1,733 entries), GitHub Security Advisories, and the Exploit Prediction Scoring System. We have published the caveats above because they are real, including the ones that weaken the finding.

If you spot an error in this filing, tell us and we will correct it and note the change.

Further reading

• FIRST: the Exploit Prediction Scoring System
• CISA: Known Exploited Vulnerabilities catalogue
• NCSC: vulnerability management guidance

Correction

4 October 2026, 16:06 BST. This filing was first published on 30 July 2026 using a dataset that turned out to be incomplete. A fault in StackFlag had silently failed to store about 180,000 records from the National Vulnerability Database. We re-ran the analysis on the complete data and every figure in this filing has changed.

The original said the EPSS rule produced 3,513 items of which "more than a third" were exploited, and described the severity rule as "25 times the workload for nine and a half percentage points more coverage". On complete data the EPSS list is 17,217 items, about one in 13 of which was exploited, and the severity list is 11.5 times longer for about 15 points more coverage. Our claim that an EPSS threshold of 0.5 gave a list with better-than-even precision was also wrong: it is about one in five.

What holds: "just do the criticals" is still the worst rule we tested, and a likelihood-based rule still produces a far shorter list than a severity threshold. What does not: the size of the advantage, which we overstated. We now count distinct vulnerabilities, not database records.

← All filings