A CRA risk assessment is one of the most critical components of Cyber Resilience Act compliance. Before any manufacturer, importer or digital product vendor can classify their product, define security measures or prepare technical documentation, they must conduct a structured CRA risk assessment to identify cybersecurity threats, evaluate potential impact and determine the appropriate conformity requirements.
In this guide, we break down the full CRA risk assessment process, including methodology, documentation requirements, threat modelling practices and examples aligned with EU regulatory expectations. Whether you build embedded systems, IoT devices, firmware, software components or connected hardware, this article explains how to perform a CRA-aligned risk assessment that stands up to regulatory scrutiny.
What Is a CRA Risk Assessment?
A CRA risk assessment is a structured evaluation required under the EU Cyber Resilience Act. It ensures that manufacturers identify cybersecurity threats, analyse vulnerabilities and document the security measures needed to comply with Annex I, Annex II and Annex VII of the regulation. The CRA risk assessment directly influences product classification, conformity requirements and technical documentation.
According to ENISA guidance on risk management, effective cybersecurity assessments must follow a clear methodology that includes threat identification, likelihood estimation and impact evaluation. The CRA expects the same level of structure and traceability.

Why the CRA Requires a Formal Risk Assessment
The Cyber Resilience Act makes risk assessment mandatory because it forms the foundation of secure-by-design and secure-by-default principles. Without a CRA risk assessment, an organisation cannot demonstrate that the product’s security controls are justified, proportionate and aligned with the threats relevant to its functionality.
- It ensures security measures are based on objective risk levels, not assumptions.
- It determines whether a product is Default Class or Critical Class.
- It directly influences the conformity assessment route.
- It ensures that vulnerabilities and attack surfaces are properly documented.
- It supports lifecycle security and post-market obligations.
Official European Commission CRA overview
Risk Assessment Requirements Under the Cyber Resilience Act
The CRA does not prescribe a specific methodology, but it requires manufacturers to follow a structured and documented approach. At minimum, every CRA risk assessment must include:
- Identification of intended use and reasonably foreseeable misuse.
- Identification of assets, attack surfaces and entry points.
- Threat modelling (e.g., STRIDE, LINDDUN, attack trees).
- Vulnerability analysis based on the product’s architecture.
- Risk evaluation using likelihood and impact criteria.
- Definition of risk-treatment actions and security measures.
- Traceability between risks and implemented mitigations.
This aligns with best practices from ISO/IEC 62443 and ISO/IEC 27005, both of which are referenced in EU cybersecurity guidance.
CRA Risk Assessment Framework: Step-by-Step
1. Define the Product and Its Operational Context
The Cyber Resilience Act risk assessment begins with a technical description of the product, including architecture, interfaces, data flows and connectivity. This establishes the baseline for identifying vulnerabilities and attack surfaces.
2. Identify Assets and Attack Surfaces
Common CRA-relevant assets include firmware, communication channels, authentication mechanisms, cryptographic operations and user data. Each asset must be mapped to potential attack paths.
3. Conduct Threat Modelling
Threat modelling methods such as STRIDE or attack trees help structure the analysis. The CRA does not require a specific model but expects a justified, repeatable approach.

4. Analyse Vulnerabilities
The CRA expects manufacturers to identify both known and potential vulnerabilities based on architecture, dependency chains and third-party components. This ties directly to SBOM requirements and open-source management.
5. Evaluate Likelihood and Impact
Risks must be evaluated using clear criteria. Impact should consider safety, data integrity, security degradation, service continuity and downstream consequences.
6. Define Mitigation Measures
Security measures must be proportional to the risks identified and aligned with Annex I requirements, including secure configuration, update mechanisms, vulnerability handling and cryptographic protections.
7. Document Traceability
Regulators expect a traceability matrix linking:
- Risk → Vulnerability → Mitigation → CRA requirement → Evidence
This is essential for audits and for the CRA technical documentation file.
Risk Assessment Examples for IoT, Embedded and Software Products
Example 1: IoT Sensor
- Threat: network interception
- Vulnerability: unencrypted communication
- Impact: confidentiality breach
- Mitigation: TLS 1.3 with certificate-based authentication
Example 2: Embedded Controller
- Threat: local access exploitation
- Vulnerability: insecure debug interface
- Impact: unauthorised firmware modification
- Mitigation: secure boot, interface locking and debug authentication
Example 3: Software Application
- Threat: supply-chain compromise
- Vulnerability: outdated open-source package
- Impact: remote code execution
- Mitigation: SBOM tracking and automated dependency monitoring
How CRA Risk Assessment Influences Product Classification
The CRA risk assessment is the primary input for determining whether a product belongs to Default Class or Critical Class. Critical Class products must follow a more rigorous conformity assessment and involve a notified body.
Risk factors that increase the likelihood of Critical Class classification include:
- Connectivity to critical infrastructure
- Potential impact on safety or essential services
- High-value data processing
- Integration into industrial environments
Full guide: CRA applicability & product classification
Documenting Your Cyber Resilience Act Risk Assessment
Under Annex II and Annex VII, manufacturers must include the Cyber Resilience Act risk assessment in their technical documentation. At minimum, documentation must cover:
- Risk assessment methodology
- Threat and asset identification
- Risk tables and evaluation
- Security controls and mitigations
- Traceability mapping
This documentation must remain available for 10 years after the product is placed on the market.
Conclusion
A CRA risk assessment is a mandatory, foundational activity for Cyber Resilience Act compliance. It shapes product classification, guides security design, informs technical documentation and ensures that products meet EU cybersecurity expectations. Organisations that begin the CRA risk assessment process early will reduce compliance risk, accelerate audits and improve the security quality of their digital products.


