CVSS Scoring for Medical Devices: A Complete Walkthrough

Reviewed September 17, 2026

A CVSS score shows up everywhere in medical device security work: in CVE records, in SBOM vulnerability reports, in VEX statements, and in postmarket monitoring plans reviewed under FDA guidance. Teams often treat the number as the final answer, when it is actually one input among several that need to be combined before a decision gets made. Misreading CVSS, or treating it as equivalent to patient risk, produces both over-reactions to low-impact findings and under-reactions to findings that matter clinically. This post walks through each metric group, works through a real-style scoring example, and explains exactly where CVSS fits alongside ISO 14971, EPSS, and the CISA KEV catalog in a defensible vulnerability management process.

Why This Matters

CVSS is the most widely used vulnerability scoring standard, and it appears in nearly every CVE record, SBOM vulnerability feed, and vendor advisory a medical device manufacturer will encounter. The February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, expects manufacturers to describe how they assess and prioritize vulnerabilities across the product lifecycle, and CVSS is the common language most teams use to start that conversation.

The risk is treating CVSS as a complete answer rather than a starting metric. A 9.8 base score on a component that a device cannot reach through any exploitable path, or that would produce no patient harm if triggered, does not automatically mean urgent action. Conversely, a moderate score on a component tied to a life-sustaining function may deserve faster attention than the number alone suggests. Reviewers increasingly expect to see this reasoning made explicit: the CVSS score, the exploit-likelihood context, and the mapping to a documented harm severity category, together, rather than a spreadsheet of scores with no interpretation attached.

What Are the CVSS Metric Groups and What Do They Answer?

CVSS organizes its scoring into four metric groups, and each one answers a distinct question about the vulnerability. The Base metric group answers "how severe is this vulnerability in general, independent of any specific environment," and it is the only group that is mandatory and produces a score that persists in public CVE records. It covers exploitability factors like attack vector and attack complexity, and impact factors like confidentiality, integrity, and availability loss.

The Threat metric group, called Temporal in CVSS 3.1, answers "how does the severity change based on current real-world conditions," primarily whether exploit code is publicly available and whether a fix exists. The Environmental metric group answers "how does this vulnerability's severity change in my specific deployment," allowing a scorer to adjust base values and add organization-specific security requirements for confidentiality, integrity, and availability. The Supplemental metric group, introduced in CVSS 4.0, answers "what additional context helps a downstream consumer prioritize this," including a Safety metric directly relevant to medical devices, without changing the numeric score itself.

[KEY REQUIREMENT] Always publish the full vector string alongside any numeric score in internal reports, SBOM feeds, and VEX statements, since the number alone cannot be independently verified or recalculated by a downstream reader.

How Do You Read a CVSS Vector String?

A vector string is read left to right as a series of abbreviated metric codes and values separated by slashes, starting with the CVSS version. A CVSS 3.1 vector begins with CVSS:3.1/ followed by Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), and the three impact metrics for Confidentiality, Integrity, and Availability (C, I, A), each with a letter code such as N for Network, L for Low, or H for High.

A CVSS 4.0 vector follows the same slash-separated pattern but splits some metrics further, separating Attack Requirements (AT) from Attack Complexity and adding Vulnerable System and Subsequent System impact metrics, plus the optional Supplemental group that includes Safety (S), Automatable (AU), and others when scored. Reading the vector, rather than just the score, tells you exactly which conditions were assumed true when the number was calculated, which matters when the same CVE gets scored differently by NVD, a component vendor, and an internal team.

Worked Example: Scoring a Device Vulnerability

Consider a real-style scenario: a connected infusion pump's maintenance interface accepts unauthenticated configuration commands over the local network segment it sits on. An attacker on the same network segment, without credentials or user interaction, can send a command that alters the dosing configuration.

Scoring this under CVSS 3.1: Attack Vector is Adjacent Network (AV:A) because the attacker needs to be on the local segment, not the open internet. Attack Complexity is Low (AC:L) since no special conditions are needed beyond network access. Privileges Required is None (PR:N) and User Interaction is None (UI:N) since the command is accepted without authentication or a user action. Scope is Changed (S:C) if the compromised component can affect a different security authority, such as the dosing engine. Impact is High across Confidentiality, Integrity, and Availability (C:H/I:H/A:H) since dosing configuration integrity is directly at stake.

That produces a vector of CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which calculates to a Base Score of 9.3, Critical. Under CVSS 4.0, the same finding would additionally be scored for Safety impact, since altered dosing configuration has a direct patient safety consequence, and for Automatable, since the attack does not require unique manual interaction and could plausibly be scripted across multiple devices on a network.

[KEY REQUIREMENT] Document the assumptions behind each metric choice, especially Attack Vector and Scope, since these are the values most often disputed between a manufacturer's internal scoring and a third party's independent scoring of the same CVE.

Why Isn't a CVSS Score a Patient Risk Score?

A CVSS score is not a patient risk score because it measures technical severity in isolation from clinical context, deployment likelihood, and the specific harm a device failure could cause a patient. Two vulnerabilities can share an identical CVSS score while one affects a logging function with no patient-facing consequence and the other affects a therapy delivery function where an exploit could cause direct harm. The score cannot distinguish between them on its own.

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, Medical Device Software Development: A Compliance Guide, and When to Start Medical Device Cybersecurity.

ISO 14971 risk management works from a different axis entirely: severity of harm and probability of occurrence, evaluated specifically in the context of the device's intended use. Mapping a CVSS score into this framework requires a documented decision, not an automatic conversion, because the mapping depends on what the vulnerable component actually does within the device. See CVSS 3.1 vs 4.0 for Medical Devices for a detailed look at how the newer Safety and Automatable metrics narrow this gap without closing it entirely.

How Does CVSS Relate to EPSS and the CISA KEV Catalog?

CVSS, EPSS, and the CISA KEV catalog answer three different questions, and a defensible vulnerability management process uses all three together rather than relying on any one alone. CVSS answers "how severe would this be if exploited." The Exploit Prediction Scoring System, EPSS, answers "how likely is this to be exploited in the near term," using a probability score derived from observed exploitation activity across the broader vulnerability landscape.

The CISA KEV catalog answers a narrower and more certain question: "is this vulnerability already being actively exploited right now." A high CVSS score paired with a low EPSS score and no KEV listing suggests a theoretically severe but currently low-priority finding, while a moderate CVSS score paired with KEV listing demands immediate attention regardless of the base severity number. Postmarket monitoring plans reviewed under the FDA's guidance are expected to show this kind of layered reasoning rather than a single-metric triage rule.

How Does the FDA Expect CVSS to Be Used in Postmarket Reporting and VEX?

The FDA does not mandate a specific CVSS version or a specific scoring threshold that triggers action, but the February 3, 2026 final guidance expects manufacturers to describe a coherent, repeatable method for assessing and prioritizing vulnerabilities across the postmarket period. CVSS scoring, when used, needs to be documented consistently, with version, vector string, and scoring rationale available for review rather than a bare number.

In a VEX statement, the expectation is that a manufacturer states clearly whether a component's vulnerability affects the product, and if it does, what the status and remediation plan are. Including the full CVSS vector string alongside the VEX status gives a downstream user, whether a hospital, a reviewer, or another manufacturer building on the component, the ability to independently verify the severity claim rather than trusting an unexplained label.

How Blue Goat Cyber Approaches This

Blue Goat Cyber scores vulnerabilities found during medical device penetration testing with full vector strings and documented scoring rationale, then maps each finding into the device's ISO 14971 risk management file rather than delivering a standalone severity list. This scoring work feeds directly into postmarket cybersecurity services, where CVSS, EPSS signals, and KEV status are combined into a documented triage process suitable for a monitoring plan a reviewer can actually evaluate. The goal is a scoring record that a manufacturer can defend years later, not just a number generated at the time of testing.

Frequently Asked Questions

Which CVSS version should medical device manufacturers use?

The FDA does not mandate a specific version, so either CVSS 3.1 or CVSS 4.0 is acceptable as long as the version is stated clearly and the full vector string is published. CVSS 4.0 is increasingly preferred for safety-relevant findings because it includes Safety and Automatable metrics that 3.1 cannot express directly.

What does a CVSS score of 0 mean?

A CVSS score of 0 typically results from a vulnerability with no meaningful impact under the scored metrics, for example a finding with no confidentiality, integrity, or availability impact at all. It does not mean the finding is irrelevant to document, since context outside CVSS, like a compliance requirement, may still call for a fix.

Can two people score the same vulnerability differently?

Yes, this happens often, usually because of differing assumptions about Attack Vector, Scope, or the deployment environment. This is why documenting the reasoning behind each metric choice, not just the final score, matters for consistency and for defending the score during a review.

Is CVSS required for FDA submissions?

CVSS is not explicitly required by name, but the FDA's guidance expects a documented, repeatable vulnerability severity assessment methodology, and CVSS is the most widely accepted way to satisfy that expectation. Whatever methodology is used, it needs to be applied consistently and explained clearly.

How often should CVSS scores be reassessed after initial scoring?

Scores should be reassessed whenever new threat intelligence changes the Threat or Environmental metrics, such as public exploit code becoming available or the device's deployment context changing. Static scores that are never revisited across the product's postmarket life do not reflect the current threat environment reviewers expect to see addressed.

Does a high CVSS score always mean urgent action for a medical device?

Not automatically. Urgency depends on combining the CVSS severity with exploit-likelihood data such as EPSS or KEV status and with the component's actual role in patient-facing device functions, documented through the risk management file.

CTA

If your team needs help scoring vulnerabilities consistently and mapping them into a risk management file that holds up under FDA review, contact Blue Goat Cyber to discuss your device's postmarket vulnerability management process.