How we set fix-by deadlines
Every vulnerability page tells you how quickly to fix it: one deadline if the software is reachable from the internet, and one if it is only used internally. This page explains how those deadlines are worked out.
Four questions, not one score
A severity score says how bad a flaw could be. It does not say how likely it is to hurt you, so a long list sorted by score still leaves you guessing what to fix first.
In June 2026 CISA, the US government's cyber defence agency, changed how US federal agencies decide what to patch first, in Binding Operational Directive 26-04. Instead of a score, the deadline comes from four yes-or-no questions:
- Can it be reached from the internet? Only you know this. In StackFlag you set it once for each stack.
- Is it known to be exploited? From CISA's catalogue of vulnerabilities attackers are actively using.
- Can an attack be fully automated? If so, attackers can scan for it and hit many targets at once.
- Does it give an attacker full control? Rather than partial access, such as reading some data.
The deadlines
Each combination of answers has a fixed deadline. There is no score to add up. "Check for compromise" means patching is not enough on its own: look for signs that someone has already got in.
| Internet-facing | Known exploited | Automatable | Full control | Fix within |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | 3 days and check for compromise |
| Yes | Yes | Yes | No | 3 days |
| Yes | Yes | No | Yes | 3 days and check for compromise |
| Yes | Yes | No | No | 14 days |
| Yes | No | Yes | Yes | 3 days |
| Yes | No | Yes | No | 14 days |
| Yes | No | No | Yes | 14 days |
| Yes | No | No | No | 60 days |
| No | Yes | Yes | Yes | 3 days and check for compromise |
| No | Yes | Yes | No | 14 days |
| No | Yes | No | Yes | 14 days |
| No | Yes | No | No | 14 days |
| No | No | Yes | Yes | 60 days |
| No | No | Yes | No | 60 days |
| No | No | No | Yes | At next upgrade |
| No | No | No | No | At next upgrade |
Deadlines as published in the directive's remediation table.
Where the answers come from
Whether a vulnerability is known to be exploited comes from CISA's Known Exploited Vulnerabilities catalogue. Whether an attack can be automated, and how much control it gives, come from CISA's own assessments, which cover most recent vulnerabilities and many older ones.
When CISA has not assessed a vulnerability, we estimate those two answers from the technical details behind its severity score, and the page labels them "estimated". Our estimates agree with CISA's about nine times in ten, and when they differ they lean towards a shorter deadline rather than a longer one.
What this is, and what it is not
We follow the directive's model because it is a clear, well-tested way to decide what to fix first. It is guidance, not a compliance service: the directive itself only binds US federal agencies, and only you know how your systems are set up and what else protects them.
If the software in a stack is partly internet-facing and partly internal, treat the stack as internet-facing. The shorter deadline is the safer one.
Using it in StackFlag
Every vulnerability page shows both deadlines. Tell us where each of your stacks runs, and every flag on it shows the one deadline that applies, so you can work through your flags in order of urgency rather than by score.
In your alerts
- Order by deadline. An email alert can list the most urgent flags first, across all your stacks, instead of grouping by stack and score.
- Only what is due soon. An alert can send only flags due within 3, 14 or 60 days. A stack you have not set is treated as internet-facing, and a flag we cannot give a deadline yet is always sent, so nothing is left out for lack of information.
- When a deadline gets shorter. If a stack is set to alert you when a vulnerability is updated, you also hear when its deadline tightens - for example when attackers start exploiting it.