CVSS 3.1 vs 4.0 for Medical Devices: Safety & Automatable Metrics

Most medical device security teams are still pasting CVSS 3.1 base scores into VEX statements and calling it a day. That works until a reviewer asks "what's the Safety impact?" - and 3.1 literally has no field to answer that question.

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.

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 (which can be set to S for Safety when human harm is in scope) 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.

If safety is in scope, you may see SI:S or SA:S instead of H/L/N, indicating human safety impact. Supplemental metrics, when present, are appended (e.g., /S:P/AU:Y/R:U/V:C/RE:M/U:Red).

The metric order in the vector is fixed by the spec. If a vector arrives with metrics in a different order or with values that are not in the spec, the score is invalid - do not paste it into a VEX.

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). Scope Changed because the vulnerable component (network service) impacts the pump function (different security authority).

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:S/SA:S

Base score: 9.5 (Critical). But now the vector explicitly says:

• SI:S/SA:S - patient safety impact on the subsequent system (the infusion delivery).
• 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) = S (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) = S (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:S/SA:S

Base score: 7.7 (High) under the official CVSS 4.0 calculator.

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. One victim per exploit, no fleet-wide payoff.
• U:Amber - Urgency: Amber. Real safety pathway, but bounded by proximity and per-victim effort.

For comparison, the same flaw under CVSS 3.1 would score roughly CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N = 4.2 (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) = S (Safety). 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) = S (Safety). 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:S/SA:S

Base score: 9.4 (Critical) under the official CVSS 4.0 calculator.

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

• 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:I - Recovery: Irrecoverable in the moment. Restoring a known-good image requires biomed staff at each bedside.
• V:C - Value Density: Concentrated. One attacker pivot inside the network owns every monitor of this model in the facility.
• U:Red - Urgency: Red. Same-day field communication and a compensating network control are warranted while a signed-firmware patch is prepared.

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, CVSS Scoring for Medical Devices: A Complete Walkthrough, and Medical Device Software Development: A Compliance Guide.

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 = 9.6 (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 two facts (AU:Y, SA:S) drive the field-action recommendation.

This example also illustrates a pattern worth naming: when AU:Y, S:P, and SI:S/SA:S all line up on a base score above 9.0, you are looking at a finding that almost always belongs in a coordinated disclosure and a same-cycle postmarket update under the Feb 3, 2026 guidance, regardless of installed-base size.

CVSS 4.0 metric cheat sheet for medical devices

Use this as a desk reference when scoring a finding. 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 (SS on the subsequent side, and MSI:S / MSA:S on the modified/environmental side) 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 (display brightness, log verbosity) is VI:H but not Safety. A reboot of a diagnostic-only viewer is VA:H but not Safety. 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 SA: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:S/SA:S and the Supplemental Safety metric.
• Calling everything AV:N. A device only reachable on a clinical VLAN behind a firewall is AV:A (Adjacent) in most realistic threat models. The Environmental group exists to tailor this.
• Leaving S:U everywhere in 3.1. Almost every realistic medical device finding has a Scope Changed dimension because the network component is rarely the patient-facing component. 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 cybersecurity deficiencies after our submission, we resolve them at no additional cost.

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