Patching Is Not Remediation. CISA Just Made That Federal Policy

When your team remediated its last known exploited vulnerability, did anyone prove the system was not already compromised before the patch landed?

For most security programs, the honest answer is no. The patch closed the door. Nobody checked whether someone was already inside. That gap was an operational shortcut everyone tolerated. As of June 10, federal policy treats it as unacceptable.

What changed

CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk. It supersedes BOD 19-02 and BOD 22-01 and rebuilds federal vulnerability management around four risk criteria: whether the asset is publicly exposed, whether the vulnerability is in the Known Exploited Vulnerabilities catalog, whether exploitation can be fully automated, and whether exploitation yields control of the asset.

Vulnerabilities meeting the highest-risk criteria must be remediated within three days. CISA’s stated rationale is that adversary use of AI may be compressing the window between patch release and exploitation.

The remediation timeline got the headlines. It is not the part that should change how you operate.

The requirement that matters

For the highest-risk tier, BOD 26-04 pairs the three-day clock with a second mandate: agencies must check whether the affected asset was compromised before the patch was applied.

That should be read carefully. The agency responsible for defending federal networks has stated, as policy, that patching is not remediation if the attacker arrived first. Close the vulnerability while the adversary retains access and you have a patched, compromised system. The compliance checkbox is green. The breach is ongoing.

The check is not a log review. It is forensic triage: scope the exposure, gather sufficient evidence, analyze it, and produce a record stating who, what, where, and when, with timestamps. It runs inside the same 72-hour window as the patch. And the clock does not start when the team is ready. It starts when the vulnerability is identified.

This will not stay federal

BOD 26-04 binds federal civilian executive branch agencies. If you run security for an enterprise, it is tempting to file this under government news. The last directive CISA issued in this space argues otherwise.

BOD 22-01 created the Known Exploited Vulnerabilities catalog as a federal patching mandate in 2021. Within a year, KEV remediation was the reference standard for enterprise vulnerability management. Auditors asked about it. Cyber insurers underwrote against it. Regulators in financial services cited it in examinations. None of those organizations were bound by the directive. All of them were measured against it.

The pattern is set to repeat. The practical question for enterprises in regulated industries is not whether examiners will ask about compromise assessment at patch time. It is when, and whether the answer will hold up.

Why the obvious approach fails

The instinct is to treat this as more incident-response work: when a KEV notification lands, send responders to investigate the affected asset. That approach fails for two reasons: the workload it creates, and the evidence it can no longer reach.

Take the workload first. Forensic triage is skilled work traditionally performed on demand, over days or weeks, on a small number of systems after an incident is declared. The directive demands it at vulnerability-management cadence, per asset, on a 72-hour clock that someone else starts, at whatever volume the KEV catalog produces. The baseline is already failing at the lighter workload. Verizon’s 2026 Data Breach Investigations Report found that only 26 percent of KEV vulnerabilities were fully remediated in 2025, down from 38 percent the prior year. That was the success rate for patching alone. The directive adds an investigation to the same window.

Then the evidence itself. A triage that begins when the KEV entry publishes is investigating the past with the tools of the present. The real question is not whether the system is compromised right now. It is whether it was compromised at any point during the exposure window, which may stretch back weeks or months before the patch existed. Point-in-time inspection at patch time cannot answer that. The evidence was either captured continuously across the window, or it is gone. On-demand forensics cannot reconstruct a window that has already closed.

This is the structural gap in most security architectures. Prevention controls block threats at the perimeter. Detection and response tools watch processes, identities, and network traffic in the present tense. Neither maintains a forensic record of the estate over time. When the directive asks whether an asset was compromised before you patched it, the existing stack has no layer that holds the answer.

The shift the directive forces

If the evidence cannot be gathered after the fact, it has to already exist when the alert lands. That is the shift the directive forces. Detecting compromise becomes continuous, not something that begins after a notification. A program built that way looks different from the IR model in a specific way, and that difference is what makes it workable at KEV cadence.

Call it Active Attack Detection. The aim is to find active attacks and signs of compromise before the encryption that finally makes an attack obvious, so that when a vulnerability lands on the KEV list, the compromise state of the affected systems is already known. Answering CISA’s question becomes a lookup, not a fresh investigation. It works because the analysis is agentless and runs against data the estate already produces, not by stationing responders on every asset. There is nothing to deploy per system and no investigation to staff on the clock, so the continuous record is maintained without the cost and alert volume that made the IR approach fail.

It has to cover the whole arc. An attack is not one event. It runs from persistence to lateral movement to exfiltration to encryption, and finally to the recovery you would count on afterward. Compromise has to be detected across all of it, in both the systems and the data, or the answer to whether you were already breached has a hole in it.

The same goes for recovery, and it is becoming urgent. Mandiant’s M-Trends 2026 found attackers going after the very systems companies use to recover after a breach, a pattern it calls recovery denial. Restore from a backup that still carries the attacker and you are back where you started, which is why the same continuous record has to prove the recovery point is clean before you rely on it.

The defensible position

The directive reduces to one question a security leader should be able to answer before being asked: for any asset we patched this quarter, can we prove it was not already compromised, and can we prove what we would recover from is clean?

A program that can produce that proof, continuously, is ahead of where federal policy just moved and ahead of where enterprise expectations are heading. A program that cannot has a documented gap that a federal directive now describes.

Compromise assessment is moving from something you do after an incident to something you run continuously. The programs that treat it that way now will not be the ones scrambling when the question arrives with a citation behind it.

---

Sources

[1] CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026

[2] CISA, CISA Issues New Directive Improving How Federal Agencies Prioritize the Mitigation of Cyber Vulnerabilities (issuing announcement), June 10, 2026

[3] CISA, BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, November 3, 2021

[4] CISA, Known Exploited Vulnerabilities Catalog

[5] Verizon, 2026 Data Breach Investigations Report, 2026

[6] Mandiant (Google Cloud), M-Trends 2026, 2026