Exploited flaws now get 3 days, not 21: CISA rewrote the patch clock

01Four questions replaced one number

Binding Operational Directive 26-04, issued on 10 June, “supersedes and hereby revokes” BOD 22-01, the 2021 directive that created the KEV catalogue, and BOD 19-02, which gave agencies 15 days for critical flaws on internet-facing systems.¹⁵ The deadline now depends on four answers: is the asset publicly exposed; is the flaw in the KEV; can an adversary automate every step of the exploit; and does it give partial or total control. CISA publishes the last three for every CVE through its Vulnrichment programme; the agency answers the first.¹

Where control is total and the asset is exposed, the 3 days come with a “forensic triage”: patching is not enough, the agency must also check whether the system was already compromised. Flaws outside the KEV get 3, 14 or 60 days, or wait for the next scheduled upgrade. The clock starts when CISA lists the flaw or when the agency first detects it on an asset, whichever is earlier, and taking a system off the internet is itself a valid move that lengthens its deadline.¹

CISA gives its reason in the directive’s background, and it is about speed rather than volume.

“Cyber threat actors exploit unpatched vulnerabilities, and their use of AI may further narrow the time defenders have to react between patch release and possible exploitation.”

Agencies must meet Table 1 within 180 days of issuance, which is 7 December.¹ The catalogue does not wait: CISA’s implementation guidance says the due date printed on each KEV entry is now calculated from the same table, assuming exposure where CISA has evidence of it. “If CISA determines that the vulnerability is present in a publicly exposed asset, the technical impact is total, and that it is automatable by an adversary, the KEV’s due date will reflect a 3-day patching deadline.”²

02The catalogue already shows it: 21 days, then 14, then 3

We counted every KEV entry by the gap between the date CISA added it and the due date it set. Through 2023, 2024 and 2025 the median was 21 days in each year. In 2026 the pattern broke twice. The last 21-day entry was added on 5 March and the first 14-day entry on 9 March; from then until early June, 14 days was the default, with 3 days for the worst cases. From June, 3 days became the norm.⁴

What drew 3 days after 10 June is mostly software that commonly faces the internet: Ivanti Sentry, Oracle PeopleSoft, a LiteSpeed cPanel plugin, a Joomla editor extension, Splunk Enterprise, a Lantronix device server, three flaws in Ubiquiti’s UniFi OS, PTC Windchill, Cisco Unified Communications Manager, SimpleHelp remote support and, on 1 July, Microsoft SharePoint Server. Three of the 14 carry CISA’s “known ransomware use” flag. The one exception, a Cisco Catalyst SD-WAN Manager path-traversal flaw, got 14 days.⁴

03Short clocks were the exception for a year before they became the rule

Three-day deadlines are not new; what is new is that they are ordinary. BOD 22-01’s own text set a default of two weeks for recent CVEs, adjustable “in the case of grave risk”.³ CISA nonetheless gave almost everything 21 days, and used short windows as an emergency brake: one day for Citrix NetScaler in July 2025, for three SharePoint flaws the same month and for Cisco’s ASA firewalls in September; two days for Cisco SD-WAN on 25 February 2026, the day it issued Emergency Directive 26-03.⁴⁶ Across all of 2025, 7 of 245 entries had 3 days or less.⁴

The March step to 14 days is the two-week default BOD 22-01 had always written down; June’s step to 3 is BOD 26-04. A team that tracks only the directives would have missed the first change by three months.

04The old clock was already too slow, and most organisations missed it anyway

CISA’s case for a short clock was in its 2021 directive. Of the exploited CVEs it had studied, “42% are being used on day 0 of disclosure; 50% within 2 days; and 75% within 28 days.”³ A 21-day deadline therefore arrived after most of the exploitation it was meant to prevent. And the deadline was not being met. Verizon’s 2026 Data Breach Investigations Report found that exploitation of vulnerabilities was the way in for 31% of breaches, overtaking stolen credentials, at 13%, as the most common way in.⁷ As summarised by Help Net Security, only 26% of critical KEV flaws were fully remediated during 2025, down from 38% a year earlier, and the median time to full remediation rose to 43 days.⁸

05What a board should write down

The directive binds US civilian agencies, not companies; it does not even reach federal contractors unless their contracts say so.¹ But it is now the most detailed public benchmark for a patch deadline that we know of, and it sits a long way from what most internal policies say and from what most organisations achieve.

Exploited and reachable from the internet: 3 days. Patch, or take the system off the internet until you can, then check whether it was already compromised. The forensic step matters because a flaw is often used before it is listed.³

Exploited, inside the network: 7 days. Tighter than CISA’s 14, and the same as the strictest Indian rule we found (see below).

Not known to be exploited: 14 days for critical flaws on exposed systems, 60 days or the next upgrade for the rest. “Known to be exploited” means the KEV catalogue or the vendor’s own advisory, whichever says so first.

Exceptions in writing. A system that cannot meet its clock gets a named owner, a compensating control and an end date, and the board sees the count of overdue exploited flaws every month. The policy also needs one prerequisite, which BOD 26-04 makes a requirement for agencies: an inventory that tags every asset as exposed or internal.¹