On this page
Published:
Key Takeaways
- CVSS v4.0 has eleven Base metrics: five describe exploitation and six describe technical impact.
- Score the vulnerable system separately from subsequent systems. A device, app, or cloud service can be the vulnerable system.
- CVSS measures vulnerability severity, not patient harm or whether a manufacturer can accept risk.
One vulnerability. Two impact boundaries.
Score the system containing the flaw separately from other systems affected through exploitation.
Vulnerable system
Where the flaw lives
- VC
- Confidentiality
- VI
- Integrity
- VA
- Availability
Subsequent systems
Supported consequences elsewhere
- SC
- Confidentiality
- SI
- Integrity
- SA
- Availability
Each impact: None, Low, or High. Connectivity alone does not establish subsequent-system impact. CVSS severity is not a patient-risk decision.
Score a vulnerability
CVSS v4.0 base severity (CVSS-B). Patient harm and risk acceptance need a separate assessment.
Record a VEX status
VEX does not produce a score. It records whether a known vulnerability affects your product, using the four statuses in CISA's VEX minimum requirements. The status is the statement author's documented assessment; nothing here is preselected.
CVSS describes how a vulnerability can be exploited and what technical damage it can cause. The six impact metrics are Confidentiality, Integrity, and Availability for the vulnerable system and for subsequent systems. CVSS v4.0 also has five exploitability metrics, making eleven Base metrics in total. This guide covers all eleven so you can justify each selection in the CVSS v4.0 calculator.
Before scoring, name the component containing the vulnerability, its affected version, the attack path, and the demonstrated consequences. The vulnerable system might be a device, mobile app, desktop application, or cloud service. Do not automatically treat the physical device as the vulnerable system or every connected component as a subsequent system. Follow FIRST's system-boundary guidance and document your choice.
The six impact metrics
For each impact metric, select None (N), Low (L), or High (H). Score the reasonably supported outcome of successful exploitation, not a speculative worst case. None means no impact of that type, not that the vulnerability is harmless overall.
1. Vulnerable System Confidentiality (VC)
Question: What information can the attacker disclose from the system containing the vulnerability?
- None: No confidentiality loss.
- Low: Some restricted information is disclosed, but the attacker cannot control the extent or the loss has no direct, serious impact.
- High: All information is disclosed, or disclosure of some restricted information has a direct, serious impact. A stolen administrative private key can qualify even without disclosure of every record.
Example: An authorization flaw exposes all patient records held by the vulnerable cloud service. VC:H may be appropriate. Exposure of a limited, low-impact diagnostic detail may support VC:L. Document the actual data and access demonstrated.
2. Vulnerable System Integrity (VI)
Question: What can the attacker change in that system?
- None: No integrity loss.
- Low: Limited modification is possible without a direct, serious consequence, and the attacker does not control the full extent of the change.
- High: The attacker can completely compromise integrity, or limited modification causes a direct, serious consequence.
Example: A flaw allows an attacker to change a therapy parameter stored on the vulnerable device. VI:H can be justified if that modification has a direct, serious consequence. The clinical harm still needs a separate safety assessment.
3. Vulnerable System Availability (VA)
Question: Can exploitation interrupt access to that system or its resources?
- None: No availability loss.
- Low: Reduced performance or intermittent interruptions occur without complete denial of access or a direct, serious consequence.
- High: Access is completely denied, whether sustained during an attack or persisting afterward, or a partial interruption has a direct, serious consequence.
Example: A crafted packet stops the vulnerable monitor from providing its monitoring service until reboot. VA:H may be supported. A brief response delay without serious consequences may support VA:L.
4. Subsequent System Confidentiality (SC)
Question: Does exploiting the first system disclose information from another system?
- None: No confidentiality loss in subsequent systems.
- Low: Some restricted information is disclosed with limited scope and no direct, serious impact.
- High: All information is disclosed, or disclosure of some restricted information has a direct, serious impact.
Example: A compromised gateway exposes records from a separate EHR system through an established, demonstrated attack path. SC:H may be appropriate. Merely connecting the gateway to the EHR does not establish an impact.
5. Subsequent System Integrity (SI)
Question: Can the attack alter information or behavior in another system?
- None: No integrity loss in subsequent systems.
- Low: Limited modification is possible without a direct, serious consequence.
- High: Complete integrity compromise is possible, or limited modification has a direct, serious consequence.
Example: Exploitation of an app allows unauthorized therapy commands to reach a separate device. SI:H may apply if the command path and serious technical consequence are supported by evidence. Do not infer this solely from a diagram showing app-to-device communication.
6. Subsequent System Availability (SA)
Question: Can the attack interrupt another system's service?
- None: No availability loss in subsequent systems.
- Low: Reduced performance or interrupted access occurs without total denial or a direct, serious consequence.
- High: Complete denial of access occurs, or partial disruption has a direct, serious consequence.
Example: Exploitation of a gateway causes a separate clinical system to become unavailable. SA:H needs evidence of that downstream consequence. If exploitation only crashes the gateway, assess VA and do not assume SA.
The calculator calls these groups Device and Downstream. In FIRST's terminology they are Vulnerable System and Subsequent System. Those formal definitions apply even when the vulnerable component is not a device.
The five exploitability metrics
Attack Vector (AV): where can the attack originate?
| Value | Meaning | Example |
|---|---|---|
| Network (N) | Exploitation works across network hops; public internet exposure is not necessary. | A vulnerable service accepts malicious requests through a routed network. |
| Adjacent (A) | The protocol limits the attack to a logically adjacent network or proximity. | An attack requires Bluetooth range or the same local subnet. |
| Local (L) | The path uses local read, write, or execute capabilities. | An attacker executes a local privilege-escalation exploit, including through a remote terminal session. |
| Physical (P) | The attacker must physically touch or manipulate the system. | Exploitation requires connecting hardware to a debug port. |
Avoid: Choosing Adjacent simply because the product is normally deployed inside a hospital. Classify the attack path, not just the deployment location.
Attack Complexity (AC): must an exploit defeat security protections?
Low (L) means no target-specific circumvention of security-enhancing conditions is needed. High (H) means exploitation must evade protections such as ASLR or DEP, or obtain a target-specific secret through additional attacks.
The amount of coding effort, attacker skill, or time spent writing an exploit does not by itself make AC High. Required authentication belongs under PR; winning a race belongs under AT.
Attack Requirements (AT): are special execution conditions necessary?
None (N) means the attack does not depend on special deployment or execution conditions. Present (P) means conditions must exist, such as winning a race or being on the network path to inject traffic.
AC concerns defeating security protections. AT concerns conditions that arise from deployment or execution and are not primarily security protections. Explain the distinction rather than counting the same obstacle twice.
Privileges Required (PR): what access is needed before exploitation?
None (N) means no existing privileges are required. Low (L) means basic, limited privileges. High (H) means significant control, such as administrative access to settings and files.
Score privileges before the exploit, not those gained afterward. A patient account may be Low, but a job title or account label alone does not decide the value. FIRST generally treats self-service accounts that an attacker can provision as part of the attack as no privilege requirement; hard-coded or shared default credentials also need careful treatment.
User Interaction (UI): must someone other than the attacker participate?
None (N) means no other human user needs to participate. Passive (P) means limited or involuntary interaction, such as viewing a page that renders malicious content without subverting a protection. Active (A) means specific, conscious interaction, such as importing a malicious file or overriding a warning to run a payload.
Describe the exact action. A clinician being logged in is not, by itself, proof of Active interaction.
Worked example: an unauthenticated record-disclosure flaw
This is an invented training example, not a client finding. A routed cloud API lets an unauthenticated attacker retrieve every patient record in that service. No security mitigation bypass, special execution condition, or other user's action is needed. Testing demonstrates disclosure, but no modification, service disruption, or subsequent-system impact.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Enter those values in the calculator. Change VC from High to None to see why an easy attack path alone is not enough for a nonzero Base severity score when all technical impacts are None. The score is produced by the CVSS v4.0 scoring algorithm, not a simple average of the selections.
Retain the vector, the affected version, your evidence, and a short reason for every selection. If your evidence supports a different consequence, change the relevant metric rather than copying the example.
What the score does not tell you
CVSS severity bands are None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0). They are not patient-risk acceptance categories.
The calculator's separate High, Medium, or Low exploitability label is a Blue Goat Cyber screening heuristic, not an official CVSS metric or a probability estimate. Its known-exploitation option adds the Threat metric E:A. Its Safety flag adds the Supplemental metric S:P, which does not change the numeric score. Neither replaces product-specific evidence or the manufacturer's risk decision.
Threat and Environmental metrics can refine a score beyond the Base assessment. This calculator does not expose the complete Environmental metric set. An overall low technical score can still warrant urgent clinical review. See CVSS scoring for medical devices for the wider risk-assessment context.
Frequently asked questions
Does CVSS v4.0 have six metrics?
It has six Base impact metrics and five Base exploitability metrics. Threat, Environmental, and Supplemental groups contain additional metrics. Earlier CVSS versions use different metric sets, so do not mix a v3.1 vector with v4.0 definitions.
Should every connected system get a High downstream rating?
No. Score the supported impact of exploiting this vulnerability. Connectivity alone does not prove disclosure, modification, or loss of service in another system.
Can a CVSS score tell us whether patient risk is acceptable?
No. Assess clinical consequences and risk controls separately under your documented methodology. Do not accept or reject residual risk automatically from the CVSS band.
Official sources
- FIRST CVSS v4.0 specification: formal metric definitions, system boundaries, and severity bands.
- FIRST CVSS v4.0 user guide: scoring guidance and interpretation.
- FIRST CVSS v4.0 calculator: official reference calculator for cross-checking vectors.
