Risk Assessment for CAN and CAN FD Systems

Why Risk Assessment Is Mandatory

CRA Article 13(2) requires manufacturers to undertake and document a cybersecurity risk assessment for each product with digital elements before placing it on the market. The regulation does not mandate a specific methodology; manufacturers may choose any approach that produces a defensible, traceable analysis. This reference uses IEC 62443-3-2 throughout because it is the methodology that fits industrial and other non-automotive applications best, which is the scope of this site. IEC 62443-4-1 SM-3 mandates equivalent process discipline for industrial suppliers, and IEC 62443-3-2 specifies the system-level risk-assessment process itself. CRA Art. 13 IEC 62443-3-2

What a Risk Assessment Covers

A risk assessment per IEC 62443-3-2 is a structured process: identify assets, define damage scenarios, enumerate threat scenarios and attack paths, rate attack feasibility, compute risk, and select risk treatment. The output is a documented, traceable analysis from assets to treatment decisions, the same shape of artifact CRA Article 13 expects. The Machinery Regulation similarly requires the cybersecurity-related safety analysis to be documented and methodologically defensible. Several established methodologies could be used; the IEC 62443-Style Assessment page names the alternatives in common use (ISO/IEC 27005, NIST SP 800-30, ISO/IEC 27019, EN 18031 under the Radio Equipment Directive) and explains why this reference settled on IEC 62443-3-2 for industrial CAN. IEC 62443-3-2

Vulnerability Scoring with CVSS — A Separate, Complementary Activity

Vulnerability scoring is not risk assessment. Where a risk assessment frames the entire system before release, vulnerability scoring produces a comparable severity number for one specific weakness, typically discovered later. CVSS v4.0 is the de facto scoring system the CRA expects when reporting vulnerabilities to ENISA and to customers. CAN-specific vector choices are not obvious; the CVSS for CAN page, based on EmSA-WP-103, walks through them with worked examples. Scores from individual findings feed back into the living risk-assessment record, but they do not replace it.

How Defensive Measures Reduce Risk Score

Every defensive measure maps to one or more CVSS v4.0 metric changes;
the per-control mapping with worked examples is on CVSS for CAN.
The strategy of combining several measures into layered protection is covered on Defense in Depth,
and the per-threat coverage of individual shells at IEC 62443 Security Levels is cataloged on the Solutions overview.

How Much Security Is Enough

The purpose of the assessment is not to pile on every available control; it is to invest in proportion to the risk. IEC 62443-3-2 ends in a risk-treatment step where each identified risk is reduced, accepted, or transferred, and the CRA frames the same principle as security appropriate to the risk. A node behind a locked cabinet on an isolated segment may rationally accept risks that a gateway on an exposed diagnostic port must mitigate. The target Security Level sets the height of the bar: an SL2 baseline is a light symmetric layer, while heavier machinery such as a full public-key infrastructure or hardware-backed key storage enters only at SL3 and above, or where scale and anti-counterfeiting justify it. Security bought beyond the assessed risk is cost without a matching reduction in risk.

Getting Started

For a typical CAN product team, a pragmatic starting point is: (1) document the assets and external interfaces, (2) score the unprotected baseline using CVSS (see worked examples), (3) decide on mitigations to reach an acceptable residual score, and (4) maintain the assessment under change control.

Frequently Asked Questions

Is a risk assessment required for every CAN product under CRA?

Yes. CRA Article 13(2) requires manufacturers to undertake a cybersecurity risk assessment before placing a product with digital elements on the market and to document the result. CAN nodes shipping firmware fall in scope.

Is CVSS a risk-assessment methodology?

No. Risk assessment and vulnerability scoring are two distinct activities. A risk assessment per IEC 62443-3-2 is a process that frames the system: identify assets, threats, attack paths, derive risk, and choose treatment. CVSS v4.0 is a per-finding severity metric used when reporting a specific vulnerability to ENISA or to customers. The risk assessment frames the system; CVSS scores findings within it.

Can I use a documented security justification instead of a full risk assessment?

For low-risk classical CAN systems with strong physical access controls, a documented security justification (per EmSA-WP-101) can be a proportionate alternative to a full risk assessment. Whether this satisfies a specific regulator depends on the product category, the assessed risk, and the conformity-assessment route chosen.

Do I have to implement security at all costs?

No. The CRA requires protection appropriate to the risk, not the maximum possible. IEC 62443-3-2 makes this explicit through its risk-treatment step: each risk is either reduced with a control, accepted with a documented rationale, or transferred, weighing the cost against the reduction it buys. A low-risk node behind a locked cabinet may accept risks that a gateway on an exposed diagnostic port must actively mitigate. The assessment is what tells you where that line falls.

How much should CAN security cost?

It scales with the target Security Level the assessment sets, not with a fixed shopping list. An IEC 62443 SL2 baseline is a lightweight symmetric layer that fits ordinary CAN controllers; the more expensive elements, a full public-key infrastructure or hardware-backed key storage, become necessary only at SL3 and above, or where scale or anti-counterfeiting justify them. Spending beyond the assessed risk buys no additional compliance.