Medical Device Risk Assessment using CVSS

CVSS is a scoring system for vulnerability severity, not a risk assessment on its own. FDA's postmarket cybersecurity guidance (December 2016) names CVSS version 3.0 as an example tool for rating the exploitability of a vulnerability. FDA's premarket cybersecurity guidance (February 2026) asks for an exploitability-focused, non-probabilistic risk assessment and leaves the scoring method to you. The MITRE Rubric for Applying CVSS to Medical Devices adapts the enterprise scoring questions to devices and clinical settings. This post explains how to use all three together, and where the score belongs in your file.

What CVSS measures

The Common Vulnerability Scoring System is an open standard maintained by FIRST, the Forum of Incident Response and Security Teams. It turns the characteristics of a single vulnerability into a number from 0 to 10.0 and a vector string that records how each metric was scored. CVSS v3.x maps the number to a qualitative rating: None, Low, Medium, High, or Critical.

CVSS v3.0 and v3.1 organize the metrics in three groups:

• Base metrics describe the vulnerability itself: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and the Confidentiality, Integrity, and Availability impacts.
• Temporal metrics describe the state of the world around it: Exploit Code Maturity, Remediation Level, and Report Confidence.
• Environmental metrics let an organization adjust the score for its own setting: Confidentiality, Integrity, and Availability Requirements, plus modified versions of the base metrics.

FIRST published CVSS v4.0 in November 2023 with a different metric structure. FDA's guidance and the MITRE rubric still reference v3.0, so this post uses the v3.x structure. State the version you score with in your risk management procedure, and use it consistently.

What FDA says about CVSS

FDA mentions CVSS in one place: the postmarket guidance, Section VI.A, Assessing Exploitability of the Cybersecurity Vulnerability. The guidance notes that estimating the probability of a cybersecurity exploit "is very difficult due to factors such as; complexity of exploitation, availability of exploits, and exploit toolkits." It then says: "FDA suggests that manufacturers instead consider using a cybersecurity vulnerability assessment tool or similar scoring system for rating vulnerabilities and determining the need for and urgency of the response."

The example it gives is "the 'Common Vulnerability Scoring System,' Version 3.0," and it lists the factors that feed exploitability: attack vector, attack complexity, privileges required, user interaction, scope, the three impact metrics, exploit code maturity, remediation level, and report confidence. It adds one caution: "weighting of the individual factors that contribute to the composite score should be carefully considered."

Two things follow from this. First, CVSS is an example, not a mandate. Second, FDA frames CVSS as an exploitability tool. The guidance pairs it with a separate assessment of the severity of patient harm, which CVSS does not measure. More on that below.

The 2026 premarket guidance does not name CVSS. Section V.A.2 explains why security risk is scored differently from safety risk: cybersecurity risks "are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling." Instead, "security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system." It points readers to the postmarket guidance for exploitability methods, which is where CVSS comes in. Our complete guide to FDA cybersecurity risk assessment covers Section V.A.2 in full.

Why plain CVSS misfits medical devices

CVSS was written for enterprise IT. The MITRE rubric's introduction describes the problem: the standard scoring questions and examples do not reflect the clinical environment or potential patient safety impacts. A "High" availability impact in enterprise terms means a server is down. On a ventilator it may mean a patient is not ventilated. The metric values look the same on paper.

Three gaps show up in practice:

• Impact metrics stop at the device. CVSS asks what happens to the vulnerable component. It does not ask what happens to essential performance or to the patient.
• Scope is hard to apply. Whether an exploit crosses a security authority boundary is an abstract question when the "components" are firmware, a companion app, and a cloud tenant owned by the same manufacturer.
• Scores drift between analysts. Without device-specific guidance, two engineers scoring the same finding often land two levels apart.

The rubric exists to close those gaps.

The MITRE Rubric for Applying CVSS to Medical Devices

MITRE developed the rubric under contract to FDA with a working group that included FDA, manufacturers, healthcare delivery organizations, and safety and security experts. Version 0.12.04, dated September 2019 and revised October 2020, has been qualified by FDA as a Medical Device Development Tool. Qualification means FDA has reviewed the tool for a stated context of use, so a submission that uses it within that context does not need to re-justify the tool itself.

How the rubric works:

• A question series for every metric. Each part of the CVSS vector has its own series of structured questions. The questions are ordered so the answers with the largest effect on the score come first, and some answers let the analyst skip questions that no longer apply.
• Decision flow diagrams. Each metric has a flowchart that mirrors the questions. The text is authoritative when the two differ.
• An extended vector. Answers that do not change the CVSS score are still recorded, with codes that begin with "X." That captures device context for the broader risk analysis.
• Worst case when unknown. If an answer is unknown, the analyst records "Unknown" and the rubric assigns the metric value that maximizes the score.
• Patient safety flags. Some answers carry a PIPS marker, "Potential Impact to Patient Safety." That is a prompt to run a safety hazard analysis and consider whether the issue is reportable under the postmarket guidance.
• A group exercise. The rubric recommends scoring with a group that covers five knowledge areas: cybersecurity and privacy; device engineering and architecture; patient health impact; clinical workflow in the healthcare delivery organization; and IT integration and interoperability.

The output is a standard CVSS v3.0 score and vector that anyone in the ecosystem can read, plus the extended vector and the question answers for your own file.

How to score a vulnerability with the rubric

Here is the sequence we use. It follows the rubric's scoring guidance and FDA's postmarket risk evaluation.

1. Isolate the vulnerability. Score the root cause, not the attack. One vulnerability often supports several attacks. In an attack chain, score each vulnerability on its own prerequisites: an elevation-of-privilege flaw reached after a remote compromise still starts from local access.
2. Work through the base metrics with the rubric. Answer each question series in order. Record "Unknown" rather than guessing, and "Not Answered" for questions the flow skipped, so a reviewer can see nothing was omitted.
3. Record the extended vector and any PIPS flags. This is where the device context lives. A PIPS flag means the finding goes to the safety risk team as well.
4. Score the temporal metrics. Exploit code maturity, remediation level, and report confidence change over time. For a premarket finding they usually start low and rise. Section V.A.2 of the premarket guidance makes the point directly: 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."
5. Map the score to an exploitability level. The postmarket guidance works with high, medium, and low exploitability. Document the thresholds you use.
6. Assess severity of patient harm separately. The postmarket guidance offers ISO 14971-style qualitative levels as one approach: Negligible, Minor, Serious, Critical, and Catastrophic. CVSS does not give you this. Your hazard analysis does.
7. Decide controlled or uncontrolled. The postmarket guidance describes 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.
8. Feed the result back. 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.

If several scenarios would change the score, such as an optional feature being enabled, score each one and either aggregate or take the highest.

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

• Copying the NVD score. The National Vulnerability Database scores a component in a generic setting. Your device changes attack vector, privileges, and impact. Rescore with the rubric and keep the NVD score as a reference.
• Scoring the attack instead of the flaw. A single parser bug reachable over Bluetooth and over USB is one vulnerability with one score, not two findings with two scores.
• 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.
• Mixing versions. Scoring some findings in v3.0 and others in v3.1 or v4.0 makes the numbers incomparable. Pick one and write it down.
• Treating the score as the verdict. A CVSS 4.3 can be uncontrolled risk if the harm is catastrophic. A CVSS 9.8 in an unreachable component can be controlled. The matrix decides, not the number.
• Using CVSS as an ISO 14971 probability. The premarket guidance is explicit that security risk is non-probabilistic. Do not convert a CVSS score into a P1 or P2 estimate. Transfer the hazard and let the safety process rate it on its own terms.

What goes in the submission

Section V.A.2 of the premarket guidance asks for three things about scoring: the method used for scoring risk before and after mitigation, the acceptance criteria, and the method for transferring security risks into the safety risk assessment. All three belong in the Cybersecurity Risk Management Report described in Section V.A and Appendix 4.

Write the procedure once and reference it. State the CVSS version, that you use the MITRE rubric, how you map scores to exploitability levels, how you rate severity of harm, and the matrix that decides acceptability. Then make sure each scored finding shows its vector and extended vector, so a reviewer can retrace the answers. A good test: a reviewer who disagrees with one metric should be able to see exactly which question they would answer differently.

For the postmarket side, your Cybersecurity Management Plan (Section VI.B) should say how you score new vulnerabilities and how fast you respond. 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 gives you a consistent, shareable way to rate how exploitable a vulnerability is. The MITRE rubric makes that rating meaningful for a medical device and hands you patient safety flags along the way. FDA's guidance then asks you to pair exploitability with severity of harm and make a controlled-or-uncontrolled call. Keep those three steps distinct and documented, and the score becomes useful evidence instead of a number that invites argument. For how controls and usability interact once you decide to mitigate, see balancing security controls with usability, and for the full set of cyber device documentation, see 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.