CISA stopped telling agencies to patch everything. We checked its own data, and the deadline for a newly exploited bug went from 14 days to 3

Every small business that has ever hired a security consultant has received the same artifact: a scan report with several hundred findings, colour coded, sorted by CVSS score, with no indication of which four things to do on Monday. It is technically accurate and practically useless, and the reason is that a severity score describes how bad a bug is if someone exploits it, not whether anyone is going to.

In June the US government formally gave up on that model for its own agencies. The replacement is worth stealing, because it is four questions and you can answer all four without buying anything.

What changed

Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk,” was issued on June 10, 2026. It revokes two things:

• BOD 19-02, which gave agencies 15 days to fix anything CVSS-critical and 30 days for anything high. That is the “sort by severity score” model.
• BOD 22-01, which created the Known Exploited Vulnerabilities catalog and required agencies to remediate everything on it by a flat due date.

In their place, BOD 26-04 uses the SSVC method (Stakeholder-Specific Vulnerability Categorization) and asks four yes-or-no questions about each vulnerability:

1. Is the affected asset publicly exposed? Can something unauthenticated and untrusted reach it from the internet?
2. Is the vulnerability on the KEV catalog? Is there evidence somebody is actually exploiting it in the wild?
3. Is exploitation automatable? Can an attacker script every step, from finding targets to landing the payload, with no human judgment in the loop?
4. What is the technical impact? Does a successful exploit give the attacker partial control of the asset, or total control?

The answers map to a deadline. As practitioners have read the tier table, publicly exposed plus on KEV plus automatable plus total control gets three calendar days and mandatory forensic triage. Other high-risk combinations get 14 days. Internal systems with automatable exploits get 60 days. Everything else gets fixed when the system is next upgraded, which is a polite way of saying it goes in the backlog and that is fine.

Note what is not in that list. Nowhere does an agency sort by CVSS score.

We checked whether it actually changed anything

Directives are one thing. We wanted to know whether CISA’s behaviour changed, so we pulled the machine-readable KEV feed directly and counted the gap between the date each vulnerability was added and the remediation deadline attached to it. Catalog version 2026.08.21, retrieved this morning.

For entries added between January 1 and June 9, 2026, before the directive, there were 133 entries, and the deadlines were spread out:

Three quarters of everything, 99 of 133, got two weeks or three.

For entries added on or after June 10, there are 57 entries, and every single one of them cites BOD 26-04 in its required-action text. The spread collapsed:

86 percent now get three days. Nothing gets 21 days any more. This is not a policy that was announced and quietly shelved; it is visible in the data on every entry added since.

Some context for the volume, from the same feed. The catalog holds 1,674 entries in total. 273 were added in the last twelve months, 72 in the last 90 days, 21 in the last 30. And 352 entries are flagged as having been used in ransomware campaigns, which is a little over one in five.

Twenty-one genuinely exploited vulnerabilities a month, most of them now carrying a three-day clock, is the actual tempo of the problem. It is also completely unmanageable if your triage method is a severity-sorted list, which is exactly why the directive exists.

Why this is the right framework for a small business

The four questions are not federal-specific. They encode a piece of reasoning that scan reports systematically get wrong, which is that exposure and automatability matter more than severity.

A CVSS 9.8 on a database server that only accepts connections from your own application, on a private network, with no public route to it, is a thing to fix eventually. A CVSS 7.5 on the login page of your public website, with a working exploit on GitHub and a botnet already spraying it, is a thing to fix tonight. Severity ranks those the wrong way round. The four questions rank them correctly, and it takes about fifteen seconds per item.

Question three is the one people underrate. “Automatable” is what separates a vulnerability that gets exploited against a few dozen chosen targets from one that gets exploited against every host on the internet within 48 hours. A bug that needs a valid login, a specific unusual configuration, or a human deciding you are worth the effort will almost certainly never be aimed at a nine-person company in Scarborough. A bug that a script can find and exploit in one unauthenticated request absolutely will, because the attacker is not choosing you, they are choosing everyone and you are in the range.

The wp2shell chain in WordPress core is the textbook case, and it is why CISA gave it three days. Publicly exposed, yes, it is a website. On KEV, yes, within four days of the patch. Automatable, yes, one unauthenticated HTTP request to a REST endpoint that exists on every install. Total control, yes, it produces an administrator account and then arbitrary code. All four boxes. That is the profile of a vulnerability that finds you rather than the other way round.

Running the four questions on a real small business stack

Here is the same triage applied to the kit an actual twenty-person Toronto company runs, using the security stories we have covered over the past few weeks.

Your public website. Publicly exposed by definition. Everything else depends on what it is built with, but a CMS with an unauthenticated attack surface answers “yes” to automatable more often than anything else you own. This is your highest-priority asset every single time, and it is the one most likely to be maintained by nobody in particular.

Your VPN or firewall appliance. Publicly exposed, and almost always fully automatable, because it is a network appliance answering unauthenticated requests on port 443. The Cisco ASA flaw we wrote up on August 14 had a three-day CISA deadline for precisely this reason. Perimeter appliances are the second thing to check, always, and they are the ones nobody looks at because they have been working fine for four years.

An on-prem server running SharePoint, or a self-hosted dashboard, or a git runner. The question that decides this is whether it is genuinely internal. If it is reachable from the internet, treat it like the firewall. If it is truly behind a VPN with no public route, it drops to the 60-day tier and you can schedule it like a normal maintenance task. Most small businesses are wrong about which of those two they have, so verify rather than assume. The SharePoint cluster from July hurt the businesses that thought their server was internal and had a public DNS record pointing at it.

Your managed service provider’s tooling. You cannot answer any of the four questions about software you do not run, which is the entire problem with the N-central breach. The substitute is to ask your provider the questions directly and note whether they can answer them.

Staff laptops and phones. Rarely publicly exposed, rarely automatable at scale, usually reached through a person clicking something rather than a scanner finding them. That does not make them safe, it makes them a different problem, one that is solved with multi-factor authentication and email authentication rather than with a patch deadline.

The five-line version you can actually use

Write these down somewhere your IT provider will see them, and apply them to every alert:

1. Can somebody on the internet reach this thing without logging in?
2. Is it on CISA’s KEV catalog? The catalog is free, public, and the single best signal available on whether a vulnerability is theoretical or real.
3. Could a script do the whole attack, or does it need a person who has decided to target us specifically?
4. If it works, do they get everything, or just a piece?
5. Four yeses means tonight. Three means this week. Anything internal and not on KEV goes in the queue with everything else, and that is a legitimate answer rather than negligence.

The last line is the point of the whole exercise. Formally deciding not to fix something is what makes the list of things you will fix short enough to actually finish. Every vulnerability programme that treats its backlog as a to-do list ends up with a backlog nobody works, which is strictly worse than a triaged queue of six items that get done.

One caveat worth stating

BOD 26-04 binds US federal civilian agencies. It does not bind a Canadian business, it does not bind a US contractor directly, and the deadlines in it are not your legal obligations. Federal agencies have until December 7, 2026 to be operating fully under the new timelines, with policy updates due earlier in the process.

What it is useful for is the reasoning. When CISA attaches a three-day deadline to something, that is the US government’s threat intelligence apparatus stating that this specific bug is being exploited at scale right now, and it is telling you so for free, in a machine-readable file, before the story reaches the trade press. If you are looking for one input to your security decisions and you have no budget, the KEV catalog is the one to take.

Update, August 25, 2026. We ran the same exercise on the catalog again three days later, this time counting 2026 entries by product rather than by deadline, and the result was not what we expected. The third most-listed product name of the year, behind Windows and CISA’s generic “Multiple Products” bucket, is Langflow, an open-source AI workflow builder with five entries. That is ahead of SharePoint, ahead of Microsoft Office, ahead of every Cisco product. n8n, Ray, MLflow and Metabase are on the same list. It is the clearest worked example we have of the four questions above pointing somewhere nobody’s asset inventory was looking, and it has its own post.

Update, August 28, 2026. Another clean worked example landed three days later. CISA added CVE-2026-60004, a 9.8 remote code execution flaw in the self-hosted Git server Gitea, to the catalog on August 25 with a remediation deadline of August 28. Three days again, and for exactly the reasons the four questions ask about: it is internet-facing, it needs no authentication on a default install, exploit code is public, and it was already being used to drop payloads. The pattern in the data above is holding, and the Gitea case is written up here.

Update, August 29, 2026. The batch CISA added on August 26 is the best illustration yet of what “risk-based” actually means, because it splits the deadlines inside a single day’s additions. Six vulnerabilities went on the list. Four of them are old: CVE-2015-3246 in Red Hat’s libuser, CVE-2015-5287 in the Automatic Bug Reporting Tool, CVE-2021-23758 in Ajax.NET Professional, and CVE-2022-0995 in the Linux kernel. Two are the ones that matter this week: CVE-2019-1068 in Microsoft SQL Server and CVE-2026-8452 in Citrix NetScaler ADC and Gateway.

The two with the three-day deadline of August 29 are the seven-year-old SQL Server bug and the brand-new NetScaler one. The other four, spanning 2015 to 2022, got September 9, a fortnight out. Age is doing nothing here. Exposure and automatability are doing everything: NetScaler is a perimeter appliance answering unauthenticated requests, and reporting on the campaign describes web shells named x.php and z.php being dropped along with discovery commands, across dozens of exploitation attempts from a dozen attacker IP addresses in under two weeks. The Red Hat and kernel bugs are local privilege escalations that need a foothold first, so they get the longer clock.

If you ever wanted proof that sorting a vulnerability list by CVSS or by publication date is the wrong instinct, this is it. In one batch, on one day, a 2019 bug got three days and a 2022 bug got fourteen.

If you would like someone to run these four questions against your actual setup once and write down the answers, that is a conversation worth having. It is usually a short list and it is usually not the things people expect.

Sources

• BOD 26-04: Prioritizing Security Updates Based on Risk, CISA, June 10, 2026
• CISA Known Exploited Vulnerabilities catalog, JSON feed, catalog version 2026.08.21, retrieved August 22, 2026. The entry counts and deadline distributions above are our own analysis of that file.
• CISA Adds Six Exploited Flaws to KEV, Including NetScaler, Linux, and SQL Server Bugs, The Hacker News, August 27, 2026, and CISA Warns of Six Exploited Flaws in Microsoft, Linux and Citrix, Infosecurity Magazine, for the August 26 batch and its split deadlines
• FedRAMP response to CISA BOD 26-04, FedRAMP
• CISA Directive Highlights Risk-Based Vulnerability Management, Wiley
• Navigating the requirements of CISA BOD 26-04, Nucleus Security, and BOD 26-04: Risk-based Prioritization, GuidePoint Security, for the tier table