---
title: "CVSS v4.0 for CAN — Scoring Vulnerabilities for the EU CRA"
canonical_url: https://can-security.net/risk-assessment/cvss-for-can/
description: "The EU Cyber Resilience Act requires CVSS vulnerability scoring, but CAN does not map cleanly to its categories. A consistent method based on EmSA-WP-103."
last_updated: 2026-08-27
---
# Applying CVSS v4.0 to CAN and CAN FD Vulnerabilities

[CVSS](https://can-security.net/resources/terms-and-definitions/#term-cvss) is vulnerability scoring, not risk assessment; the two are distinct activities. The EU [CRA](https://can-security.net/resources/terms-and-definitions/#term-cra) requires manufacturers to score vulnerabilities consistently when reporting to ENISA and to customers. CAN technology does not map cleanly to standard CVSS categories; there is no IP address, no port, no privilege model. EmSA white paper WP-103 establishes a CAN-specific scoring convention; this page summarizes and applies it. [CRA Art. 13](https://can-security.net/resources/cra-requirements/) [EmSA-WP-103](https://can-security.net/resources/terms-and-definitions/#term-emsa-wp-103)

## Vulnerability Scoring vs. Risk Assessment

Risk assessment and vulnerability scoring are two distinct activities, and confusing them obscures what each is for. A **risk assessment** is a process: identify assets, frame threats, rate exposure and impact, select mitigations, document residual risk. It is done up front, at system or product scope, and produces a traceable analysis. **Vulnerability scoring** is what you do per finding: given one specific weakness, produce a comparable severity number that can be communicated to ENISA, to customers, and to the wider community. CVSS v4.0 is the de facto scoring scheme the CRA expects. The risk assessment frames the system; CVSS scores findings within it, both during development and across the product lifecycle as new vulnerabilities surface.  
See [IEC 62443-Style Risk Assessment](https://can-security.net/risk-assessment/iec-62443/) for the process side.

## Why CVSS Matters for CAN Product Manufacturers

CRA Article 13 requires vulnerability handling, including communication of severity to users. CVSS is the industry standard for severity scoring. For CAN-based products, scoring inconsistently across the industry would defeat the purpose; WP-103 proposes conventions that have been used in real CAN vulnerability disclosures.

## How CVSS v4.0 Works — A CAN-Specific Primer

CVSS v4.0 has four metric groups: Base (intrinsic to the vulnerability), Threat (exploitation maturity), Environmental (deployment-specific), and Supplemental. Base metrics produce the headline score. The Base metrics most relevant to CAN are AV (Attack Vector, typically Physical), AC (Complexity, typically Low for CAN bus access), AT (Attack Requirements), PR (Privileges Required, typically None on classical CAN), and the impact triad VC/VI/VA on the vulnerable system plus SC/SI/SA on subsequent systems.

## Scoring a Classical CAN Node: Baseline (5.2 / Medium)

An unprotected classical CAN node baseline is:

Rationale: physical attack vector (AV:P) with low complexity (AC:L) and no special prerequisites (AT:N, PR:N, UI:N). Confidentiality of the typical control payload is rated N because the data itself is usually not confidential. Integrity (VI:H) and availability (VA:H) are High because frame injection and DoS are unconstrained. The Subsequent System metrics are None for a single CAN node; they would change if the analysis covered the wider system the CAN node controls.

## How Defense-in-Depth Layers Reduce the Score

Each layer of [Defense in Depth](https://can-security.net/risk-assessment/defense-in-depth/) reduces a different CVSS metric. The reductions stack; that is the point of layering:

- **Access Limitation (physical enclosure, perimeter shell):** Eliminates the attack vector entirely for the common case, reducing AV from P to "not exploitable", effectively dropping the score to 0 for that scenario, though insider and supply-chain risk remain documented separately.

- **[Bus Load Monitoring](https://can-security.net/solutions/bus-load-monitoring/):** Reduces VA from H to L for flooding and error-frame attacks; availability events are surfaced and operators can respond.

- **[Local Injection Detection](https://can-security.net/solutions/local-injection-detection/):** Reduces VI from H to L by giving the legitimate sender a way to detect impersonation of its own CAN IDs.

- **[Anomaly Event Monitoring](https://can-security.net/solutions/anomaly-event-monitoring/):** Reduces VI/VA from H to L for many attack classes; the attack is no longer silent and operators can respond.

- **[Frame Security](https://can-security.net/solutions/frame-security/) ([CANcrypt](https://can-security.net/resources/terms-and-definitions/#term-cancrypt) / [SPsec](https://can-security.net/resources/terms-and-definitions/#term-spsec)):** Reduces VC, VI, and VA all to N for in-band CAN attack scenarios. The score drops near 0; residual risk is on the cryptographic implementation and key management.

- **[Secure Object Fieldbus Access](https://can-security.net/solutions/secure-object-fieldbus-access/) (configuration locking, protected OD entries):** Reduces VA from H to L or N for configuration-tampering scenarios specifically.

- **[Secure Bootloader](https://can-security.net/solutions/secure-bootloader/):** Closes the firmware-tampering vector, removing the highest-impact subsequent-system scenarios from scope.

## Who Scores What

The component manufacturer scores the vulnerability against its own product. The integrator may re-score it in the context of the integrated system using Environmental metrics. The operator may further adjust based on deployment-specific compensating controls. WP-103 recommends that manufacturers publish the Base score and clearly state the assumptions, leaving Environmental refinement to the integrator.

## Reference: EmSA-WP-103

The full derivation of vector strings and worked examples is in EmSA-WP-103, available from the [esacademy.com white papers library](https://www.esacademy.com/en/library/security-white-papers.html).

> ### EmSA Consulting on CVSS Scoring

> For the two cases not covered by the off-the-shelf catalog and the courses, we review CVSS vector choices and scoring justifications in your risk-assessment record, or customize a Solutions shell when the score points to gaps the current configuration cannot close.

> [Talk to ESAcademy →](https://www.esacademy.com/en/security.html)

> ### EmSA Training — CRA Requirement Mapping (incl. CVSS)

> Walks teams through how CRA requirements apply to CAN devices, with detailed treatment of the vulnerability handling process and CVSS v4.0 vector decisions for CAN-specific scenarios.

> [Open this course →](https://emsa.courses/course/cra-can-mapping)

> ### White Paper — EmSA-WP-103

> The reference white paper underpinning this page. Available alongside the broader EmSA security white paper library.

> [Library on esacademy.com →](https://www.esacademy.com/en/library/security-white-papers.html)

## Frequently Asked Questions

### What CVSS score does an unprotected classical CAN node get?

5.2 (Medium) under CVSS v4.0, with vector `CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N`. Source: EmSA-WP-103.

### Does the CRA require CVSS specifically or just "a scoring system"?

The CRA requires manufacturers to use a recognized vulnerability scoring scheme and to communicate severity with each reported vulnerability. CVSS is the de facto scoring scheme for this purpose, and the version expected at the time of writing is CVSS v4.0. ENISA's reporting templates assume CVSS.

### Can I reduce my CVSS score by adding a security event monitor?

Yes. A security event monitor that detects and reports anomalies reduces the integrity and availability impact metrics from High to Low for many threat classes, because the attack is no longer silent. The total score drops accordingly. See [Anomaly Event Monitoring](https://can-security.net/solutions/anomaly-event-monitoring/).

### What is the CVSS score if CAN FD with SPsec encryption is used?

When SPsec authenticated encryption is in place across the bus, the integrity, availability, and confidentiality impact metrics for the typical CAN-borne attack scenarios all drop to None, yielding a baseline near 0.0. Residual risk shifts to attacks against SPsec itself or its key material; those are scored separately.