CVSS for Medical Devices: Scoring, Scale, & 3.1 vs 4.0

A CVSS 3.1 Base score alone does not describe patient harm. Assess clinical consequences separately; CVSS 4.0 adds safety-related context but still does not replace that assessment.

Why this matters

The criticality of accurately assessing and communicating cybersecurity vulnerability severity in medical devices cannot be overstated, directly impacting patient safety, regulatory compliance, and market access. Inadequate or outdated scoring methodologies increase the risk of delayed submissions, market withdrawal, or even patient harm from exploitable vulnerabilities. While the FDA's Cybersecurity in Medical Devices Final Guidance dated February 3, 2026, accepts CVSS 3.1, it emphasizes the importance of understanding actual clinical impact. CVSS 4.0 introduces essential metrics like 'Safety' (MSI/MSA) and 'Automatable' (AU) that directly address the unique risks of medical devices, aligning more closely with standards like IEC 81001-5-1, ISO 14971, and AAMI TIR57 / ANSI/AAMI SW96:2023 regarding patient risk management. Relying solely on CVSS 3.1's general metrics can obscure the true patient safety implications of a flaw, potentially leading to underestimation of risk by both manufacturers and regulators. Accurately reflecting these nuances through CVSS 4.0 helps manufacturers demonstrate due diligence and a thorough understanding of their product's security posture, proactively addressing reviewer concerns about essential clinical performance and safety.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA Medical Device Safety Communications; FDA Cybersecurity resources for medical devices.

What does CVSS stand for and how does the scale work?

CVSS stands for the Common Vulnerability Scoring System. It is maintained by FIRST (the Forum of Incident Response and Security Teams) and gives every vulnerability a numeric score from 0.0 to 10.0. The CVSS scale is split into five bands:

CVSS scoring is built from metric groups. In CVSS 3.1 those are Base (the intrinsic flaw), Temporal (exploit maturity and fixes), and Environmental (your deployment). CVSS 4.0 renames Temporal to Threat and adds Supplemental metrics such as Safety and Automatable. The published NVD score is usually the Base score only, which is why a device team has to tailor it to its own design before it goes into a submission or VEX statement.

Why version matters at all

A CVSS number on its own is almost useless. A 7.5 means nothing without the vector string that produced it, and the vector string means nothing without knowing which version of the specification it was scored under. CVSS 2.0, 3.0, 3.1, and 4.0 all use overlapping but non-equivalent metrics. The same vulnerability can score 9.8 under 3.1 and 8.7 under 4.0 - or vice versa - without anything about the device changing.

For medical devices, this matters because:

• Submissions, VEX documents, and CVE entries persist for years.
• The same SBOM component may be scored by NVD (often 3.1), the upstream vendor (sometimes 4.0), and a third-party tool (mixed).
• A reviewer comparing your VEX to the public CVE record needs to see consistent versioning, not a 3.1 score next to a 4.0 vector.

Always emit the version explicitly. The 4.0 vector string starts with CVSS:4.0/, the 3.1 string with CVSS:3.1/. If your tooling strips the prefix, fix the tooling.

CVSS 3.1 vs 4.0 metric-by-metric

The base metric group is where most of the meaningful change happened. Here is the practical mapping:

The headline change for medical devices is the Safety metric. CVSS 3.1 has no field that says "this vulnerability could cause physical harm to a patient." Teams worked around this by inflating Availability or writing prose in the VEX justification. CVSS 4.0 makes safety a first-class concept under both the Subsequent System Integrity/Availability values (whose Environmental Modified counterparts MSI/MSA can take S for Safety) and the Supplemental Safety metric.

Reading a 4.0 vector string

A complete CVSS 4.0 base vector looks like this:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Parse it left to right:

• CVSS:4.0 - version. Reject anything that omits this.
• AV:N - Attack Vector Network. Reachable over the network.
• AC:L - Attack Complexity Low. No special conditions on the exploit itself.
• AT:N - Attack Requirements None. The target does not need to be in a specific state.
• PR:N - Privileges Required None.
• UI:N - User Interaction None.
• VC:H/VI:H/VA:H - Vulnerable system confidentiality/integrity/availability all High.
• SC:N/SI:N/SA:N - No impact on subsequent systems.

The Base SC/SI/SA metrics themselves only take High/Low/None. Safety is not a Base value: it appears as the Environmental Modified Subsequent System Integrity/Availability metrics (MSI:S / MSA:S), or as the Supplemental Safety (S) metric. Supplemental metrics, when present, are appended (e.g., /S:P/AU:Y/R:U/V:C/RE:M/U:Red).

FIRST recommends a standard metric order, but permits other orders. Validate metric names, values, duplicates, and required Base metrics before using a vector.

A worked example - same flaw, both versions

Consider a real-world-style finding: an unauthenticated command on the wired Ethernet interface of an infusion pump lets an attacker on the same hospital VLAN change the infusion rate. No user interaction required. Pump is in clinical use.

CVSS 3.1 base vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H

Base score: 10.0 (Critical). For this illustrative score, assume evidence establishes that the network service and affected pump resources are governed by different security authorities; different components alone do not establish Scope Changed.

What the score does not tell a reviewer:

• Is this exploit automatable across a fleet?
• Is patient safety affected, or "just" availability?
• Does the attacker need to be on a specific VLAN?

CVSS 4.0 base vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

Base score: 9.3 (Critical). Add the Environmental Modified Subsequent System metrics to carry the safety signal explicitly: /MSI:S/MSA:S raises the score to 9.8 (Critical). The vector now explicitly says:

• SI:H/SA:H plus MSI:S/MSA:S - patient safety impact on the subsequent system (the infusion delivery). Safety is not a Base SI/SA value; it is carried in the Environmental Modified metrics and the Supplemental Safety metric.
• AT:N - no special target state required.

Add supplementals: /S:P/AU:Y/R:I/V:C/U:Red - safety present, automatable, irrecoverable in the moment, concentrated value, urgent. Now a reviewer or a hospital risk officer can act on the score without reading three paragraphs of narrative.

The numbers are similar. The information content is not.

A second worked example - BLE pairing flaw on a continuous glucose monitor

Consider a different shape of finding. A continuous glucose monitor (CGM) wearable pairs with a patient's phone over Bluetooth Low Energy using Just Works pairing. An attacker within BLE range (roughly 10 meters), during the brief pairing window after the patient inserts a new sensor, can complete the pairing instead of the patient's phone and then receive glucose readings and suppress high/low alerts on the patient's phone. The sensor itself keeps operating; the patient stops seeing alerts.

Walk the 4.0 base metrics in order, picking each value deliberately.

1. Attack Vector (AV) = A (Adjacent). BLE is a short-range network protocol, not arbitrary internet reach. Not N, not P.
2. Attack Complexity (AC) = L (Low). Just Works has no cryptographic barrier; standard BLE tools complete the exchange.
3. Attack Requirements (AT) = P (Present). The attacker must be in range during the pairing window after a sensor change. That is a real precondition that 3.1's AC:H would have lumped in with cryptographic difficulty - 4.0 separates the two.
4. Privileges Required (PR) = N (None). No account, no prior access.
5. User Interaction (UI) = P (Passive). The patient inserts a sensor and initiates pairing on their phone, but takes no action that would let them notice the attacker. Not A (Active), not N.
6. Vulnerable System Confidentiality (VC) = H (High). Glucose telemetry from the sensor is fully disclosed.
7. Vulnerable System Integrity (VI) = N (None). The sensor's own readings are not modified.
8. Vulnerable System Availability (VA) = N (None). The sensor keeps measuring and transmitting.
9. Subsequent System Confidentiality (SC) = L (Low). The paired phone's CGM app loses confidentiality of the live data stream, but no other phone data is exposed.
10. Subsequent System Integrity (SI) = H (High); Environmental MSI:S conveys Safety. Suppressed hypoglycemia alerts can delay treatment of a low - this is a safety impact on the downstream system (the patient's alerting pathway), not a generic data-integrity loss.
11. Subsequent System Availability (SA) = H (High); Environmental MSA:S conveys Safety. The alert pathway is unavailable to the patient at the moment it matters.

Final base vector:

CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:L/SI:H/SA:H

Base score: 7.1 (High) under the official CVSS 4.0 calculator. Adding the Environmental MSI:S/MSA:S Safety values raises this to 8.6 (High).

Now add supplementals that a clinical reviewer will actually read:

• S:P - Safety: Present. Patient harm pathway exists.
• AU:N - Automatable: No. Each exploit requires physical proximity during a pairing window.
• R:U - Recovery: User. The patient regains alerting by re-pairing with their own phone.
• V:D - Value Density: Diffuse. Assume the exploited system provides limited resources to the attacker; victim count alone does not determine Value Density.
• U:Amber - Urgency: Amber. Real safety pathway, but bounded by proximity and per-victim effort.

For comparison, the same flaw under CVSS 3.1 scores CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N = 4.8 (Medium), with no field anywhere in the vector that says "this can delay treatment of a hypoglycemic event." The 4.0 vector both scores it higher and tells the reviewer why.

The point of the walk-through is not the final number. It is that each metric in 4.0 has a defensible answer grounded in the device's clinical context, and the supplementals carry the nuance the FDA reviewer is actually looking for.

A third worked example - unauthenticated firmware update on a networked patient monitor

Consider a bedside patient monitor that exposes a firmware update endpoint over the hospital VLAN. The endpoint accepts unsigned firmware images from any host on the same network segment and reboots into the new image without operator confirmation. The monitor displays ECG, SpO2, and NIBP, and feeds alarms to a central station. The same model is deployed fleet-wide across the hospital.

Walk the 4.0 base metrics in order.

1. Attack Vector (AV) = N (Network). The update endpoint is reachable across the routable hospital VLAN, not just an adjacent link. An attacker on any compromised endpoint in that segment (workstation, IoT printer, biomed laptop) can reach it.
2. Attack Complexity (AC) = L (Low). There is no signature check, no anti-replay, no ASLR-style defense to defeat. Push image, monitor reboots.
3. Attack Requirements (AT) = N (None). The endpoint is always listening. No service mode, no pairing window, no maintenance reboot required.
4. Privileges Required (PR) = N (None). The endpoint accepts unauthenticated POSTs.
5. User Interaction (UI) = N (None). No clinician has to do anything for the update to land.
6. Vulnerable System Confidentiality (VC) = L (Low). The attacker can read prior firmware and limited config, but PHI lives on the central station, not on the monitor itself.
7. Vulnerable System Integrity (VI) = H (High). Arbitrary firmware can be installed. Alarm thresholds, waveform processing, and the alarm-forwarding logic itself can be silently modified.
8. Vulnerable System Availability (VA) = H (High). The monitor can be bricked or held in a reboot loop, removing patient monitoring at the bedside.
9. Subsequent System Confidentiality (SC) = L (Low). The malicious firmware can exfiltrate the live waveform/vitals stream to the central station and onward, but not bulk PHI.
10. Subsequent System Integrity (SI) = H (High). The central station receives suppressed or fabricated alarms, which is a documented hazard in the device's ISO 14971 risk file (delayed clinician response to deterioration).
11. Subsequent System Availability (SA) = H (High). The alarm channel to the central station can be dropped silently, which is the worst clinical failure mode for a bedside monitor.

Final base vector:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:L/SI:H/SA:H

Base score: 9.3 (Critical) under the official CVSS 4.0 calculator. Adding the Environmental MSI:S/MSA:S Safety values raises this to 9.8 (Critical).

Supplementals a hospital risk team and FDA reviewer will actually read:

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, CVSS Score for Medical Devices: How to Calculate and Use It, and Medical Device Software Development: A Compliance Guide.

• S:P - Safety: Present. Multiple credible patient-harm pathways (silenced alarms, falsified vitals, bedside outage).
• AU:Y - Automatable: Yes. A single script can sweep the VLAN, identify monitors, and push firmware fleet-wide. This is the key field-action driver.
• R:U - Recovery: User. Recovery requires staff intervention to restore a known-good image; Irrecoverable would mean the system cannot be restored.
• V:C - Value Density: Concentrated. Use Concentrated only if the exploited system provides a concentrated set of resources to the attacker; fleet size alone does not establish this.
• U:Red - Urgency: Red. This illustrative provider urgency designation does not establish a field-action deadline; assess communication and mitigation timing against device-specific risk and applicable obligations.

For comparison, the same flaw under CVSS 3.1 scores CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H = 10.0 (Critical), but nothing in the vector flags fleet-wide automatability or the alarm-channel safety pathway. The 4.0 vector lands in the same severity band and tells the reviewer exactly which facts (AU:Y, MSA:S) drive the field-action recommendation.

A severe, automatable finding with plausible patient harm warrants prompt device-specific assessment. Section 524B requires out-of-cycle patches as soon as possible for critical vulnerabilities that could cause uncontrolled risks, but CVSS fields alone do not establish a reporting or patch deadline. Assess applicable 21 CFR 803 and 806 reporting separately.

CVSS 4.0 metric cheat sheet for medical devices

Use this as a desk reference when scoring a finding. To calculate the score and vector string as you go, open the free CVSS v4.0 calculator for medical devices. Each entry gives the plain-language question to ask, the values, and the medical-device-specific tell for which value to pick.

Base - Exploitability

Base - Impact on the vulnerable system (the device itself)

Base - Subsequent system (what the device is connected to)

Base - Safety vs similar impact metrics (the part teams get wrong)

The Safety metric (expressed via the Environmental MSI:S / MSA:S values and the Supplemental Safety S metric; there is no Base SS metric) is not a duplicate of Integrity or Availability. Use this decision rule:

• Use VI:H when the attacker can change a value on the device (dose, threshold, calibration), regardless of whether that change reaches a patient. VI describes the technical change.
• Use VA:H when the device stops working as a piece of equipment. VA describes the equipment outage.
• Use Safety (S) only when there is a credible pathway from the technical impact to physical harm to a patient or operator, per the device's own ISO 14971 hazard analysis. Safety describes the clinical consequence.

A change to a non-clinical setting may be VI:L or VI:H depending on the integrity impact; assess Safety separately. A viewer reboot's Availability and Safety ratings depend on the extent of disruption and clinical consequences. A 30-second pump lockup mid-infusion of a high-alert medication is VA:H and Safety, because the hazard analysis already flagged "interrupted infusion" as a harm.

If your risk file (ISO 14971) does not list the resulting harm, do not set Safety. Either the metric is wrong or your hazard analysis is incomplete. Either answer is one the FDA reviewer will follow up on.

Supplemental - what FDA reviewers actually read

Environmental - when to override base

Set Modified metrics (MAV, MVI, MSI, MSA, etc.) only when the deployed configuration legitimately changes the answer. A pump that ships with BLE enabled but is deployed BLE-disabled in a specific health system can drop MAV from A to P. Do not use environmental metrics to soften a base score for a generic submission. The FDA expects the base score to reflect the device as shipped.

Where CVSS 4.0 changes scores meaningfully for devices

Real differences you will see in practice:

• Devices requiring physical access or service mode often drop in 4.0 because AT:P (Attack Requirements Present) is now distinct from AC:H. 3.1 tended to over-score these.
• Pivot-style findings (compromise the BLE bridge, then control the pump) now score more honestly in 4.0 via Subsequent System metrics instead of the often-misused Scope flag.
• Safety-relevant denial of service can now score higher in 4.0 by setting the Environmental MSA:S, where 3.1 would cap at A:H.
• Fleet-wide worm-able flaws can be flagged with AU:Y Supplemental, which 3.1 has no way to express.

What the FDA actually expects in 2026

The February 3, 2026 premarket cybersecurity guidance does not mandate CVSS 4.0. It does require that vulnerability assessments capture patient safety impact, exploitability, and the basis for any "not affected" disposition. CVSS 4.0 simply gives you native fields for those things; CVSS 3.1 requires you to handle them in prose alongside the score.

For premarket submissions:

• A CVSS 3.1 base score with a clear safety analysis in narrative form is still acceptable.
• A CVSS 4.0 vector with Safety metrics populated is increasingly the cleaner answer, especially when the device has connected components.
• Mixing versions inside one document without labeling is the worst option. Always emit the version prefix.

For postmarket VEX:

• Whatever version your SBOM tooling produces, preserve the original vector string in the VEX vulnerability.scores[] array (or your format's equivalent) and add a Safety-aware re-score if the original was 3.1 and patient harm is in scope.
• When the upstream component publishes a 4.0 vector but your device-level analysis materially changes the score (because the component is not network-reachable in your design, for example), publish your tailored vector with environmental metrics rather than just dropping the base score.

Common scoring mistakes specific to medical devices

• Setting A:H to represent patient harm under 3.1. Availability is about the vulnerable component's availability. A pump that delivers a wrong dose is an integrity/safety failure, not an availability failure. Under 4.0, use VI:H/SI:H/SA:H, add the Environmental MSI:S/MSA:S when a safety pathway exists, and populate the Supplemental Safety metric.
• Calling everything AV:N. Use AV:A when exploitation is technically restricted to a logically or physically adjacent network; VLAN placement or a firewall alone does not establish AV:A. The Environmental group exists to tailor this.
• Leaving S:U everywhere in 3.1. In CVSS 3.1, Scope changes only when exploitation affects resources governed by a different security authority; patient-facing effects alone do not establish Scope Changed. 4.0's Subsequent System metrics make this explicit.
• Quoting NVD scores verbatim. NVD scores third-party components in isolation. A 9.8 on a library may be 4.2 in your device with the function not reachable. That is what Environmental metrics and VEX are for.
• Dropping the vector string from VEX. A bare number is not auditable. Always include the full vector.

When to move to 4.0

Move now if any of the following are true:

• You ship devices with safety-relevant network or wireless interfaces (pumps, ventilators, surgical robots, dialysis, anesthesia, monitors with active control).
• Your SBOM tooling already supports 4.0 output.
• You are preparing a 510(k), De Novo, or PMA where the cybersecurity section will be reviewed against the February 3, 2026 guidance.
• You operate a coordinated vulnerability disclosure program and want consistent, machine-parseable Safety signal.

Stay on 3.1 for now if:

• Your downstream consumers (hospitals, ISAOs) explicitly require 3.1.
• Your scanning and SCA tooling only emits 3.1 and the output cannot be enriched in your build pipeline.
• Even then, augment safety-relevant findings with a parallel 4.0 vector in the human-readable disclosure.

The realistic 2026 posture for most medical device manufacturers is dual: keep 3.1 as the machine-emitted baseline, add 4.0 with Safety populated for any finding that touches essential clinical performance.

Where this fits in your overall security program

CVSS is one input into vulnerability triage, not the whole answer. The full chain looks like:

1. SBOM identifies the component and version.
2. Vulnerability source (NVD, vendor advisory, ICS-CERT, internal pen test) produces the CVE and an initial CVSS vector.
3. VEX captures your device-specific disposition - affected, not affected, fixed, under investigation - with the rationale.
4. CVSS environmental and supplemental metrics tailor the score to your device.
5. Risk acceptance or remediation flows from the tailored score and the safety analysis, not from the base score in isolation.

If your VEX statements still look like { "vulnerability": "CVE-2024-XXXX", "score": 9.8, "status": "not_affected" } with no vector, no version, no justification linked back to your threat model, the score is not doing work - it is just decoration.

How Blue Goat approaches this

Blue Goat Cyber's medical device practice is led by engineers with CISSP, OSCP, and prior military red-team backgrounds. We treat cybersecurity documentation as design-controlled engineering output, not a submission template, every artifact (threat model, SBOM, security risk assessment, penetration test, labeling) traces back to a controlled requirement and a verified result.

Our engagements deliver the full Feb 3, 2026 guidance documentation set scoped to the device's risk profile, integrated with the existing IEC 62304 software lifecycle and ISO 14971 risk file. See our medical device cybersecurity services for the full scope. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

To see how we test for these weaknesses on real hardware, see our medical device penetration testing service.

FAQ

What does CVSS stand for?

What is a good or bad CVSS score?

Does the FDA require CVSS 4.0?

Can we keep using CVSS 3.1 in our submissions?

How does Automatable (AU) interact with patient risk?

How do we handle a CVE that the NVD has 3.1-scored as 9.8 but is not exploitable in our design?

Where do CVSS scores live in the FDA submission?

Our SBOM tool emits 3.1 scores from NVD. Do we just copy them into the submission?

Where to go next

CVSS scoring is one piece of an FDA-defensible vulnerability management program. Related reading:

• Threat modeling for medical devices in AAMI TIR57 / ANSI/AAMI SW96:2023 terms.
• SBOM and VEX construction for Section 524B submissions.
• Postmarket vulnerability management plans under the February 3, 2026 guidance.
• Pen testing methodology and how findings feed into your CVSS pipeline.

If you want help mapping your current 3.1 workflow onto a dual 3.1/4.0 posture with Safety metrics populated, that is exactly the kind of engagement we run with device manufacturers preparing for or responding to FDA cybersecurity review.

Related FDA & cybersecurity guides

• FDA Section 524B cybersecurity requirements explained
• SBOM vulnerability management for medical devices
• VEX document guide for FDA submissions
• FDA deficiency-letter response service
• STRIDE threat modeling for medical devices