What breaks when medical device teams rely on CVSS alone?

CVSS alone breaks prioritisation because it treats theoretical severity as if it were equivalent to real-world exposure. In healthcare, that leads teams to spend time on vulnerabilities that cannot be reached or exploited while leaving reachable systems underprotected. Effective programmes combine exploitability data, reachability, and criticality to focus effort where patient impact is most likely.

Why This Matters for Security Teams

CVSS is useful as a starting point, but it is not a prioritisation strategy. In medical device environments, the difference between a high score and a patient-relevant risk can be enormous. A vulnerability in a lab-adjacent support system may score highly while being unreachable, while a lower-scored issue in a network-exposed device interface may create immediate operational and safety impact. That gap is exactly why practitioners need context from asset criticality, network exposure, compensating controls, and exploit activity.

This is especially important where devices support clinical workflow, telemetry, or remote servicing. The NIST Cybersecurity Framework 2.0 pushes teams to connect risk analysis with business outcomes rather than treat scoring in isolation. NHIMG research on the Ultimate Guide to NHIs also shows why this matters operationally: 97% of NHIs carry excessive privileges, which can turn a medium-severity flaw into a practical path to broader compromise. In practice, many security teams discover the mismatch only after a clinician-facing system or service account has already been used as the shortest route into a regulated environment.

How It Works in Practice

Effective prioritisation starts by separating score from exposure. CVSS tells you how severe a vulnerability might be in the abstract. It does not tell you whether the affected component is internet-facing, reachable from a medical network, protected by segmentation, or embedded in a system that can be safely patched only during a maintenance window. In healthcare, those distinctions matter because downtime, patient safety, and device certification constraints often shape remediation more than the score itself.

Teams usually get better results when they layer CVSS with exploit intelligence, asset criticality, and environmental context. That means asking whether the issue is actively exploited, whether an attacker needs local access, whether a service account or API key can reach the vulnerable component, and whether the device supports compensating controls such as network isolation or application allowlisting. The attack surface question is not just about code. It also includes credentials, tokens, and service identities that can bridge into device management planes.

Useful implementation patterns include:

• Tag devices by clinical criticality, safety impact, and service dependency.
• Combine CVSS with reachability and exposure data from scanners, CMDBs, and network tooling.
• Escalate issues with known exploitation activity before high-scoring but dormant findings.
• Track non-human identity paths, because service accounts and API keys often create the real blast radius.

Current guidance suggests aligning this process with risk-based control selection rather than chasing raw vulnerability counts. That approach is consistent with NIST CSF risk management and with NHIMG guidance on NHI visibility and lifecycle control in the Ultimate Guide to NHIs. These controls tend to break down when device inventories are incomplete and service identities are unmanaged, because teams cannot reliably tell which findings are actually reachable.

Common Variations and Edge Cases

Tighter vulnerability filtering often reduces noise, but it also increases the need for high-quality telemetry and disciplined exception handling. Teams must balance faster remediation of exploitable issues against the reality that many medical devices have long patch cycles, vendor approval requirements, or limited maintenance windows.

There is no universal standard for this yet, so best practice is evolving. Some organisations use EPSS, exploit intelligence, and asset criticality to override CVSS. Others add patient-safety impact tiers or clinical service dependency mapping. The main edge case is legacy equipment that cannot be patched promptly: in those environments, compensating controls such as segmentation, strict access paths, and monitoring become the primary risk reducers.

Identity also changes the picture. If a device management console, update service, or integration workflow depends on overprivileged NHIs, then the vulnerability is not confined to the software flaw itself. It can become an access-control problem. That is why NHIMG highlights excessive privilege as a recurring exposure pattern, and why NIST’s risk framing is more useful than score-only triage. Teams that rely on CVSS alone tend to overestimate dormant weaknesses and underestimate exploitable paths inside connected care environments.

Related resources from NHI Mgmt Group

• What breaks when teams rely on periodic access certification alone?
• What breaks when security teams rely on prompt filtering alone?
• What breaks when teams rely on runtime secret retrieval alone?
• What breaks when cloud teams rely on IAM alone?