In June, CISA stopped treating every high-severity vulnerability as equally urgent. Whereas just a couple of months earlier, Cyber Essentials moved in the opposite direction.

Binding Operational Directive 26-04, issued on 10 June 2026, tells US federal agencies to prioritise vulnerabilities by risk rather than by severity score, and in the process it retired the requirement to use CVSS at all. For a small business, that contrast is academic. For an enterprise running a large, complicated estate, it is the difference between a programme that prioritises risk and one that prioritises compliance paperwork.

Two regulators, two philosophies

CISA’s directive replaces a severity number with four questions a Resilience underwriter would recognise.

1. Is the affected asset publicly exposed?
2. Can the flaw be exploited through automation?
3. Does it hand an attacker total control of the system?
4. Is anyone already exploiting it in the wild?

A vulnerability that meets all four must be fixed within three days, with forensic triage to check whether it has already been used. The four questions are the decision points CISA draws from Stakeholder-Specific Vulnerability Categorization (SSVC), a methodology it built with Carnegie Mellon’s Software Engineering Institute and has run since 2020; BOD 26-04 makes it the binding federal standard. Everything below that threshold gets a judgment instead of a uniform countdown — though for the worst vulnerabilities CISA’s three-day deadline is far tighter than Cyber Essentials’ flat 14 days. Risk-first is not laxer; it concentrates urgency where it belongs. In consolidating two older directives, BOD 26-04 also removed the obligation to prioritise by CVSS, a quiet but significant concession that severity scores and exploitation risk are not the same thing.

Cyber Essentials, run by the IASME Consortium on behalf of the NCSC, went the other way. Its current specification requires that any in-scope vulnerability with a CVSS base score of 7.0 or above, or one a vendor labels critical or high, or one where the vendor discloses no severity at all, be patched within 14 calendar days of a fix being released. Under the current Danzell question set in force since 27 April 2026, missing that window is an automatic fail, with no compensating-control route around it. The only way to spare a system you cannot fix in time is to take it out of scope altogether, isolating it behind a firewall or VLAN with its internet access cut. Commentary from assessors suggests the NCSC has even considered shortening the window to seven days. Large enterprises rarely choose this model. Many inherit it, because CE+ is now a gate for UK government tenders. To be precise, Cyber Essentials does not require patching everything — it tiers by severity, mandating fixes for high and critical flaws (CVSS 7.0 and above). My issue is with severity as the sole sorting key, not with the existence of a threshold.

A rule built for 10 laptops, applied to 10,000 servers

Cyber Essentials was designed as a baseline for the broad population of UK businesses, most of them small. For a 10-seat firm running mostly auto-updating software, blanket 14-day patching is a gift. It is simple, blunt, and effective. It removes the need to make hard prioritisation calls, because at that scale there are very few to make.

Hand the same rule to an enterprise carrying tens of thousands of assets across acquired estates, legacy systems, operational technology, and clouds it half-remembers buying, and the arithmetic changes entirely. The same instruction now governs a far larger and more heterogeneous surface, much of which cannot be patched on a 14-day cadence without breaking the business it supports. The rule did not get harder to follow because anyone was careless. It got harder because a control built for one population is being applied, through procurement, to another.

The score the rule depends on is disappearing

There is a deeper problem with anchoring a mandate to a CVSS threshold. The threshold itself is becoming unreliable. The public CVE programme published 48,185 vulnerabilities in 2025, up 20.6% on the previous year, roughly 130 a day, according to Cisco researcher Jerry Gamblin’s analysis. NIST puts the longer-run rise at 263% between 2020 and 2025. The volume alone strains any model that treats all high-severity findings as equally pressing.

What makes it worse for a CVSS-keyed rule is that the score itself is no longer guaranteed to exist when the clock starts. On 15 April 2026, NIST moved the National Vulnerability Database to a triage model, fully enriching only vulnerabilities that are known to be exploited, used in federal systems, or designated critical under Executive Order 14028, and leaving the rest unscored. In 2025, only about a quarter of new CVEs received full analysis. A rule that begins “CVSS base score of 7.0 or above” increasingly points at a number that, for a growing share of vulnerabilities, is published late or not at all.

The trigger is eroding beneath the standard’s feet. The concept underneath is no firmer. “Severity” — the very thing CVSS claims to measure — is never formally defined in the standard, a gap now debated openly across the vulnerability-data community, where even CVSS working-group members cannot point to one. And where the number does exist, its own custodians say it should not carry this weight: FIRST, which maintains CVSS, states that base scores “should not be used alone” to assess risk, and now points to BOD 26-04 as the model to follow. Cyber Essentials keys a binding deadline to the very score FIRST warns against using this way.

AI already moved the deadline

Every 14-day SLA rests on an assumption. It assumes a meaningful gap between when a vulnerability is disclosed and when it can be weaponised. Mandiant measured that gap at 63 days in 2018 and 32 days by 2022. By 2024 it had crossed zero, with exploitation beginning, on average, before a patch was available. That assumption is now failing outright. According to an emergency strategy briefing from SANS, the Cloud Security Alliance, and the OWASP GenAI Security Project, the mean time from disclosure to confirmed exploitation has fallen below one day in 2026.

The same briefing surfaced the detail that should worry anyone running a CVSS-floor rule. The AI tooling driving that compression does not just find individual flaws, it chains low-severity primitives into working exploits, precisely the bugs a “7.0 and above” threshold is designed to ignore. A severity floor filters out exactly the material that modern tooling now assembles into critical compromises. The pressure is visible on the human side too. According to longtime kernel maintainer Willy Tarreau, the Linux kernel security mailing list went from two to three reports a week to five to 10 a day, a volume Linus Torvalds described as almost entirely unmanageable.

A 14-day clock is the wrong instrument when exploitation can precede the patch, and a severity floor is the wrong filter when the danger arrives in pieces that each score below it.

Descoping the estate optimises for the assessor

Faced with a rule that a large estate cannot satisfy on its terms, the rational response many organisations reach for is to shrink the assessment scope until what remains can pass. It works on paper. The certificate is issued, the tender requirement is met, and the dashboard turns green.

Resilience has a name for the instinct behind that move. In our risk-first CISO framing, the compliance operator runs a programme optimised for the assessor rather than the adversary. Descoping is that pattern in miniature, a control implemented to satisfy a requirement rather than to address an exposure. It does not lower the organisation’s real risk. It relocates that risk to a place the certificate cannot see.

Attackers do not respect a scope boundary. A descoped, unpatched, internet-facing asset is exactly the kind of forgotten system that turns a routine incident into a material loss.

What a risk-first approach actually prioritises

The alternative is not patching less. It is prioritisation by exploitation likelihood and business consequence rather than by a severity label assigned in isolation. That is the logic CISA has now adopted, and the logic mature security leaders were already running.

Three signals do most of the work. Whether a flaw is being exploited, captured in CISA’s Known Exploited Vulnerabilities catalogue. How likely it is to be, estimated by the Exploit Prediction Scoring System (EPSS) maintained by FIRST, which scores the large majority of CVEs well below a 10% probability of exploitation in the next 30 days. And whether the vulnerable asset is actually reachable in the environment, which determines whether a theoretical flaw is a practical exposure. Together these replace a binary severity gate with a defensible ranking. None of these signals is flawless — EPSS, for one, estimates observed exploitation and should inform prioritisation rather than dictate it — but in combination they beat a single CVSS score.

Commercial platforms now fold these signals into a single figure. Qualys’s TruRisk, for instance, blends exploitability, threat intelligence, CISA KEV and asset criticality, and on the vendor’s own figures cuts the high-priority list by up to 85% against raw CVSS — precisely the operational shift argued for here. But a risk score does not lift the compliance burden for a CE-bound organisation: the assessor still tests the blanket 14-day rule against CVSS severity, not your TruRisk score. If anything it sharpens the friction, flagging for deferral the very high-CVSS patches the certificate insists you treat as urgent.

Resilience adds the dimension CVSS never had, the financial consequence of the exposure. As Chris Wheeler, CISO at Resilience, puts it, CVSS scores don’t have a dollar sign. The controls that most limit loss severity, such as tested disaster recovery, validated backups, and practised incident response, rarely top a vulnerability scan, yet they move the cost of an incident more than another quarter of aggressive patching. What separates a contained incident from a catastrophic one is seldom what a severity score elevates, and it is claims data, not scan output, that shows you which is which.

What to do before the standard catches up

The standards are likely to converge on risk, because the alternative is becoming arithmetically impossible for large estates. CISA has already moved. The NCSC’s own thinking is not far behind: its 2026 “patch wave” guidance tells organisations to prioritise updates with SSVC — the very framework CISA’s directive adopts — and its vulnerability management guidance treats a decision not to patch as a legitimate, senior-level risk call. The blunt instrument is Cyber Essentials, the certification, which has gone the other way: April’s Danzell revision tightened the rule rather than loosening it. So when does the UK catch up? IASME and the NCSC revise the scheme annually, so the next realistic window is 2027 — but on present signals convergence is more likely to be forced by CVE volume, AI and the CISA precedent than scheduled.

Until that happens, large enterprises should not reshape the estate to flatter the certificate. Run the blanket rule where it genuinely fits, on the small, uniform, internet-facing surfaces Cyber Essentials was designed for, and govern the rest by exploitation evidence, reachability, and financial exposure. Hold CE+ for the tenders that require it without mistaking the badge for the security posture.

And when the board or the assessor asks how many vulnerabilities you closed this quarter, answer with the better question. How many of them moved the number?

Nothing here should be taken as legal, financial, or security advice for your specific situation — see the full disclaimer at cyberresilience.com/disclaimer.