CISA's Patch Deadlines Collapsed From 21 Days to Three — and It Started Four Months Before the Directive That Gets the Credit

CISA added six vulnerabilities to its Known Exploited Vulnerabilities catalog on 21 and 22 July. Two of them were WordPress Core, added on the same day, and they drew remediation deadlines eleven days apart.

That split is the visible edge of a much larger shift. We pulled the catalog's full JSON feed — 1,653 entries, catalog version 2026.07.24 — and measured every remediation deadline CISA has ever issued. The median window has fallen from 21 days to three. Almost none of that happened when the directive everyone credits was published.

The deadlines moved before the directive did

Binding Operational Directive 26-04 was issued on 10 June 2026. It supersedes and revokes BOD 22-01, which had governed KEV remediation since November 2021, and BOD 19-02 before that. It replaces a flat clock with a matrix built from four variables: whether the asset is publicly exposed, whether the CVE is in the catalog, whether an adversary can automate the exploit, and how much control exploitation yields.

The natural assumption is that the timelines changed on 10 June. They did not.

The 21-day window was retired on 5 March 2026 — three months before the directive. It had been the catalog's workhorse, carrying 1,025 of all 1,653 entries. It has not been used since.

The first 3-day deadline was issued on 27 January 2026, four and a half months before BOD 26-04 formalised risk-based timing. By the time the directive appeared, the median had already halved to 14 days on its own.

What the directive did was ratify a regime the catalog had been running for a quarter. Since 10 June, 36 entries have been added: 32 at three days and four at fourteen. Only two vocabulary items remain in active use.

The six that landed this week

The two WordPress Core entries are the clearest illustration of the matrix doing its job — same vendor, same product, same day, different answers to the exposure and automation questions, and therefore different clocks. It is also the clearest illustration of why a team cannot infer its deadline from the vendor name.

The arithmetic problem nobody legislated

The directive is explicit that "Days are calendar days." Combined with a three-day window, that produces an effect the policy text never addresses: the deadline is set by which weekday CISA publishes.

A vulnerability added on a Thursday with a three-day clock is due on Sunday. The federal staff who must remediate it have Friday. Ten of the 32 three-day deadlines issued since 10 June contain exactly one working day, and eleven of them fall due on a Saturday or Sunday.

This is not an argument against short deadlines. It is an argument that a 72-hour figure quoted in a policy document and a 72-hour window experienced by an on-call team are different quantities, and only one of them is in the directive.

The directive's own clock has not finished running

There is a wrinkle in the sequencing worth knowing about. The directive phases its requirements, and the phase that binds agencies to Table 1's remediation timelines is the last one.

Phase III falls due on 7 December 2026 — 134 days from now. Phase II, which requires agencies to rebuild their processes around the CVE database and the KEV catalog, falls due on 9 August, in two weeks.

Meanwhile the three-day deadlines are being issued today. The catalog is running ahead of the compliance schedule of the directive that governs it, which is consistent with everything else here: the operational regime moved first and the paperwork is catching up. For a federal team the practical reading is that the deadline in the catalog is the one that will be measured, whatever phase the directive says it is in.

Who is actually in the catalog

The distribution is flatter than the coverage suggests. Microsoft leads with five entries of 36, and no vendor accounts for more than a seventh of the period. Thirty-two of the 36 are same-year CVEs, but the tail is long: CVE-2008-4128, a Cisco vulnerability eighteen years old, was added on 13 July with a three-day deadline. Age is not a proxy for urgency in this catalog, and an asset inventory that only tracks recent CVEs will miss the ones that arrive with the shortest clocks.

One more number worth holding lightly: 34 of the 36 entries carry a ransomware status of "Unknown" and two of "Known". That field records what CISA has confirmed, not what is happening, so its emptiness says nothing reassuring.

If you are not a US federal agency

Most readers of this are not bound by any of it. The catalog is still the most useful free prioritisation signal available, and the way to use it has changed with the timings.

• The deadline is now a severity signal. When windows were uniformly 14 or 21 days, the date carried no information. Now a three-day clock versus a fourteen-day clock is CISA telling you how it answered the exposure and automation questions — which is exactly the judgement most organisations lack the data to make themselves.
• Same vendor, same day, different clocks. The two WordPress Core entries show the deadline is set per-vulnerability, so a rule that escalates on vendor name will misfire in both directions.
• Weekend arithmetic applies to you too. If you mirror KEV deadlines into your own SLAs, a Thursday addition gives your team one working day unless you convert calendar days to working days deliberately.

The matrix itself is a picture

There is one more friction worth recording. The directive requires agencies to automate their vulnerability reporting through the CDM dashboard. The table that determines every deadline — Table 1: Remediation Timelines — is published on the directive page only as an image file. The full text of the directive contains exactly two day-counts, "60 days" and "180 days", and both refer to the directive's own implementation phases rather than to any remediation tier.

The deadline data is machine-readable in the catalog feed, which is how this article was written. The rules that generate it are not.

The caveats that matter

• Phase III is our reading of the directive's wording, which requires remediation within Table 1's timelines "within 180 days of issuance". We have not seen CISA state how it treats deadlines issued before that date.
• 36 entries is a small sample. The post-directive period is six weeks long. The direction is unambiguous and consistent with the four months preceding it, but the precise tier split will move.
• This binds federal civilian agencies, not you. The catalog is used worldwide as a prioritisation list, including by ASEAN CERTs, but the deadlines are a US federal obligation. Treat them as a signal of CISA's assessed urgency rather than as your own clock.
• Ransomware association is mostly unrecorded. Of the 36 entries added since 10 June, 34 carry a ransomware status of "Unknown" and two of "Known". Absence of the flag is not evidence of low risk.
• We did not verify the tier values in Table 1, because they are not published as text. Every window quoted here is measured from the deadlines CISA actually issued, not read off the matrix.

Key takeaways

• The shift predates the directive. The 21-day window was last used on 5 March 2026; BOD 26-04 was issued on 10 June.
• Two windows remain in use. Since June, 32 entries at three days and four at fourteen.
• Calendar days are the trap. Ten of the 32 three-day deadlines leave a single working day; eleven fall due at the weekend.
• Vendor is not a proxy for urgency. Two WordPress Core CVEs added on 21 July are due eleven days apart.
• Age is not urgency. An eighteen-year-old Cisco CVE drew the same three-day clock as this month's Microsoft SharePoint flaw.
• The rules are less machine-readable than the data. Table 1 is published as an image; the catalog it governs ships as JSON.