Why “Critical” Does Not Always Mean “Patch First”

"Critical" is a powerful word. It shows up in red on dashboards, triggers escalations, and pulls engineers away from planned work.

It also gets applied to a large share of findings. When a substantial portion of a backlog is labeled critical, the label stops helping anyone decide what to do first.

What "critical" usually means

In most tools, "critical" comes from the CVSS base score, typically 9.0 or above. That score reflects intrinsic properties: the vulnerability can be exploited over a network, needs little or no privilege, needs no user interaction, and has high impact.

Those are real concerns. But the base score is deliberately environment-independent. It doesn't consider whether the software is running, whether it is reachable, whether anyone is exploiting it, or how important the affected system is.

That's why two "critical" findings can represent very different levels of risk.

Severity versus local risk

Consider a few situations that all show a critical label.

• A vulnerable library sits in a build tool that runs only in an isolated CI environment and never ships to production.
• A vulnerable package is listed in a repository's manifest, but it's a development dependency excluded from the production build.
• A vulnerable service runs on an internal host reachable only from a small management network, with no evidence of exploitation.
• A vulnerable component runs on an internet-facing application server, and the vulnerability is listed in CISA KEV.

Same label. Very different urgency. Only the last one clearly deserves to jump the queue.

Meanwhile, a "high" or even "medium" vulnerability that is actively exploited on an exposed, business-critical system may matter more than all of the first three.

What drives local risk

Responsible prioritization adds context to severity.

Exploitation evidence. Known exploitation in the wild is among the strongest signals available. KEV, vendor advisories, and threat intelligence provide it. EPSS offers a probability estimate.

Exposure. Can an attacker reach the vulnerable component? Internet-facing systems carry more risk than isolated ones.

Asset criticality. What's the impact of compromise? Identity systems, production data stores, and deployment infrastructure matter more than test environments.

Presence and reachability. Is the vulnerable component actually deployed? Is the vulnerable code path used?

Compensating controls. Is there a verified control reducing the risk while a patch is pending?

Prioritizing responsibly

Downgrading a critical finding shouldn't be casual. It should be evidence-based and documented.

A responsible approach:

• Start with the label, not the conclusion. Critical findings get looked at promptly, even if the result is lower urgency.
• Use defined rules. Apply consistent criteria for exploitation, exposure, and criticality, rather than case-by-case debates.
• Record the reasoning. "Lowered priority: development dependency, not present in production image; verified via SBOM" is defensible. "Not important" isn't.
• Keep a deadline. Lower priority means a later date, not no date.
• Re-evaluate on change. If exploitation appears, exposure changes, or the component starts shipping, priority goes back up automatically.

The cost of treating all criticals equally

When every critical gets the same emergency treatment, several things happen.

Teams burn effort patching low-risk findings under pressure, often outside normal change processes. Genuinely dangerous vulnerabilities wait in the same queue. Engineers learn that "critical" doesn't mean what it says, and urgency loses its power.

That last effect is the most damaging. The label is only useful if people trust it.

Communicating it

Leadership and auditors often expect severity-based reporting. Keep severity visible. Then show how your prioritization uses it alongside exploitation and exposure, and report on how quickly you remediate the findings that are high risk in your environment. That tends to be a more convincing story than a raw count of open criticals.

The principle

"Critical" tells you a vulnerability deserves attention. It doesn't tell you where it belongs in your queue. Patch order should reflect local risk: what's exploited, what's exposed, and what matters most to the business. Get that right, and the truly urgent work gets done first.