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.

Table of Contents

• Key Takeaways
• Why version matters at all
• CVSS 3.1 vs 4.0 metric-by-metric
• Reading a 4.0 vector string
• A worked example - same flaw, both versions
• A second worked example - BLE pairing flaw on a continuous glucose monitor
• A third worked example - unauthenticated firmware update on a networked patient monitor
• CVSS 4.0 metric cheat sheet for medical devices
• Where CVSS 4.0 changes scores meaningfully for devices
• What the FDA actually expects in 2026
• Common scoring mistakes specific to medical devices
• When to move to 4.0
• Where this fits in your overall security program
• Where to go next
• Related FDA & cybersecurity guides

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 80001-1, ISO 14971, and AAMI TIR57 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.

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.

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.

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

Metric	Plain-language question	Values	Medical-device tell
AV Attack Vector	Where does the attacker have to be?	N / A / L / P	N for cloud backend or routable LAN. A for BLE, Wi-Fi, same VLAN. L for USB / service port with shell. P for needing to physically open the device.
AC Attack Complexity	Does the exploit need special conditions the attacker cannot control?	L / H	H only if there is a real defense the attacker must defeat (ASLR, signed firmware, anti-replay). Quirky timing alone is not H.
AT Attack Requirements	Does the target system have to be in a specific state?	N / P	P when service mode, pairing window, or maintenance reboot is required. This used to get crammed into 3.1's AC:H.
PR Privileges Required	What account does the attacker need on the target?	N / L / H	N for unauthenticated. L for clinician/operator role. H for biomed/admin or service account.
UI User Interaction	Does a human have to do something for the exploit to land?	N / P / A	P Passive: user just uses the device normally (opens an app, accepts a pairing prompt they always accept). A Active: user must be tricked into a specific non-routine action.

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

See also: FDA IDE Cybersecurity Requirements: 2026 Submission Guide, MQTT Vulnerabilities in Connected Medical Devices: FDA Risks, Controls, and Deficiency Patterns, and SBOM Diffing and CVE Correlation: The Postmarket Workflow the FDA Expects.

Metric	Plain-language question	Values	Medical-device tell
VC Vuln. Confidentiality	Can the attacker read data on the device?	H / L / N	H if PHI, credentials, or therapy parameters are exposed. L for non-clinical telemetry.
VI Vuln. Integrity	Can the attacker change data, firmware, or therapy on the device?	H / L / N	H if dose, alarm thresholds, firmware, or calibration can be modified. This is the metric that drives the safety story.
VA Vuln. Availability	Can the attacker stop the device from working?	H / L / N	H if device crashes, locks, or must be power-cycled mid-procedure.

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

Metric	Plain-language question	Values	Medical-device tell
SC / SI / SA Subsequent C/I/A	Once the device is owned, what happens next door?	H / L / N	Set non-N when compromise pivots to the EHR, gateway, PACS, or a fleet of identical devices. This replaces 3.1's Scope toggle.
SS Safety (Subsequent)	Can the pivot harm a patient on a different system?	N / P / S	S Safety when the pivot causes IEC 62304 hazardous-situation impact on another device or care workflow.

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

Metric	When to set it	What it tells the reviewer
S Safety	A clinical hazard exists. Mirrors SS:S / MSI:S / MSA:S.	This is a patient-safety issue, not just an IT issue.
AU Automatable	A worm, mass scanner, or one-click tool can hit your installed base.	Fleet risk. Drives field-action urgency.
R Recovery	Automatic / User / Irrecoverable.	Tells the reviewer how a clinical site gets back to safe operation.
V Value Density	Diffuse (one victim per exploit) vs Concentrated (many).	Helps the reviewer judge attacker economics for your specific device.
U Urgency	Red / Amber / Green / Clear.	Your own recommendation on field-action timing. Reviewers weigh this against safety and automatability.

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.

FAQ

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

Common CVSS 4.0 mistakes for medical devices (and how to avoid them)

11. We set Safety (S) any time the device touches a patient. Is that right?

No, and it is the most common 4.0 mistake we see. Safety means a credible pathway to physical harm that your ISO 14971 hazard analysis already recognizes. 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 "interrupted infusion" is already a documented harm. If the harm is not in your risk file, fix the risk file or drop the Safety flag, do not invent the linkage in the CVSS vector.

12. When should VI:H be paired with Safety, and when should it stand alone? Use VI:H whenever the attacker can change a value on the device (dose, alarm threshold, calibration, firmware). Add Safety (SI:S or supplemental S) only if that specific change can plausibly harm a patient per the hazard analysis. Changing display brightness or log verbosity is VI:H without Safety. Changing insulin basal rate is VI:H with Safety. The two metrics answer different questions: VI is the technical change, Safety is the clinical consequence.

13. We tend to score every availability loss as VA:H with Safety. What is the cleaner rule? Tie Safety to clinical timing, not to the fact that the device went down. A bench analyzer that crashes between batches is VA:H and not Safety. The same analyzer crashing mid-run on a stat troponin is VA:H and Safety. The CVSS vector should reflect the realistic worst-case clinical context that the device is labeled for, not the most benign one.

14. We collapsed AC:H and AT:P in our 4.0 vectors because they "feel similar." What breaks? You inflate scores. AC:H is reserved for defenses the attacker must defeat (anti-replay, signed firmware, ASLR). AT:P is reserved for required states (service mode, pairing window, maintenance reboot). A flaw that only fires in service mode but has no real defense is AC:L / AT:P, not AC:H. Reviewers reading your vector backwards will catch the conflation.

15. We softened our base scores using environmental metrics for the submission. Is that defensible? No. Environmental metrics describe a specific deployment, not the device as shipped. The base vector in your premarket submission must reflect the device's default configuration. Use Modified metrics only in customer-specific risk communications or in postmarket VEX statements where the deployment is known. Using them to lower a submission-level score is a deficiency-letter trigger.

16. We left supplemental metrics blank because they "don't affect the score." Why does that matter? Supplementals (S, AU, R, V, U) are exactly what FDA reviewers and hospital risk teams read to triage your finding. A VI:H flaw with AU:Y (automatable) and S:P (safety) is a field-action conversation. The same flaw with AU:N and S:N is a routine patch. Leaving supplementals blank forces the reviewer to assume the worst case or to ask. Always populate them.

17. Our SBOM tool emits 3.1 scores from NVD. Do we just copy them into the submission? No. Preserve the upstream 3.1 vector for traceability, then publish a device-tailored score (3.1 modified, or a fresh 4.0 vector) that reflects whether the vulnerable code is reachable in your design, the deployed attack surface, and the realistic safety pathway. A blanket "9.8 Critical, not affected" without a tailored vector and a VEX justification is the single most common scoring deficiency we see in deficiency letters.

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.

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

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.