Conducting a CRA-Compliant Product Risk Assessment

Why the Risk Assessment Matters

The cybersecurity risk assessment is the analytical foundation of CRA compliance. It is explicitly required as part of the technical file and must demonstrate that the manufacturer has systematically identified risks and designed the product to address them. A superficial risk assessment that does not match the actual product architecture will not survive scrutiny from a notified body or market surveillance authority.

Scope the Assessment

Define the scope before beginning:

• Which product(s) and versions are being assessed
• Operating environments (consumer, industrial, critical infrastructure)
• Intended users and their expected technical sophistication
• Data types processed (personal data, safety-critical control data, etc.)
• Physical deployment context (internet-facing, air-gapped, etc.)

Asset Identification

Identify what needs protection:

• Data (user credentials, personal data, operational data, cryptographic keys)
• Functions (core product functionality, update mechanisms, administrative interfaces)
• Interfaces (network ports, APIs, physical interfaces, wireless protocols)

Threat Identification

For each asset, identify realistic threats:

• Attackers (nation-states, criminal groups, script kiddies, insiders, competitors)
• Attack vectors (network, physical access, supply chain, social engineering)
• Attack types (data theft, ransomware, supply chain compromise, DoS, privilege escalation)

Use STRIDE as a checklist to ensure coverage.

Vulnerability Assessment

Map known vulnerability classes to the product's implementation:

• Is user authentication implemented correctly?
• Are all third-party dependencies current and supported?
• Are input validation controls in place at all trust boundaries?
• Does the update mechanism verify signatures?
• Are default credentials unique?

Reference the SBOM to assess third-party component risk.

Risk Evaluation and Prioritisation

For each identified risk, evaluate:

• Likelihood — how probable is exploitation? (Consider EPSS scores for known CVEs)
• Impact — what is the consequence of successful exploitation? (Safety, financial, privacy, availability)
• Risk level — combine likelihood and impact (e.g., using a 5×5 risk matrix)

Annex I Traceability

Map each Annex I requirement to the risk assessment and the corresponding control:

Annex I Req	Risk Addressed	Control	Residual Risk
Req 3 (Access Control)	Unauthorised access	Multi-factor auth, unique credentials	Low
Req 4 (Confidentiality)	Data interception	AES-256 storage, TLS 1.3 transport	Low

This traceability matrix is what auditors will review.

Ongoing Risk Assessment

The risk assessment is not a one-time exercise. It must be updated when:

• The product adds new connectivity or functionality
• A new vulnerability class is discovered in similar products
• Third-party components in the SBOM are found to be vulnerable
• The threat landscape changes significantly