CVSS 3.1 vs 4.0 for Medical Devices: Vector Strings, Scoring, and What FDA Reviewers Want

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.

Key Takeaways

• CVSS 3.1 remains acceptable to the FDA; 4.0 is not mandated but is increasingly expected for safety-relevant findings.
• 4.0 splits Attack Vector and Attack Requirements, which materially changes scores for devices that need physical access or specific configurations.
• 4.0 adds Safety (S) impact metrics under both Subsequent System (MSI/MSA) and Supplemental groupings - this is the single biggest reason to adopt it for medical devices.
• The Automatable (AU) metric directly maps to fleet-wide patient risk on connected devices.
• Vector strings must be read, not just scored; the prefix tells you the version and the metric ordering tells you what was actually assessed.
• VEX and postmarket disclosures should include the full vector string, not just the numeric score.

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:

Concern	CVSS 3.1	CVSS 4.0	Why it matters for medical devices
How the attacker reaches the device	Attack Vector (AV)	Attack Vector (AV)	Same metric; values Network/Adjacent/Local/Physical unchanged.
Conditions required beyond reach	Attack Complexity (AC) conflated with prerequisites	Attack Complexity (AC) + Attack Requirements (AT)	4.0 separates "the exploit itself is hard" from "the target must be in a specific configuration." Cleaner for devices that require service mode, paired phone, or specific firmware revision.
Privileges held	Privileges Required (PR)	Privileges Required (PR)	Unchanged conceptually.
User interaction	User Interaction (UI) None/Required	User Interaction (UI) None/Passive/Active	4.0 distinguishes "user just has to be logged in" from "user has to actively click something." Matters for clinician-facing UIs.
Scope change	Scope (S) Changed/Unchanged	Removed; replaced by Subsequent System metrics	3.1's Scope was widely misunderstood. 4.0 explicitly scores impact to a Subsequent System (e.g., the gateway pivoted into the device).
Impact on the vulnerable component	C/I/A (None/Low/High)	VC/VI/VA (None/Low/High)	Renamed for clarity - Vulnerable system Confidentiality/Integrity/Availability.
Impact on downstream systems	Implicit via Scope	SC/SI/SA (None/Low/High)	Explicit. A vulnerable BLE bridge with High SI on the pump it controls now scores honestly.
Patient-harm potential	No native metric	MSI/MSA Safety values + Supplemental Safety (S)	The reason to adopt 4.0 for medical devices.
Exploit automatability	Not represented	Automatable (AU) Yes/No	A worm-able flaw on a fleet of 50,000 infusion pumps scores differently than a one-off.
Recovery / Value Density / Response Effort / Provider Urgency	Not represented	Supplemental group	Optional context that reviewers and ISACs increasingly want.
Threat intel adjustment	Temporal (E/RL/RC)	Threat (Exploit Maturity only)	Simpler, more honest.
Environmental	CR/IR/AR + modified base	Modified base + MSI/MSA + CR/IR/AR/SC/SI/SA	Richer environmental tailoring, including modified subsequent system impact.

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.

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.

FAQs

1. Does the FDA require CVSS 4.0? No. The February 3, 2026 premarket cybersecurity guidance does not specify a CVSS version. It requires that vulnerability assessments capture exploitability and patient safety impact, which 4.0 makes easier but 3.1 can still convey in narrative form.

2. Can we keep using CVSS 3.1 in our submissions? Yes, as long as the safety impact analysis is explicit in the narrative and the vector string is included. Just labeling a finding "9.8 Critical" is not sufficient regardless of version.

3. Will NVD score new CVEs in 4.0? NVD has been gradually adding 4.0 vectors to new entries while preserving 3.1 vectors. Expect both for the foreseeable future.

4. How do we score a vulnerability that requires service mode? Under 3.1, this typically pushed AC:H. Under 4.0, use AT:P (Attack Requirements Present) and keep AC:L if the exploit itself is straightforward once in service mode. This usually produces a more honest score.

5. What is SI:S vs SA:S? Subsequent System Integrity Safety vs Subsequent System Availability Safety. Use SI:S when the integrity of a downstream system that interacts with patients is compromised (wrong dose delivered). Use SA:S when the availability of a downstream safety function is lost (alarm disabled, pump halted mid-infusion).

6. How does Automatable (AU) interact with patient risk? A worm-able or scan-and-exploit flaw on a fleet of devices is a fundamentally different patient-safety event than a targeted one-off. AU:Y is a strong signal to a hospital risk team and to FDA postmarket reviewers.

7. Do we score the SBOM component or the device? Both. Preserve the upstream component's score and publish your device-tailored score using environmental metrics. They answer different questions.

8. How do we handle a CVE that the NVD has 3.1-scored as 9.8 but is not exploitable in our design? VEX status not_affected with a justification (e.g., vulnerable_code_not_present, vulnerable_code_not_in_execute_path) and, ideally, a tailored CVSS vector showing the modified base. Bare denial without rationale is what gets follow-up questions.

9. Should pen-test findings be CVSS-scored? Yes. Internal pen test findings without a CVE still benefit from a CVSS vector for prioritization and for inclusion in the postmarket vulnerability management plan. Use 4.0 if at all possible since you control the scoring.

10. Where do CVSS scores live in the FDA submission? They appear in the vulnerability assessment, the SBOM/VEX outputs, and the residual risk analysis. They should be consistent across all three. Mismatched scores between the SBOM addendum and the risk analysis are a common deficiency-letter trigger.

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 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.