CVSS for Medical Device Product Risk: Flawed, but Still Essential

If you have a hammer, everything is a nail

Bottom line

CVSS is flawed, and everyone in the field knows it. But it’s the tool that security professionals rely on and medical device manufacturers (MDMs) have to use: suppliers, vulnerability databases, CISA advisories, and FDA all speak CVSS. The danger is twofold: not understanding its limits, and relying on it as the only basis for decisions. CVSS was built to score the severity of software vulnerabilities in the traditional enterprise IT environment, not to prioritize product risk, and if it’s all you have (or use), its gaps will leave you hanging exactly where patient safety is at stake.
Our position: use CVSS to characterize a vulnerability, especially how exploitable it is, but don’t treat the total CVSS score as your risk score. Assess impact in terms of patient harm, as FDA’s postmarket cybersecurity guidance does. As NVD puts it:
“The Common Vulnerability Scoring System (CVSS) is a method used to supply a qualitative measure of severity. CVSS is not a measure of risk.”
— NVD, “Vulnerability Metrics”; https://nvd.nist.gov/vuln-metrics/cvss

Why consistent risk scoring matters

MDMs need a risk scoring method that is reliable, scales across development activities and a large volume of vulnerabilities, and is acceptable to FDA.
Vulnerabilities enter at every stage of the SDLC, and each stage has its own discovery method: threat modeling in design, SBOM and scanning for the supply chain, code review and testing in development, penetration testing before release, sampling in manufacturing, and monitoring postmarket.
No single method is suitable across all development activities, so using a uniform approach to scoring across activities matters. It keeps results consistent, reduces training and tooling needs, and lets a risk score transition between phases, e.g., a design risk identified in threat modeling that ends up being fixed in development.

Why you still need CVSS

CVSS is the de facto standard for good reasons:

• Component vulnerabilities arrive pre-scored. NVD, other databases, and scanners use CVSS, so every SBOM finding has a predetermined score (which may need to be adjusted, but it is a given starting point).
• Product advisories use it. NVD and CISA (formerly ICS-CERT) score finished-product vulnerabilities with CVSS.
• It avoids guessing at probability. Exploitability, as a subscore of CVSS, is more defensible than likelihood for security risks with little historic and field data.
• Regulators expect it. FDA’s postmarket cybersecurity guidance names CVSS as a way to assess Exploitability.

CVSS isn’t optional, so the real question is how to use it without getting caught out by its gaps. That starts with knowing exactly where it falls short.
It helps to separate two ways of using CVSS. Using all of CVSS means treating the total score, Exploitability plus Impact, as the measure of risk; that is where most of the flaws below bite. Using CVSS selectively means taking its Exploitability metrics (attack vector, attack complexity, privileges required, user interaction) as the likelihood input and assessing Impact separately, for example as severity of patient harm on your ISO 14971 scale. FDA’s postmarket cybersecurity guidance takes the second approach: it points to CVSS for Exploitability and pairs it with patient-harm severity in a two-dimensional matrix to decide whether a risk is controlled.

Where CVSS will leave you hanging

1. It was built for enterprise IT

The CVSS SIG’s experts first rated real IT vulnerabilities on a five-point scale (none, low, medium, high, critical). Deloitte & Touche LLP then fit formulas to those ratings (CVSS v3.1 Specification, section 7.5) and mapped the results onto a 0.0–10.0 scale, which implies a higher precision than the initial SIG ratings support.
Further, nothing shows that an IT-calibrated model carries over to support medical device product security decisions. In fact, the absence of such proof should give us pause.

2. It adds instead of multiplying

CVSS v3 mathematically adds Exploitability (0–3.9) and Impact (0–6) to a total 0–10 score. Common risk analysis methodologies, including ISO 14971 or NIST SP 800-30, multiply likelihood by severity. With addition, cutting Impact by one point lowers the total by one point regardless of Exploitability; with multiplication, the same cut does far more for a high-exploitability risk, which is where it should count. Think of a rectangle: lengthening one side grows the perimeter linearly, no matter the length of the other side. But the area grows in proportion to both sides. Risk estimation should behave like area calculation.

3. It’s biased toward Impact

Impact has a wider range (0–6) than Exploitability (0–3.9) and fewer metrics (3 vs. 4), so each Impact metric change moves the total score more. That makes it hard to show the benefit of controls that reduce Exploitability, which is how most device risks are mitigated. This and the additive problem above apply to the total score; they largely go away when Exploitability is used on its own.

4. Impact measures data, not patients

CVSS scores confidentiality, integrity, and availability of data. Admin access to a folder of screen savers or to radiation dose settings can score the same. Environmental Metrics help, but they answer IT questions (internet-facing server? cafeteria menu or patient record?), and it’s unclear whether Modified Base Metrics should reflect the deployment environment or the state after mitigation.

What the evidence shows

In cybersecurity we deal with a high degree of uncertainty and that is reflected in the precision of our risk forecasts. Inherently, cybersecurity risks are difficult to predict and any risk methodology should be treated as such - i.e., risk assessments provide guidance but within a wide range of uncertainty. For example, a recent study showed that only 2.3% of vulnerabilities scored high or critical (CVSS 7.0 and above) were observed in exploitation attempts in a given month, while medium-severity CVEs made up 28% of vulnerabilities actually exploited. The total severity score alone doesn’t predict what gets exploited, which is another reason to assess Exploitability and Impact separately.

CVSS v4: better, but not a fix

FIRST now says outright that CVSS Base scores “should not be used alone to assess risk.” v4 also improves on v3: it scores downstream (“subsequent system”) impact separately, replacing the confusing Scope metric; adds Attack Requirements; trims Threat Metrics to Exploit Maturity; separates supplier and consumer roles more clearly; and adds Supplemental Metrics, including for Safety.
But for product risk, v4 is harder to work with. Scores come from an expert-derived lookup table of MacroVectors rather than separate formulas for Exploitability and Impact, so they’re harder to reproduce in your own processes and tools. That makes the selective approach harder in v4: the Exploitability metrics are still in the vector, but there is no calculated Exploitability sub-score to carry forward. And Supplemental Metrics, including Safety, appear in the vector but don’t change the score.

Our recommendation

Use CVSS, but don’t rely on it alone:

• Use CVSS selectively. Keep supplier and NVD scores as the record of each vulnerability’s intrinsic properties and use the Exploitability metrics as your likelihood input, but don’t treat the total score as risk.
• Assess Impact as patient harm. Rate severity on your ISO 14971 scale and combine it with Exploitability in a risk matrix, as FDA’s postmarket guidance does. Add clinical and deployment context, and apply it consistently from threat model to SBOM to testing to postmarket. OWASP’s Risk Rating Methodology and CSA Singapore’s guide are useful models.
• Document the bridge. Show FDA how a CVSS score flows into your product risk decision and your ISO 14971 analysis, recognizing that an MDM is a CVSS consumer for components and a supplier for its own advisories.

CVSS’s constraints are well known. The teams that get caught out aren’t the ones that use it; they’re the ones that use nothing else.
Join us live. On Monday, November 16 at 11:00 AM PT / 2:00 PM ET, Axel Wirth and Seth Carmody will walk through what's actually getting devices cleared and refused, including anonymized case data from recent FDA reviews, five checks to run before you file, and how a universal risk register keeps every score tied to a defensible risk decision. Register now →

Resources

Common Vulnerability Scoring System v3.1: User Guide; https://www.first.org/cvss/v3.1/user-guide
Common Vulnerability Scoring System version 4.0: User Guide; https://www.first.org/cvss/user-guide
Common Vulnerability Scoring System v3.1: Specification Document; https://www.first.org/cvss/v3.1/specification-document
Dos and Don’ts of Using CVSS Scores in Cyber Risk Management; https://www.fairinstitute.org/blog/dos-and-donts-of-cvss-scores
OWASP Risk Rating Methodology; https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
CSA Singapore: Supplementary references; https://www.csa.gov.sg/legislation/supplementary-references/
CSA Singapore: Guide To Conducting Cybersecurity Risk Assessment For Critical Information Infrastructure; Feb 2021; https://isomer-user-content.by.gov.sg/36/016e3838-a9e5-4c6e-a037-546e8b7ad684/Guide-to-Conducting-Cybersecurity-Risk-Assessment-for-CII.pdf
NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments; Sep 2012; https://csrc.nist.gov/pubs/sp/800/30/r1/final
FDA: Postmarket Management of Cybersecurity in Medical Devices; Dec 2016; https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
Cyberkach: Beyond Vulnerability Severity: Exploring How Exposures Combine to Amplify Cyber Risk; Sep 2026; https://storage.googleapis.com/media_storage_cyberkach/report-files/1791463152580-Beyond-Vulnerability-Severity-Exploring-How-Exposures-Combine-to-Amplify-Cyber-Risk-Cyberkach.com.pdf