Why do critical vulnerabilities sometimes deserve lower priority than medium ones?

Why This Matters for Security Teams

Severity labels are a useful starting point, but they do not tell a team what can actually be reached, exploited, or turned into business impact. A critical finding on a segmented lab host may be less urgent than a medium issue on an internet-facing service that handles customer data, privileged sessions, or payment workflows. The NIST NIST Cybersecurity Framework 2.0 pushes teams toward risk-based decisions instead of score chasing, because prioritisation should reflect exposure, impact, and operating context.

Security teams often get this wrong when they treat scanner output as an action plan rather than as one input into triage. That creates noisy backlogs, wasted remediation effort, and the dangerous habit of fixing the most alarming label instead of the most exploitable weakness. For practitioners, the real question is not whether a vulnerability is severe in the abstract, but whether it is reachable, weaponisable, and aligned to a likely attack path.

In practice, many security teams encounter the true cost of mis-prioritisation only after an exposed medium finding becomes the entry point for a breach, rather than through intentional risk-based triage.

How It Works in Practice

Effective prioritisation combines severity with exploitability, asset value, and control context. A critical issue should rise to the top when it sits on a high-value system, has an internet-facing path, or affects authentication, secrets, or privileged access. A medium issue may outrank it when it is reachable from a likely attacker path, sits on a production service, or exposes sensitive records.

Most mature programs layer vulnerability data with asset inventory, business criticality, threat intelligence, and detection coverage. That is where frameworks such as the NIST Cybersecurity Framework 2.0 and MITRE ATT&CK become useful operationally: CSF helps organise governance, risk, and response, while ATT&CK helps determine how a weakness maps to real attacker behaviour.

• Start with reachability: internet-facing, partner-facing, and internally lateral paths deserve higher weight.
• Overlay asset context: production, regulated data, identity systems, and privileged tools amplify risk.
• Check exploit maturity: known exploitation, public proof-of-concept code, and active threat use should move a finding up.
• Account for compensating controls: segmentation, WAF rules, EDR, and strict privilege can reduce practical urgency.
• Use remediation windows: patch quickly when exploitation is plausible, even if the CVSS label is only medium.

This approach also matters in identity-heavy environments, where a medium vulnerability on an admin portal or secrets store can create a faster path to credential theft than a critical flaw on a disconnected server. The right priority is the one that reflects attacker effort and likely blast radius, not the one that simply looks worst on paper. These controls tend to break down when asset inventories are stale and ownership is unclear because teams cannot confidently tie findings to real-world exposure.

Common Variations and Edge Cases

Tighter prioritisation often increases analyst effort, requiring organisations to balance faster closure of obvious issues against the overhead of contextual review. Best practice is evolving, and there is no universal standard for ranking every finding across every environment, which is why some teams still use CVSS as a first-pass filter and then apply business and exposure modifiers.

Edge cases matter. A critical vulnerability may be lower priority if the affected system is isolated, non-production, or protected by strong network controls and compensating detection. A medium issue may move up if it sits in a supply chain component, a remote management interface, or a workflow that touches privileged credentials. In cloud and hybrid estates, misconfiguration can make a moderate software flaw materially more dangerous than its label suggests.

For teams handling identity, PAM, or NHI governance, the same logic applies to secrets, service accounts, and agentic AI tool access. A medium issue that exposes a token, a signing key, or an automation identity can create a broader security problem than a critical issue with no viable path to execution. Current guidance suggests prioritising by attack path, data sensitivity, and business dependency rather than by score alone, and the OWASP Top 10 remains a helpful reminder that implementation flaws become dangerous when they are reachable.

In short, severity is a signal, not a decision. Organisations that mature beyond score-based triage usually reduce their backlog faster and defend better because they spend time on what can actually be abused.

Related resources from NHI Mgmt Group

• Why do lower-severity findings sometimes deserve higher priority than critical ones?
• How should security teams prioritise vulnerabilities when attackers chain medium-severity flaws?
• What breaks when access removal is treated as a lower priority than provisioning?
• Why do critical vulnerabilities remain open for so long in modern appsec programmes?