Patching by severity is over. Here's what replaces it.

A single statistic anchors this filing. In 2018, the median time from a vulnerability being disclosed to being exploited in the wild was 840 days. Today, on Checkmarx's numbers, it is under two days. Their researchers expect it to be one minute by 2028. The CVSS severity score, the number every patching schedule for the last decade has been built on, was designed for a world where defenders had weeks. They no longer do.

This filing pulls together the May and June reporting on what has changed, what the regulators are now asking for, and what an SME should do about it. The short version: stop sorting bugs by severity, start sorting by exposure and exploitation.

What changed

Three things hit the industry at once.

Exploitation overtook credential theft. The 2026 Verizon Data Breach Investigations Report, published in May, found that around 31% of all breaches now begin with vulnerability exploitation. That overtakes credential theft as the leading entry point for the first time in the report's nineteen-year history. The same report notes that exploitation-driven breaches rose 180% year on year. Patrick Münch of Mondoo flagged a sharper number underneath it: only 26% of vulnerabilities on CISA's Known Exploited Vulnerabilities (KEV) catalogue were fully remediated last year, and the median time to patch rose from 32 to 43 days. The catalogue is meant to be the short list of things attackers are actually using. Three quarters of those did not get patched in time.

Discovery accelerated. The UK AI Security Institute reports that Anthropic's Claude Mythos Preview model completed an attack chain in three out of ten benchmark cases. No prior AI model had ever completed it at all. Rik Ferguson of Forescout summarises the consequence: "The old assumption was that defenders had at least some time on their side to assess, prioritise, and patch before exploitation became realistic. That advantage has evaporated." Researchers at Recorded Future make the same point with their own data. The volume of public CVEs and the speed from disclosure to weaponisation are both climbing, and the increase tracks the spread of AI-assisted code review.

The other side already shifted. Checkmarx surveyed software firms in early 2026 and found that 75% of them admitted to knowingly shipping code with known vulnerabilities. Down from 81% the prior year. Eran Kinsbruner of Checkmarx put it bluntly: "The backlog isn't a process problem anymore; it's a math problem. AI-generated code is outpacing every manual remediation model in existence." If the people writing the software cannot keep up, the people running it cannot either.

What CISA changed in response

On 11 June, CISA replaced its standing patching directives BOD 19-02 and BOD 22-01 with a single new one, BOD 26-04. Federal civilian agencies have 180 days, until around 7 December, to implement it. The directive is the first official US move away from severity-driven patching.

The mechanism is worth understanding because UK regulators and large UK enterprise customers tend to track CISA's direction. BOD 26-04 stops asking agencies to sort bugs by their CVSS severity label. Instead, agencies assess each vulnerability on four factors:

Asset exposure. Is the affected system reachable from the internet, or only from a managed internal network? An identical bug on a public-facing web server and a hardened internal database is not the same risk.
KEV status. Is this vulnerability on CISA's Known Exploited Vulnerabilities list? If yes, real attackers are already using it. The CVSS score is irrelevant to the urgency.
Exploit automation. Does an exploit exist that runs at scale, with no skill, in widely available tooling? A vulnerability with a one-click Metasploit module is a different operational risk to one that needs a research team.
Technical impact. What does the attacker actually get from a successful exploit? Remote code execution as root is not the same as a denial-of-service against a non-critical service.

The patching windows are tightened where the four factors stack against you. Three days for the worst combinations, paired with a forensic check to see whether the attacker has already been in. Longer windows where the factors do not. And, notably, deferral to "the system's next major upgrade" where a vulnerability sits on a system that is hard to reach, has no public exploit, and would do little if compromised. CISA's framing was direct: "a severity label alone doesn't dictate what to fix first."

What 345 days of exposure looks like

The case study published by BleepingComputer on 3 June is the one to put in front of anyone arguing this is theoretical. Sprocket testers were brought in to a regional US bank and found an API endpoint on a third-party mortgage platform that "required no authentication and no session of any kind". By incrementing tenant IDs, an attacker could read records, including named staff with business email addresses and direct dial numbers, from every financial institution on the shared platform.

The point the writers made was not about that specific bug. It was about timing. An annual penetration test leaves, in their phrase, "roughly 345 days of operational reality unvalidated". The infrastructure changes constantly: cloud migrations, vendor integrations, new deployments, configuration drift. The test that proved the firm was clean on 1 May does not prove it on 2 May, never mind on 30 April of the following year. For most SMEs the equivalent is the IT provider's quarterly check, or the once-a-year insurance-required scan. The gap between checks is where almost all real exposure lives.

What an SME should change

You are not going to write a copy of BOD 26-04 for your business this quarter. You can change three things that close the gap quickly.

Sort your patching by what attackers actually exploit, not by severity. CISA's KEV catalogue is free, public, and updated continuously. Anything in your environment that matches an entry on KEV should be patched ahead of anything else, regardless of its CVSS score. Anything with a CVSS of 9 that is not on KEV, not reachable from the internet, and has no public exploit can wait behind it. The rule is short enough to print on a card. If your IT provider runs your patching and they cannot show you that their priority order matches KEV, that is the conversation to have.

Track time-to-patch as a number for the systems that matter. Pick the five to ten systems that, if compromised, would actually hurt the business. Email, accounting, the customer database, the website, the production environment, the back-up store. For each, write down how long the last critical patch took to land after it was published. If you do not know, ask. The point is not the absolute number; it is making the number visible. Most firms find theirs is shocking the first time they look. Our existing filing on the only SOC metric that matters covers why this number, not the count of alerts, is the thing to watch.

Close the "one big check a year" loop. The 345-day point applies to almost every SME. The annual penetration test or insurance scan is necessary, not sufficient. Two cheap things help. First, an external attack-surface scan, run weekly against your public-facing systems, that flags new services as they appear. Several providers do this for a few pounds per asset per month. Second, a rule that any new public-facing service goes through a short security check before it goes live, not after. Most accidental exposures are services that were spun up for a project and never reviewed.

There is a fourth change worth flagging, but it is harder. The supplier side. Around half the systems an SME relies on are run by someone else. The questions to ask of suppliers are different in kind, not in degree. Not "are you patched". The honest answer is always "yes". The useful questions: do you publish your time-to-patch numbers, do you subscribe to KEV alerts, what is your process for emergency patching outside the maintenance window, and when did you last exercise it. If a vendor cannot answer in plain English, the answer is that they are not doing it.

What not to do

A few patterns are common and worth naming.

Buying a "vulnerability management platform" before you have a patching process. The platform produces lists. The lists need someone to act on them, on a schedule, with clear priorities. A platform without a process produces a longer list, not a safer estate. Start with the KEV-first rule and the time-to-patch number. The tool can come later.

Counting CVSS-critical patches done as a board metric. It looks reassuring on a slide and it does not measure what hurts. A board metric that does measure it: percentage of KEV-listed vulnerabilities in your environment, patched within X days. The number is small if you are doing well and big if you are not. It also tracks the change CISA has just made.

Treating AI vulnerability discovery as someone else's news. The capability is on both sides. Tools that find bugs are also tools that find them in your code, in your suppliers' code, and in the open-source you depend on. The defender's question for the next twelve months is not "will AI find a bug in our stack". It is "when it does, are we positioned to act on it within the new window".

The change behind the change

The deeper thing here is that the security industry has spent twenty years building processes around the assumption that humans triage vulnerabilities and humans exploit them. Both of those assumptions are weakening at once. The patching cadence that worked when both sides moved at human speed does not work when one side moves at machine speed and the other does not.

The fix is not to match the attacker's speed across the board. That is unaffordable for any SME and unnecessary for most vulnerabilities. The fix is to be much faster on the small set of vulnerabilities that are actually being used, much more honest about the systems that matter, and much more sceptical of metrics that count motion rather than outcomes. CISA's directive is one model. KEV-first patching is the simplest version of it that an SME can implement this week.

How Steelwise can help

Reading your current patching process against the new rules, picking the systems that matter, and writing the short KEV-first runbook that your IT provider can follow is the kind of practical work we do with clients. Get in touch.