3.4 Risk Assessment
3.4.1 Methodology
Risk assessment for vulnerabilities and products is based on established standards:
- CVSS v3.1/v4.0 -- Common Vulnerability Scoring System for individual CVEs
- SSVC -- Stakeholder-Specific Vulnerability Categorization for prioritisation
- CRA Annex I -- Requirements catalogue as the assessment framework
LEGAL BASIS
Art. 13(3) CRA: "The manufacturer shall carry out a cybersecurity risk assessment of the product with digital elements and shall take the result of that assessment into account during the planning, design, development, production, delivery, and maintenance of the product."
3.4.2 CVE Risk Assessment (Individual Vulnerabilities)
CVSS-Based Initial Assessment
| CVSS Score | Severity | CRA Priority |
|---|---|---|
| 9.0 -- 10.0 | Critical | P0/P1 |
| 7.0 -- 8.9 | High | P2 |
| 4.0 -- 6.9 | Medium | P3 |
| 0.1 -- 3.9 | Low | P4 |
Contextual Assessment
The CVSS score is supplemented by a contextual analysis:
| Factor | Assessment | Weighting |
|---|---|---|
| Exploitability | Actively exploited / PoC available / Theoretical | High |
| Reachability | Network / Local / Physical | High |
| Data exposure | Personal data / Business data / None | Medium |
| Prevalence | Number of affected products / customers | Medium |
| Mitigability | Fix available / Workaround / None | Medium |
Decision Matrix
Exploitability
Active PoC Theoretical
Severity +----------------------------------+
Critical | P0 P1 P1 |
High | P1 P2 P2 |
Medium | P2 P3 P3 |
Low | P3 P4 P4 |
+----------------------------------+3.4.3 Product Risk Assessment (CRA Art. 13(3))
A cybersecurity risk assessment is carried out for each CRA-relevant product. Use the Risk Assessment Template.
Assessment Categories
1. Threat Analysis
- Who are potential attackers? (Script kiddies, organised crime, state actors)
- What attack vectors exist? (Network, physical, supply chain)
- What assets are at risk? (Data, functionality, availability)
2. Impact Analysis
- Confidentiality: What data could be disclosed?
- Integrity: What data/functions could be manipulated?
- Availability: What downtime is acceptable?
- Safety: Could physical damage occur? (relevant for firmware/IoT)
3. Likelihood Assessment
- Attack complexity
- Required privileges
- User interaction required
- Attack vector exposure
Risk Matrix
Likelihood
High Medium Low
Impact +----------------------------------+
Critical | CRITICAL HIGH MEDIUM |
Significant | HIGH HIGH MEDIUM |
Moderate | HIGH MEDIUM LOW |
Minor | MEDIUM LOW LOW |
+----------------------------------+3.4.4 Residual Risk Under the CRA Is Not a Matter of Risk Appetite
In organisational risk management, risks are evaluated against acceptance criteria derived from the organisation's own objectives or risk appetite. The CRA does not work that way.
THE BENCHMARK IS THE PRODUCT, NOT THE ORGANISATION
Under the CRA, residual cybersecurity risk is assessed against the requirement that the product placed on the market ensures an appropriate level of cybersecurity based on the risks, taking into account its intended purpose and reasonably foreseeable use.
The manufacturer's internal risk tolerance, commercial strategy or mere cost considerations are not relevant in determining whether risks have been addressed.
Residual risk is an inherent outcome of risk assessment and treatment — cybersecurity risks cannot in practice be entirely eliminated. But the existence of residual risk does not imply that any risk may be accepted at the manufacturer's discretion. A product may only be placed on the market where the residual risks, after appropriate measures, have been sufficiently addressed through the implementation of the essential requirements of Annex I Part I, in light of:
- the intended purpose,
- the reasonably foreseeable use and conditions of use, including where relevant the operational environment (for example the intended users) and the assets to be protected, and
- the length of time the product is expected to be in use.
Ways to address an identified risk (Art. 13(3))
| Measure | Example |
|---|---|
| Reduce the attack surface | Remove unused services and interfaces |
| Implement technical safeguards | Authentication, encryption, integrity protection |
| Limit or adapt functionality | Disable a risky capability by default |
| Define the intended purpose more precisely | Restrict the product to trusted environments |
| Shape reasonably foreseeable use | Risk communication, user guidance, user interface design steering users towards secure patterns |
RISK MAY NOT BE TRANSFERRED TO USERS
The CRA does not provide for the transfer of cybersecurity risk or responsibility to users or third parties in order to compensate for shortcomings in product design, or to justify leaving risks unaddressed. The obligation to place a secure product on the market and to demonstrate conformity remains with the manufacturer.
Information and instructions to users may support secure deployment and operation — including where the manufacturer has chosen to restrict the intended purpose to trusted environments — and may inform users of residual risks. They cannot substitute for treatment.
Example (legitimate use of intended-purpose restriction): A manufacturer develops an industrial sensor that, for functional reasons, cannot be protected against physical attacks on the sensor itself. To mitigate the risk identified in the risk assessment, the manufacturer limits the sensor's intended purpose to trusted environments where unauthorised physical access is prevented, and states these limitations clearly in the information and instructions to users.
Example (legitimate reliance on platform security): A manufacturer of a professional application processing locally stored sensitive data identifies the risk of unauthorised access to clear-text data. Rather than building a proprietary encryption mechanism, it relies on the encryption and key management functions provided natively by the operating system, whose cryptographic services are mature and regularly maintained.
Where the risk assessment identifies risks that cannot be adequately addressed through appropriate measures, compliance may require changes to the design, functionality or intended purpose of the product. Cost or commercial feasibility alone are not sufficient grounds for leaving such risks untreated where this would prevent the product from meeting the essential requirements.
The relationship to Annex I Part I, point (1)
Point (1) of Annex I Part I requires that products be designed, developed and produced so as to ensure an appropriate level of cybersecurity based on the risks. This is a catch-all, distinct from the legal obligation to carry out a risk assessment under Art. 13(2).
| Situation | Effect on point (1) |
|---|---|
| All relevant risks are treated by implementing the other applicable essential requirements of Part I | Point (1) is deemed fulfilled. In most cases, compliance with the other requirements produces compliance with point (1). |
| The risk assessment identifies additional risks not fully addressed by those measures | The manufacturer must implement further appropriate measures on the product in order to comply with point (1). |
3.4.5 Risks That Originate Outside the Product
The risk assessment covers relevant risks that may affect the product including risks originating outside it — external networks, environmental factors, external infrastructure, other systems, or services on which the product relies.
WHAT THE CRA DOES AND DOES NOT REQUIRE
The CRA does not require manufacturers to control or govern the external environment. It requires them to identify such risks and mitigate them through the design and development of the product itself — by implementing the appropriate essential requirements and, where necessary, providing users with information and instructions on integration or deployment risks.
| External risk | Product-level mitigation |
|---|---|
| Unauthorised persons gain access to back-end systems outside the product and send malicious commands to it | Cryptographic authentication of remote commands; verification of the integrity of configuration changes; security-relevant logs or alerts on abnormal behaviour |
| An external service becomes unavailable (power outage, infrastructure failure) | Ensure the outage does not cause the product to enter insecure states |
The CRA regulates how the product responds to those external risks. It does not impose obligations on how the back-end infrastructure is organised, staffed or operated, nor does it treat that infrastructure as part of the product → 1.15 Remote Data Processing.
Three risk categories must therefore be covered for any product with remote elements:
- risks related to remote data processing solutions that are part of the product;
- risks related to reliance on third-party remote solutions — treated like third-party components;
- risks related to the product environment (e.g. underlying hardware).
3.4.6 Reuse Across Product Families
Manufacturers frequently place similar products on the market — different variants, models or configurations of the same family. The CRA does not require each variant to be treated as an entirely separate product for risk assessment and conformity assessment purposes.
WHEN REUSE IS PERMITTED
Where the products share the same architecture, security-relevant design and intended purpose, and are exposed to the same cybersecurity risks, the manufacturer may rely on:
- a single cybersecurity risk assessment under Art. 13(2);
- a single set of technical documentation; and
- a single conformity assessment procedure.
This also allows a single EU declaration of conformity to be issued for the group — provided it clearly identifies the product variants to which it applies.
The decisive factor: are the differences relevant to cybersecurity?
| Difference | Separate assessment required? |
|---|---|
| Colour, form factor, memory size, other non-security-relevant characteristics | No |
| Different communication interfaces | Yes — reflect in the risk assessment and, where necessary, in the conformity assessment and technical documentation |
| Different software stacks | Yes |
| Different update mechanisms | Yes |
| Different remote connectivity | Yes |
REUSE IS CONDITIONAL AND MUST BE MAINTAINED
Manufacturers remain responsible for ensuring that the risk assessment and related documentation accurately reflect the products actually placed on the market. Where a new variant introduces new cybersecurity risks or changes how the essential requirements are implemented, the existing risk assessment and conformity documentation must be updated. Reliance on a single conformity assessment is only possible to the extent that the products present no differences in their cybersecurity properties.
THIS ALSO COVERS LEGACY PRODUCT FAMILIES
For products designed before the CRA applies, where several variants share the same design and cybersecurity risk profile, the manufacturer may rely on representative evidence covering the product family rather than testing every variant → 1.1 Scope.
3.4.7 Documentation Obligation
Each risk assessment must document:
- Date of assessment
- Assessed product/version — and, where a family assessment is used, the exact list of variants covered
- Identified risks with assessment, including risks originating outside the product
- Measures taken for risk mitigation, at product level
- Remaining residual risks with justification against the essential requirements — not against internal risk appetite
- Any essential requirement that cannot be fully met, the constraint that causes this, and the compensatory measures implemented
- Responsible assessor
- Next review date
The risk assessment is part of the technical documentation (Annex VII) and must be kept accurate, complete and continuously up to date (Art. 13(7), Art. 31(2)) — in the event of material changes to the product, new variants, or new threat landscapes.
Source and legal status of the interpretations in sections 3.4.4 to 3.4.6: Commission Guidance on the CRA.