Medical Device Risk Assessment using CVSS

A medical device risk assessment using CVSS (Common Vulnerability Scoring System) is normally right on target for exposing the seriousness of a cybersecurity vulnerability.

But a CVSS score alone won't tell you how much risk that same vulnerability poses to your device or its patients.

Enter FDA's 2016 postmarket cybersecurity guidance. This identifies CVSS v3.0 FDA as one way to assess vulnerability exploitability.

More recently, its February 2026 premarket guidance calls for an exploitability-focused assessment but doesn't require a specific scoring method.

But there's another piece to the risk assessment puzzle.

The MITRE CVSS rubric helps bridge that gap by adapting vulnerability scoring to medical devices and clinical settings.

Want to know how these tools work together and where the results belong in your FDA cybersecurity documentation?

Keep reading.

What CVSS measures

The Common Vulnerability Scoring System is an open standard maintained by FIRST, the Forum of Incident Response and Security Teams.

Its value is this:

It gives you a way to rate the severity of a cybersecurity vulnerability by assigning a score from 0 to 10. It also goes a step further by providing a vector string showing how that score was calculated.

CVSS v3.x also assigns a severity rating: None, Low, Medium, High, or Critical.

CVSS v3.0 and v3.1 use three groups of metrics:

• Base metrics describe the vulnerability itself, including how an attacker might exploit it, what access they'd need, and the potential impact on confidentiality, integrity, and availability.
• Temporal metrics account for factors that can change over time, such as whether exploit code is available, whether a fix exists, and how confident you are in the vulnerability report.
• Environmental metrics let you adjust the score to reflect your device and its operating environment, including how important confidentiality, integrity, and availability are in that setting.

It should be pointed out that FIRST also released CVSS v4.0 in November 2023 with a revised scoring structure. But because FDA guidance and the MITRE CVSS rubric reference v3.0, this article focuses on CVSS v3.x. Whichever version you use, identify it in your risk management procedure and apply it consistently.

What FDA says about CVSS

How difficult is it to predict whether someone will exploit a vulnerability?

Very.

Even FDA admits this in its discussion of CVSS in Section VI.A of its postmarket cybersecurity guidance because so many factors come into play such as availability of hacking tools and the overall complexity of attacks.

This is why FDA recommends using a medical device vulnerability scoring system instead of trying to calculate vulnerability exploitation.

Take the Common Vulnerability Scoring System v3.0. This modality deep dives into potential impacts and the availability of working exploits, as well as:

• How an attacker could gain access
• The difficulty of the attack
• Permissions needed
• Whether someone must interact with the device

Here's the distinction worth remembering: FDA doesn't require CVSS. It's one way to assess vulnerabilities. And while CVSS measures technical impacts, it doesn't tell you how badly a patient could be harmed. That requires a separate safety risk assessment.

FDA's February 2026 premarket guidance makes a similar distinction in Section V.A.2. Cybersecurity threats don't follow predictable failure rates, so assessing exploitability makes more sense than estimating the probability of an attack. The guidance doesn't specifically name CVSS but refers readers to the postmarket guidance for methods of evaluating exploitability.

For more on this distinction, see our complete guide to FDA cybersecurity risk assessment.

Why plain CVSS misfits medical devices

Big insight: CVSS was developed for traditional IT systems, not medical devices.

Yes, that's meaningful because suppose a server crashes and makes business operations difficult to impossible. That's far different than jeopardizing a patient's life due to a ventilator crashing. Nevertheless, both could receive the same CVSS availability score.

Fortunately, a lot of thought has gone into this resulting in the MITRE rubric addressing three shortcomings:

• Impact metrics stop at the device. CVSS measures system damage, not potential patient harm.
• Scope is hard to apply. It's difficult to define system boundaries when devices connect to apps and cloud services.
• Scores drift between analysts. Two engineers may score the same vulnerability differently without medical device-specific guidance.

The MITRE rubric helps address these gaps and makes scoring more consistent, not to mention putting a smile on the face of medical device manufacturers.

The MITRE Rubric for Applying CVSS to Medical Devices

MITRE developed this rubric for FDA with help from medical device manufacturers, healthcare organizations, and safety and cybersecurity experts.

FDA qualified version 0.12.04, dated September 2019 and revised October 2020, as a Medical Device Development Tool.

What does this mean to you?

FDA has already reviewed the MITRE rubric and found it suitable for its intended purpose. Manufacturers who use it within that purpose don't have to prove the tool itself is reliable. But they still need to show they've applied it correctly.

So, to apply correctly, here's what you do:

• Questions for each metric. The rubric is easy to follow because it walks you through questions about each CVSS metric, starting with those that affect the score most. You might be able to save time here, because some answers let you skip questions that don't apply.
• Decision flow diagrams. Useful flowcharts help you follow the scoring process. If a diagram and the written instructions disagree, all you need to do is follow the text.
• An extended vector. Answers that don't affect the CVSS score are still recorded using codes beginning with "X." Overall, this is beneficial because X preserves details about the device for later risk analysis.
• Worst case when unknown. Don't know an answer? Just mark it "Unknown." The rubric assigns the value that produces the highest score.
• Patient safety flags. A PIPS (Potential Impact to Patient Safety) marker signals that you should examine possible patient harm and whether the issue may need to be reported. In the bigger picture, this is a very important function.
• A group exercise. You should be certain your most experienced team members are involved. We have come to discover that scoring works best with people who understand cybersecurity, device engineering, patient safety, clinical workflows, and IT integration.

Follow the fields and you should wind up with a standard CVSS v3.0 score and vector, plus the extended vector and your answers to the rubric's questions. This works out well because that gives you both a score others can understand and a record of how you arrived at it.

How to score a vulnerability with the rubric

You can think of scoring a vulnerability with the rubric in terms of four sections:

1. Identifying the weakness
2. Scoring it
3. Evaluating patient harm
4. Deciding what to do next

Identifying the weakness

What you want to do is isolate the vulnerability by means of scoring the root cause and not the attack. Essentially this is about scoring each vulnerability on its own prerequisites.

Next, work through the base metrics with the rubric. Answer all questions. Remember to answer "Unknown" or "Not Answered" rather than guessing or skipping so an FDA reviewer recognizes your attempt to answer all the questions.

We recommend recording the extended vector next and possible PIPS flags.

Scoring it

You want to score the temporal metrics through a combination exploiting code maturity, remediation level, and reporting confidence over time. Pay attention to Section V.A.2 of the premarket guidance: If a penetration tester exploited a vulnerability, "the ability of a threat actor to exploit that vulnerability is likely to increase over the device lifecycle."

You will also want to map the score to an exploitability level. You should record the thresholds you use. Postmarket guidance features high, medium, and low exploitability.

Evaluating patient harm

FDA reviewers put a lot of weight on this area. They want you to assess severity of patient harm separately. The postmarket guidance provides ISO 14971-style qualitative levels as one approach: Negligible, Minor, Serious, Critical, and Catastrophic. Keep in mind, CVSS does not give you this. Your hazard analysis does.

Deciding what to do next

Expect the postmarket guidance to talk about a matrix of exploitability against severity of patient harm, and asks for a binary determination for each vulnerability using a documented process tailored to the product and its essential performance.

Decide controlled or uncontrolled.

Tip 1: Uncontrolled risk gets remediation. Any finding with a safety impact becomes a hazardous situation in the ISO 14971:2019 file, with the vulnerability as its cause.

Tip 2: Device settings can change how serious a vulnerability is. If that's the case, score each setup separately, then use the highest score or a documented method for combining them.

Where CVSS fits across the lifecycle

CVSS is a vulnerability tool. It fits some risk assessment contexts better than others.

Context	What you are scoring	How CVSS fits
Premarket threat model	Threat scenarios from the model, before any vulnerability exists	Poorly on its own. Section V.A.2 allows a worst-case exploitability assumption with controls, or a justified exploitability across the lifecycle. Use the rubric's questions as a checklist for that justification.
Premarket testing and SBOM findings	Known vulnerabilities from penetration testing, static analysis, and third-party components	Well. Score with the rubric, assume exploitability will rise, and design out anything in CISA's Known Exploited Vulnerabilities catalog rather than scoring it.
Postmarket signals	A disclosed or discovered vulnerability in a fielded device	This is what the postmarket guidance describes. Score exploitability, rate severity of harm, decide controlled or uncontrolled, and follow the remediation and communication path.

The MITRE and MDIC threat modeling playbook makes a related point about every scoring mechanism, including CVSS: a security score should not be the sole criterion for accepting a risk. Treat it as an input to the safety risk assessment, and keep the reasoning that produced the score, because that reasoning is what helps others understand the decision. See our threat modeling post for cloud-connected devices and the STRIDE threat modeling guide for how the threat model feeds the risk assessment.

Common mistakes

Confusing CVSS with patient risk. A CVSS score isn't the probability of patient harm. Don't use it to calculate ISO 14971 P1 or P2 estimates.

Relying on the NVD score. That score doesn't account for how your medical device is used or configured. Use the MITRE rubric to score the vulnerability in your device's setting. Keep the NVD score for reference.

Confusing an attack with a vulnerability. A software flaw accessible through Bluetooth and USB is still one vulnerability. Don't count it twice just because attackers have two ways in. Assess each access route when scoring.

Assuming the CVSS score tells the whole story. A low score doesn't always mean low patient risk. A high score doesn't automatically mean uncontrolled risk. You also need to consider potential patient harm and existing safeguards.

Mixing CVSS versions. Scores from v3.0, v3.1, and v4.0 aren't directly comparable. Stick with the version your rubric requires and document it.

Ignoring temporal metrics. A proof-of-concept exploit that becomes a public tool changes the picture. Rescore when the world changes, not only when the device does.

What goes in the submission

FDA wants to understand your decision-making process, not just see a collection of scores. There are three things FDA's premarket guidance, Section V.A.2, insists for documentation:

• How you score cybersecurity risks before and after mitigation.
• What criteria you use to decide whether a risk is acceptable.
• How you transfer cybersecurity risks that could affect patients into the safety risk assessment.

All three live in the Cybersecurity Risk Management Report described in Section V.A and Appendix 4.

That said, be prepared to document the scoring procedure. You need to explain the method your team followed covering topics such as:

• Which CVSS version you used.
• How you applied the MITRE rubric.
• How CVSS scores translated into exploitability levels.
• How you determined the severity of potential patient harm.
• How you decided whether a risk is acceptable.

Document the procedure once, then reference it throughout the submission.

Worth noting: Consistency matters. (Reviewers shouldn't have to figure out whether different engineers used different scoring methods.)

Another important part of the submission is showing your work for each vulnerability. What does this consist of?

Each scored finding should include:

• CVSS score and standard vector.
• MITRE extended vector.
• Answers supporting the scoring decisions.
• Risk assessment before and after mitigation.
• Relevant mitigation measures and supporting evidence.
• Links to the safety risk assessment when patient harm is possible.

What you want to do is write the procedure once and reference it. Explain the CVSS version, that you use the MITRE rubric, how you map scores to FDA exploitability assessment levels, how you rate severity of harm, and the matrix that decides acceptability.

Keep in mind that the FDA reviewer must be able to retrace the answers. You assure this by making certain each scored finding shows its vector and extended vector, so a reviewer can retrace the answers.

We've observed a good test: A reviewer who disagrees with one metric should be able to see exactly which question they would answer differently.

Then there's the postmarket side of things. Information on how fast you respond and how you score new vulnerabilities will be in your Cybersecurity Management Plan (Section VI.B).

Still uncertain?

Our post on FDA post-market cybersecurity responsibilities covers the response timelines and the 21 CFR 806 conditions.

Our book chapter on vulnerability assessment and response goes deeper on the workflow, and the chapter on security risk assessment covers the premarket side.

Use CVSS for what it does

CVSS is a good starting point, but don't expect it to tell the whole story. The MITRE rubric helps you score vulnerabilities in a medical device setting and flags possible patient safety concerns. From there, FDA wants you to consider how seriously a patient could be harmed and whether the risk is under control.

Keep a record of how you reached those decisions. After all, a score doesn't mean much if nobody can explain where it came from.

For more on what happens next, see balancing security controls with usability and what information FDA expects for cyber devices.

Need help with your cybersecurity risk assessment? Penetration testing produces the findings, and our FDA cybersecurity documentation service scores them and writes the report. See all services or email us at info@cybermed.ai.

Sources

• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• MITRE. Rubric for Applying CVSS to Medical Devices, Version 0.12.04, September 3, 2019 (revised October 27, 2020). https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices
• FIRST. Common Vulnerability Scoring System v3.0: Specification Document. https://www.first.org/cvss/v3.0/specification-document
• MITRE and MDIC. Playbook for Threat Modeling Medical Devices, November 2021. https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers.
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management.
• ISO 14971:2019. Medical devices, Application of risk management to medical devices.