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:

Days to remediate	Entries
2 or 3 days	33
5 days	1
14 days	55
21 days	44

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:

Days to remediate	Entries
3 days	49
14 days	8

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.

Update, September 1, 2026: we re-ran the count, and the headline number moved. Catalog version 2026.08.31. The pre-directive figures above reproduce exactly, which is the point of publishing the method. The post-directive window has grown from 57 entries to 70, and the split is now 55 at three days and 15 at fourteen. That is 79 percent on the three-day clock, not 86. Nothing was revised; the fourteen-day tier simply got more use over the following ten days than the first six weeks suggested it would.

That is worth more than the correction, because the fifteen entries in the fourteen-day tier have a clear shape once you list them. Cisco Catalyst SD-WAN Manager. Microsoft ADFS. The KNX building automation protocol. MLflow. TrueConf Server. JFrog Artifactory. PaperCut NG/MF. Plus the four Red Hat and Linux local privilege escalations from the August 26 batch above.

Almost none of those is a thing a federal agency exposes to the internet. They are management consoles, internal servers and building systems. So the fourteen-day tier is not “less serious”, it is “not normally publicly exposed”, which is the first of the four questions and evidently the one carrying most of the weight in the tiering. Read that way, the deadline attached to a KEV entry is telling you something about the typical deployment of the product, not only about the bug.

Which means the tier is a default you are expected to override. CISA says so in the entry text itself: the required action on the newest additions ends “Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.” If your JFrog Artifactory or your PaperCut server is reachable from outside, your clock is three days regardless of what the catalog printed, because you have answered question one differently than the average.

The cleanest illustration is a pair we have already written about. On July 21, CISA added two WordPress vulnerabilities on the same day. CVE-2026-63030, the wp2shell chain, got three days. CVE-2026-60137, a SQL injection in the same WordPress core, got fourteen. Same product, same catalog batch, a clock four times longer, decided entirely by how the thing is reached.

The two PaperCut zero-days added on August 31 are the newest fourteen-day entries and the reason we went looking. Both are actively exploited, one is a 9.4, they chain into unauthenticated remote code execution, and there is a working Metasploit module. They still got fourteen days, because a print management server is supposed to be on the inside. Roughly 800 of them are not, which is the subject of its own post.

For completeness, the rest of the catalog as of August 31: 1,687 entries in total, 281 added in the last twelve months, 77 in the last 90 days, 31 in the last 30, and 352 flagged as used in ransomware campaigns. The ransomware count has not moved since August. The monthly tempo has gone up by half.

Update, September 4, 2026: the independent numbers behind the three-day tier. Our analysis above is of CISA’s deadlines. VulnCheck’s State of Exploitation report for the first half of 2026, published July 28, measures the thing those deadlines are responding to, and the two line up better than we expected. VulnCheck tracked 495 vulnerabilities with evidence of exploitation in the period. 23.43 percent showed exploitation on or before the day the CVE was published, which is very close to the share of KEV entries getting the short clock for reasons of speed rather than exposure. The median time from publication to observed exploitation was 80 days, down from 120 in 2025, and roughly 200 CVEs were exploited within 31 days.

Hold those two facts together, because the temptation is to collapse them into one number and you will see other vendors quote a median under five days from different populations. The distribution has two humps. About a quarter of exploited bugs are already in use when you first hear about them, which is what the three-day tier exists for. The rest give you weeks to months, which is what makes the fourteen-day tier defensible and what makes quarterly patching indefensible. The four questions in this post are how you tell which hump a given advisory sits in without waiting for CISA to tell you.

The same report also answers a question we have been asked repeatedly since the frontier AI labs started publishing vulnerability-discovery results: of 1,061 vulnerabilities attributed to AI-assisted discovery, 14 have been confirmed exploited in the wild, roughly matching the overall rate. The discovery volume is up enormously and the exploitation rate has not moved. That, and what it means for how you spend a limited patching budget, is in the post on AI-discovered vulnerabilities.

Update, September 7, 2026: the blind spot in this method, demonstrated live. Everything in this post is keyed off the KEV catalog, and the KEV catalog is keyed off CVE identifiers. That is a dependency, and this week it broke in public.

On September 5, Sansec disclosed StyleSmuggler, an unauthenticated remote code execution chain in Magento Open Source and Adobe Commerce, already exploited in the wild since September 4 and affecting every current version including the latest. As of today Adobe has published no advisory, assigned no CVE, and released no patch.

No CVE means no KEV entry. Run the four questions against it and every answer says emergency: internet-facing, no authentication required, confirmed exploitation, high impact. Run it through any automated process that consumes KEV or CVE feeds, and the store comes back clean. Scanners, insurer questionnaires, managed-service dashboards, all of them will report nothing, because there is nothing to report against.

So the correction to this post is not to the method. The four questions are the right questions and they get StyleSmuggler right immediately. The correction is to the input. KEV is a catalog of vulnerabilities a vendor has agreed to number. Between a researcher publishing and a vendor assigning, your automation has no signal at all, and the only thing that covers that window is somebody reading vendor-independent research directly. For a small business, that means picking the two or three products you actually depend on and following the researchers who specialise in them, rather than waiting for a number to show up in a feed.

We wrote the Magento case up in full, including the indicators and the order of operations, here.

For completeness, the catalog as of today stands at 1,695 entries, up eight from the 1,687 recorded on August 31: seven added on September 2 (Sangoma Switchvox, Starlette, Kestra, LiteLLM, JFrog Artifactory and two SonicWall SMA1000 flaws) and one on September 4, the actively exploited Chrome V8 type confusion CVE-2026-85046, which carries a September 18 deadline.

Update, September 9, 2026: the clearest worked example of the four questions we have seen, and it arrived in a single batch. We re-pulled the feed at catalog version 2026.09.08. The catalog now holds 1,699 entries, 215 added during 2026, 286 in the last twelve months, 82 in the last 90 days, 37 in the last 30, and 355 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly again, five weeks running. The post-directive window has grown to 82 entries, split 62 at three days and 20 at fourteen, which puts the three-day share at 76 percent. That figure has now moved 86, then 79, then 76 across three counts. The honest read is that our original 86 percent was an artefact of a six-week sample, and the settled ratio is roughly three in four.

The batch itself is the useful part. CISA added four entries on September 8 and gave them two different deadlines:

CVE	Product	Deadline	Days
CVE-2026-75650	Adobe Commerce and Magento	September 11	3
CVE-2026-86218	N-able N-central	September 11	3
CVE-2026-81963	Microsoft Windows	September 22	14
CVE-2026-85880	Microsoft Windows	September 22	14

Read that against the four questions and it decodes instantly. The two Microsoft entries are the zero-days from the largest Patch Tuesday in history, and both are local privilege escalations: an attacker needs a foothold on the machine first. Not internet-facing, authentication required, so fourteen days. The Magento and N-central flaws are unauthenticated, internet-facing remote code execution, both CVSS 10.0, both confirmed exploited. Three days.

If you were triaging on severity, the 7.8-rated Windows flaws being exploited on your own staff’s laptops would look less urgent than they are, and the 10.0-rated server flaws would look identical to each other. If you triage on exposure, which is what BOD 26-04 actually asks you to do, CISA’s own deadlines fall out of the four questions without you needing to read CISA’s deadlines. That is the strongest evidence we have found that the method transfers to a business with no security team. We wrote up the Patch Tuesday side of this separately, including why a 964-CVE month resolves to about four actions for most small businesses.

Update, September 10, 2026: it did it again the very next day, and the ratio held. We re-pulled at catalog version 2026.09.09. The catalog holds 1,703 entries, 219 added during 2026, 290 in the last twelve months, 84 in the last 90 days, 38 in the last 30, and 358 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the sixth week running. The post-directive window is now 86 entries, split 65 at three days and 21 at fourteen, a three-day share of 75.6 percent. Across four counts the series now reads 86, 79, 76, 76, which is about as settled as this is going to get: roughly three in four.

The September 9 batch is the September 8 batch with different logos on it:

CVE	Product	Deadline	Days
CVE-2026-19490	Citrix NetScaler, authentication bypass	September 12	3
CVE-2025-25249	Fortinet FortiOS and others, heap overflow	September 12	3
CVE-2026-20079	Cisco Secure Firewall Management Center, authentication bypass	September 12	3
CVE-2026-87491	Google Chromium V8, out-of-bounds write	September 23	14

Three unauthenticated flaws in appliances that sit at the network edge by definition, three days each, all three additionally flagged for CISA’s forensic triage requirement. One browser flaw that needs the user to visit a crafted page, fourteen days. Same decode, no severity scores required: the three appliances are reachable from the internet without credentials, the browser bug needs a person to do something first. Note also what this batch says about the previous one. A day after the largest Patch Tuesday ever shipped, the newly exploited things were three network edge appliances and a browser, and not one of the 974 Microsoft CVEs. If you spent September 9 triaging Microsoft’s list and ignoring your firewall vendor’s advisory, the four questions would have told you to do the opposite.

Update, September 11, 2026: the third batch in four days, and this one is a router most people forgot they own. We re-pulled at catalog version 2026.09.10. The catalog holds 1,705 entries, 221 added during 2026, 292 in the last twelve months, 86 in the last 90 days, 40 in the last 30, and 359 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the seventh week running. The post-directive window is now 88 entries, split 67 at three days and 21 at fourteen, a three-day share of 76.1 percent. The series now reads 86, 79, 76, 76, 76. It has stopped moving.

Both new entries are MikroTik RouterOS, added September 10 with a September 13 deadline:

CVE	What it is	Deadline	Days
CVE-2026-67277	Missing authentication for a critical function. RouterOS accepts bandwidth-test connections before the primary session has authenticated, which can leak kernel buffer contents or crash the device	September 13	3
CVE-2026-86060	Argument injection at SSH login. A username beginning with a prohibited character escalates the session to full administrative privileges	September 13	3

Run the four questions and both answer the same way. Internet-facing by design, because a router is. No credentials required. Fully automatable, because it is a network service answering unauthenticated requests. Three days, twice.

The background is worth knowing because it is a good example of coordinated disclosure working and then being overtaken. CERT Polska published six RouterOS vulnerabilities on September 5. MikroTik had already shipped fixes on September 3, in RouterOS 6.49.21 and 7.23.4 on the long-term branches and 7.24.2 on stable, and deliberately withheld technical detail to give operators time. Five days later two of the six were confirmed exploited in the wild, chained under the name MikroTrick into unauthenticated administrative control of any RouterOS device with SSH reachable from the internet.

That is the whole argument of this post in one week. The fix existed before the exploitation did. The gap that decides whether you are affected is not discovery, or severity, or whether anyone told you: it is whether somebody applied an update that was sitting there on September 3. And a MikroTik router is precisely the kind of device that gets installed once, works for six years, and never appears on anybody’s patching list, which is what makes it worth a specific look. If you have one, the answer to “is SSH reachable from outside” should be no regardless of version, and that is a five-minute change.

Update, September 12, 2026: the fourth batch in five days, and it is the remote-access tool your IT provider uses to reach your machines. We re-pulled at catalog version 2026.09.11. The catalog holds 1,709 entries, 225 added during 2026, 295 in the last twelve months, 90 in the last 90 days, 44 in the last 30, and 360 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the eighth week running. The post-directive window is now 92 entries, split 69 at three days and 23 at fourteen, a three-day share of 75.0 percent. The series reads 86, 79, 76, 76, 76, 75. Three in four, confirmed again.

Four additions on September 11, and once again two deadlines:

CVE	Product	What it is	Deadline	Days
CVE-2026-84869	ConnectWise ScreenConnect	Improper privilege management and missing authorization. File transfer and execution through an active remote session without authorization or host confirmation	September 14	3
CVE-2026-85706	GitLab CE and EE	Path traversal in the repository commits API. Unauthenticated arbitrary file read	September 14	3
CVE-2026-42016	JFrog Artifactory	Incorrect authorization. The token signature and issuer are validated but the token scope is not, leading to privilege escalation	September 25	14
CVE-2026-42018	JFrog Artifactory	Improper authentication. An internal anonymous-user token can be returned to an unauthenticated caller even when anonymous access is disabled	September 25	14

The decode is the same as the previous three batches and it is getting monotonous in a useful way. GitLab is unauthenticated file read on a service that exists to be reachable, so three days. ScreenConnect is a remote-access server that by design accepts connections from the internet and is the thing an attacker most wants, so three days. Both Artifactory flaws require the attacker to already hold or obtain a token against an artifact repository that is usually internal, so fourteen.

The ScreenConnect entry is the one worth stopping on if you are a small business, because you probably do not run it and you are probably exposed to it anyway. ScreenConnect is what a lot of managed service providers and outsourced IT shops use to take control of client machines. In the wording of the CISA entry, the flaw permits file transfer and execution “through an active remote session without authorization or host confirmation,” which means the abuse path runs from a compromised provider straight onto your desktop, without the prompt that is supposed to ask you first. That is the same shape as the N-able N-central breach we covered, and the action item is the same one: this is not your patch to apply, it is your provider’s, and the only thing you can do is ask them today whether they have applied it. A provider who cannot answer that question by Monday is telling you something.

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, re-pulled at catalog version 2026.08.31 on September 1, 2026, at catalog version 2026.09.08 on September 9, 2026, at catalog version 2026.09.09 on September 10, 2026, and at catalog version 2026.09.11 on September 12, 2026 for the updates above. The entry counts, deadline distributions and the quoted entry text for the September 11 batch are our own analysis of those files.
• 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
• VulnCheck State of Exploitation 1H-2026, VulnCheck, July 28, 2026, for the 495 exploited vulnerabilities in the period, the 23.43 percent exploited on or before CVE publication, the median time-to-exploitation of 80 days against 120 in 2025, the roughly 200 CVEs exploited within 31 days, and the AI-assisted discovery figures
• 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