CISA BOD 26-04: urgent patching and rapid forensic triage belong together

On 14 October, CISA added vulnerabilities in Cisco Secure Email Gateway and PAN-OS, among others, to its Known Exploited Vulnerabilities catalogue. Both entries specify 17 October as the deadline for US federal agencies and mark forensic triage as required. This is a practical example of the new model: an urgent fix stops further exploitation, while a rapid evidence review asks whether an attacker arrived before it was applied.

The basis is Binding Operational Directive 26-04, published by CISA on 10 June, and its maintained implementation guidance. The directive is binding on the covered US Federal Civilian Executive Branch agencies. It does not impose obligations on companies elsewhere.

Breachroad’s conclusion: organisations outside that scope can still use CISA’s logic as an operating model. The most valuable feature is not a particular number of days, but the combination of four facts: whether an asset is exposed, whether the vulnerability is actually exploited, whether exploitation can be automated, and how much control compromise provides.

Priority is not determined by CVSS alone

BOD 26-04 bases urgency on asset exposure, inclusion in the KEV catalogue, exploit automation and the technical impact of exploitation. That differs from a queue ordered solely from the highest CVSS score downwards.

Two servers with the same CVE may require a different sequence. An internet-facing email gateway with confirmed attacks and a path to system compromise is a different task from an isolated lab instance. The assessment still needs evidence. If an organisation cannot reliably establish whether an asset is internet-accessible, it lacks the information needed to prioritise.

CISA requires ongoing identification and tagging of publicly exposed assets. A company can achieve a similar outcome by joining its inventory to external attack-surface discovery, service ownership and environment information. A device list without exposure and accountability is not useful enough during a three-day response window.

Preserve evidence first, but do not leave the door open

CISA’s implementation guidance divides rapid triage into six stages. The times are recommended best practices rather than separate mandatory deadlines for each step:

1. scope the issue and activate the team within the first two hours;
2. preserve and collect evidence within 2–24 hours;
3. apply critical patches and stabilise services during the same 2–24 hour window;
4. contain and control systems within 6–24 hours;
5. analyse evidence within 24–48 hours;
6. make an escalation decision and produce a report within 48–72 hours.

The stages overlap by design. A team should not wait for a multi-day investigation to finish while an internet-facing system remains exploitable. Nor should it restart and update an appliance without thought if that operation will erase memory, logs or other necessary evidence.

The correct sequence depends on the situation: reduce exposure quickly, capture the most volatile and relevant data, deploy the fix and then verify the resulting state. A coordinator needs to balance security, service continuity and evidence requirements across the technical actions.

What a minimum triage report looks like

CISA suggests recording an incident and response timeline, findings framed as “who, what, where and when”, containment already performed, and recommended next steps. The result should support one of three decisions: no identified evidence of compromise with heightened monitoring, a confirmed incident requiring full response, or continued suspicion requiring further analysis.

“No evidence found” is not mathematical proof that no intrusion occurred. The report should state which sources were available, the period they covered and what could not be checked. An appliance retaining only a few hours of logs provides different confidence from correlation with an independent SIEM, identity system and network-flow data.

The report need not be long. It must enable the business owner to decide whether the service can continue, what risk remains and who makes the next decision.

A business model: three roles and one fallback channel

An internal procedure benefits from three named roles. The technical owner understands the release, architecture and safe change process. The incident lead protects evidence, scope and escalation. The business owner assesses the effect of downtime, data exposure and communications.

The team also needs a communications channel independent of the potentially compromised environment. If the incident concerns email, the chat and contact list should not depend exclusively on the same identity or infrastructure.

A simple exercise begins when CISA adds a flaw in a critical gateway, the vendor confirms attacks and the company has 72 hours to reduce risk and make a credible incident decision. Participants identify assets, owners, evidence to preserve, the sequence of changes and what the board report must say. Teams can rehearse those decisions in an incident-response tabletop workshop and our cybersecurity training for organisations.

Our vulnerability management guide covers the broader lifecycle. Applying the model outside the US federal scope, the proposed role split and the exercise scenario are Breachroad recommendations; the directive’s legal scope, prioritisation factors and triage stages come from CISA’s materials.