Why do high-severity vulnerabilities still get missed in healthcare risk decisions?

Why This Matters for Security Teams

High-severity findings are easy to over-prioritise when risk teams rely on CVSS-style scores without asking whether the vulnerable asset is reachable, externally exposed, or tied to a critical workflow. In healthcare, that shortcut can hide the issues most likely to disrupt scheduling, claims, clinical integrations, or patient-facing portals. Risk decisions need to combine technical severity with exposure, dependency, and operational impact, not treat the score as the full answer.

This problem is amplified by the density of non-human identities in modern environments. NHI Management Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and its Ultimate Guide to NHIs — Why NHI Security Matters Now shows why overlooked service accounts and API keys often sit on the paths that matter most. NIST guidance also reinforces that prioritisation should be tied to asset context and control effectiveness, not just defect severity, through the NIST Cybersecurity Framework 2.0.

In practice, many security teams encounter the real consequence of a missed high-severity vulnerability only after an outage, denial-of-service event, or data exposure has already affected care delivery rather than through intentional prioritisation.

How It Works in Practice

Practitioners should treat severity as one input to triage, then weight it against reachability, internet exposure, identity privilege, and business dependency. A critical flaw on a back-office server that is segmented and monitored may be less urgent than a medium-severity issue on a patient portal, third-party integration, or scheduling API that is directly reachable and linked to clinical operations. That is especially true where secrets, service accounts, and machine-to-machine trust chains can turn one weakness into broad lateral movement. NHI Management Group’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both show how excessive privilege and weak lifecycle management make the wrong asset look harmless until it is abused.

A practical healthcare prioritisation flow usually includes:

• Confirm whether the vulnerable system is internet-facing, partner-facing, or isolated.
• Map the dependency to clinical, revenue, or patient-data workflows.
• Check whether compromise would expose shared secrets, service accounts, or tokens.
• Evaluate whether an attacker could chain the issue into identity escalation or lateral movement.
• Use policy and asset context at triage time, not only after remediation planning.

NIST guidance on control assessment in the NIST SP 800-53 Rev. 5 Security and Privacy Controls supports this kind of contextual review, because the same technical flaw can produce very different outcomes depending on the environment. These controls tend to break down when organisations lack an accurate inventory of exposed assets and connected NHIs, because the most dangerous dependencies are then invisible to triage.

Common Variations and Edge Cases

Tighter severity-based prioritisation often reduces noise, but it also increases the risk of missing lower-scoring issues that sit on high-value or highly reachable paths, so organisations have to balance analyst efficiency against operational exposure. Best practice is evolving here, and there is no universal standard for a single scoring formula that works across all healthcare estates.

Legacy clinical systems are a common exception. Some are difficult to patch quickly, are externally reachable through vendor connections, or depend on long-lived machine credentials that expand the blast radius of a modest flaw. In those cases, a lower-severity vulnerability may deserve urgent treatment because compromise would expose sensitive workflows or shared identities. The same logic applies to environments with poorly governed service accounts, where excessive privilege can turn a routine software defect into a broader incident.

For that reason, teams should not separate vulnerability management from NHI governance. The operational question is not only “How bad is the flaw?” but also “What can the attacker touch if this system, token, or service account is abused?” That framing is consistent with current guidance in healthcare risk programs and with the broader security expectations reflected in the The 2024 ESG Report: Managing Non-Human Identities, which found that 72% of organisations have experienced or suspect a breach of non-human identities. When visibility is weak, the scoring model will look precise while still missing the systems most likely to matter.

Related resources from NHI Mgmt Group

• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why does identity matter more when vulnerabilities are discovered faster than they can be patched?