What four questions does CISA use to rank how urgent a vulnerability is?

CISA's directive BOD 26-04 ranks how urgently a vulnerability must be fixed using four questions: is the asset exposed to the public internet, is the flaw on the Known Exploited Vulnerabilities list, can an attacker automate the whole attack, and does exploitation give partial or total control. The directive binds federal agencies. Anyone can borrow the logic.

TL;DR

• The four variables are asset exposure, KEV status, exploit automation and technical impact.
• They replace a single severity number with four plain yes or no style questions.
• The directive applies to US federal civilian agencies. Other organizations may choose to borrow the method, but are not bound by it.
• You can build a simple version for your own team in under an hour.

Definition: BOD 26-04. Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," was issued by the US Cybersecurity and Infrastructure Security Agency (CISA) on June 10, 2026. A binding operational directive is a compulsory direction to federal executive branch civilian agencies. It sets how fast they must fix vulnerabilities, based on risk.

What does the directive say, in plain words?

The directive states a goal in one sentence: focus patching efforts on the areas of highest risk rather than treating all vulnerabilities and systems equally. In its own words, it aims to efficiently prioritize high-risk vulnerabilities for timely action, while deferring action against low-risk vulnerabilities.

That is a notable shift in tone. Older advice often said "patch everything." This directive says that time is limited, attackers are quick, and a ranking is more honest than a promise to fix all.

The directive revokes two earlier directives, BOD 19-02, which dealt with vulnerabilities in internet-accessible systems, and BOD 22-01, which created the Known Exploited Vulnerabilities (KEV) catalog and told agencies to fix those flaws. It folds them into one approach. CISA says the urgency of each fix is set by four variables, and the remediation timelines are in a table that is informed by SSVC, a public vulnerability decision method.

Two limits are worth stating plainly. The directive applies to federal civilian executive branch systems. It says that, unless a procurement contract directs otherwise, it does not apply to contractors. So you should not describe it as a rule that applies to every company. And this post does not repeat the exact day counts in the directive's table, since the source is the place to read them and it can be updated. You can read the full text and the timelines on the CISA page listed in the sources.

What are the four questions?

Question 1: Asset exposure. Is the vulnerable asset publicly exposed? The directive defines publicly exposed as any agency-owned or managed resource accessible to unauthenticated or untrusted entities via public networks such as the internet, regardless of where it physically sits. If any one method of checking says it is exposed, the answer is yes. The idea is simple: a flaw on a system the whole world can poke at is more urgent than the same flaw on a system tucked away.

Question 2: KEV status. Is the flaw on CISA's Known Exploited Vulnerabilities catalog? CISA calls the catalog the authoritative source of vulnerabilities that have been exploited in the wild, and tells organizations to use it as an input to prioritization. A listing means someone has seen attackers use this flaw in practice. That is much stronger evidence than a theoretical rating.

Question 3: Exploit automation. Can an adversary automate all the steps needed to exploit it? This idea comes from the SSVC framework, where it is called "Automatable." SSVC defines it as whether attackers can reliably automate the first four steps of the attack chain: reconnaissance (finding targets), weaponization (building the attack), delivery (sending it), and exploitation (making it work). If yes, an attacker can hit many targets at once with little effort. SSVC's guidance adds a cautious default: when nothing is known, assume the answer is yes.

Question 4: Technical impact. After exploitation, does the adversary gain partial or total control? The directive defines total control as complete control over how the software behaves, including the case where the exploit reliably reveals login credentials. Partial control means limited control, limited information exposure, or a low chance of total control. It notes that a denial of service attack, where the attacker can disrupt but not take over, is a form of partial control.

The directive says CISA publishes the answers to KEV status, exploit automation and technical impact for every CVE ID through services such as its Vulnrichment program. For exposure, it points agencies to CISA's internet exposure reduction guidance.

Why are four questions better than one number?

A single score hides which part drives the worry. Four answers show the reason, so teams can discuss the actual issue.

Take two flaws with the same severity number. One is listed on KEV, hits a public service, and is easy to automate. The other is not listed, sits on an internal system, and needs hands-on effort. A single number gives them the same rank. Four answers separate them at once.

The four questions also change over time in ways the directive allows for. It says the timeline for each asset is dynamic as facts change. For instance, it notes that removing a system from the internet is a valid mitigation, because it changes the exposure answer from yes to no and moves the required timeline back. If a flaw is newly added to KEV, the timeline shortens. This is the same principle as in your own decisions: facts move, so answers move.

How can a company borrow the four questions?

You can build a simple version without any government role. Treat it as your own policy, not as compliance with the directive. Here are steps.

1. Make a four column sheet. Columns: exposed, on KEV, automatable, impact (partial or total).
2. Fill the exposure column from your asset list. Tag each service as public or internal. If you cannot tell, mark it public until you can show otherwise.
3. Pull KEV status for each finding. The catalog can be downloaded as a file in CSV or JSON, so this can be automated.
4. Pull automation and impact from the CVE record where available. If the record has no answer, use the advisory text and mark your answer as a judgment.
5. Define your own response times. Write rules such as "exposed and on KEV: fix first, and review logs." Decide the other cells with your own leaders. Do not copy the federal day counts as if they were yours.
6. Review the rules once a year. CISA says it reassesses its own timelines once per fiscal year. A yearly review of your rules is a reasonable habit.

What does it look like on three alerts?

The alerts are invented for illustration.

• Alert 1: web server flaw. Exposed: yes. On KEV: yes. Automatable: yes. Impact: total. This is the hottest cell pattern. Fix first and check for signs of misuse.
• Alert 2: library flaw in an internal reporting tool. Exposed: no. On KEV: no. Automatable: no. Impact: partial (the tool can crash). This can wait for the normal cycle.
• Alert 3: library flaw in a public API. Exposed: yes. On KEV: no. Automatable: yes. Impact: partial. Public and easy to automate, so it ranks above Alert 2 even though the impact is limited. Fix in the near term.

Notice that the four answers explain themselves. A manager can read the row and understand why Alert 1 outranks Alert 3.

What can Safeguard do for this kind of ranking?

Safeguard brings several of these signals together. It scans dependencies and builds an SBOM, the list of everything in a product. Reachability analysis and an exploitability check show whether a finding can be reached and used today, with evidence. Zero-day discovery matches new advisories to the versions in your projects and ranks them. Asset discovery helps you keep the exposure column honest, and policies and gates let you turn your own ranking rules into checks.

Autonomous remediation with fix pull requests exists but is off by default, with every category on Manual. You can try a free scan at gold.safeguard.sh/scan.

For more on this directive and related signals, see CISA BOD 26-04 remediation timelines and forensic triage, what the KEV catalog is and CVSS, EPSS and KEV explained.

Try it yourself

Click through it at your own pace, or open it full screen. The demo checks each finding against four questions of its own and shows evidence for every answer. Compare that style of reasoning with the four CISA variables above.

Quick check

Sources

• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA Known Exploited Vulnerabilities Catalog
• SSVC: Automatable decision point
• SSVC: Technical Impact decision point

Last reviewed: 19 October 2026.