Cybersecurity risk assessment: How manufacturers can prove compliance with the CRA
For digital product manufacturers entering the EU market, the Cyber Resilience Act (Regulation (EU) 2024/2847, hereinafter – the CRA) establishes a regulatory framework where manufacturers must prove compliance: they need to demonstrate what risks they have identified, how they responded to them, and what evidence supports this. The central document of such an evidence base is the cybersecurity risk assessment.
In this article, we will examine what the CRA specifically requires from a risk assessment, how to conduct it, how it fits into technical documentation, conformity assessment, and CE marking, as well as what to do while harmonized standards are still being finalized. Separately, we will touch upon what is already in force: reporting obligations apply starting from September 11, 2026.
Key CRA dates: What is already in force and what lies ahead
The CRA entered into force on December 10, 2024, but applies in phases:
- June 11, 2026 – provisions regarding notified bodies become applicable;
- September 11, 2026 – reporting obligations regarding actively exploited vulnerabilities and severe incidents (Article 14);
- December 11, 2027 – essential requirements for products, documentation obligations, and CE marking.
In practice, this means that a product placed on the EU market after December 2027 must be designed with a risk assessment in mind, while products already on the market today are already subject to reporting requirements.
Why risk assessment is the foundation of proving compliance
The CRA is built on a risk-based approach. Article 13 obliges the manufacturer to carry out a cybersecurity risk assessment of the product and take its results into account across all lifecycle phases: planning, design, development, production, delivery, and maintenance. The assessment must be documented, updated throughout the product support period, and included in the technical documentation.
This is a fundamental principle: the requirements of Annex I to the CRA are not applied mechanically. It is the risk assessment that explains whether a specific requirement applies to the product and, if so, how it is implemented. A market surveillance authority will typically not ask “what did you do?”, but rather “why is this level of protection sufficient for your product?”. In fact, this is compliance engineering: translating a legal norm into requirements that can be implemented, verified, and documented.
It is worth distinguishing this assessment from a Data Protection Impact Assessment (DPIA) under the GDPR. A DPIA analyzes risks to the rights and freedoms of individuals whose data is processed, whereas a CRA assessment evaluates the cybersecurity risks of the product itself. The objects are different, although some input data (data maps, architecture descriptions) can be reused.
What a CRA cybersecurity risk assessment must contain
According to Article 13, the assessment must include a risk analysis taking into account the intended purpose of the product, reasonably foreseeable use, and conditions of operation, as well as the timeframe during which the product is likely to be used. In addition, it must demonstrate how the product complies with the requirements of Annex I. The structure can be summarized as follows:
| Assessment Element | What to Document | CRA Reference |
| Intended purpose and foreseeable use | Product functions, target users, reasonably foreseeable use scenarios | Article 13 |
| Conditions of operation and assets | Operating environment, data and functions requiring protection, expected lifetime | Article 13 |
| Threats and vulnerabilities | Threat sources, attack vectors, attack surface, third-party component dependencies | Annex I, Part I |
| Applicability of Annex I requirements | For each requirement: whether it applies, how it is implemented, or justification if not | Article 13, Annex I, Part I |
| Vulnerability handling | How the product and manufacturer’s processes comply with Annex I, Part II (SBOM, patches, vulnerability disclosure policy) | Article 13, Annex I, Part II |
| Review and update | Triggers for reviewing the assessment throughout the support period | Article 13 |
The requirements of Annex I, Part I include secure default configurations, protection against unauthorized access, encryption, data integrity, data minimization, attack surface limitation, logging, and secure data deletion. It is precisely against these points that the assessment must show “applicable / not applicable / how implemented.”
Step-by-step guide: How to conduct a risk assessment
The CRA does not mandate a specific methodology, allowing manufacturers to choose a model that fits their product and development processes.
A practical algorithm looks like this:
- Determine your role and product. Make sure you are the manufacturer of a product with digital elements (hardware, software, or remote data processing solutions) and that the product is not excluded from the CRA due to sector-specific regulation.
- Describe the purpose and conditions of use. Record why the product was created, who uses it, in what environment it operates, and its estimated lifespan.
- Build an asset and attack surface model. Describe data flows, interfaces, update channels, third-party, and open-source components.
- Identify threats and assess risks. You can use recognized approaches (e.g., STRIDE or ISO/IEC 27005), but it is vital that the results are reproducible and the evaluation criteria are fixed.
- Map risks to Annex I. For each requirement, determine whether it applies, what measure implements it, and what evidence supports it.
- Define measures and verification methods. Assign responsible parties and schedule testing (e.g., penetration testing, dependency checks).
- Set a support period and review triggers. As a general rule under the CRA, the support period must be at least five years, unless the expected product lifetime is shorter. The review of the assessment should be tied to new releases, discovered vulnerabilities, architectural changes, and significant modifications.
- Integrate results into the product lifecycle. The assessment should influence the backlog, development requirements, and release decisions rather than sitting as a separate document. This is the security engineering approach: security is built into the system as part of the architecture.
Technical documentation
The risk assessment must be included in the technical documentation under Article 31 and Annex VII. This is the exact package of documents that a market surveillance authority may request for inspection. The composition of the documentation can be summarized as follows:
| Component | What to Show | Examples of Evidence |
| Product description | Purpose, versions affecting conformity, user instructions | Product specification, user guide, architecture diagram |
| Design, development, and vulnerability handling | How the product is designed and how the manufacturer handles vulnerabilities | Secure SDLC policy, SBOM, vulnerability disclosure policy |
| Risk assessment | Result of the analysis under Article 13 | Risk assessment report, versioned risk register |
| Support | Support period and update provision rules | Support policy, public support period information |
| Verification | Standards applied, test results | Test reports, list of applied standards |
A copy of the EU declaration of conformity is also added to the documentation. The manufacturer must keep the documentation and declaration for at least ten years after the product has been placed on the market or for the support period—whichever is longer. If the materials contain trade secrets (such as details of algorithms or architecture), they should be clearly marked and an internal access regime agreed upon before any regulatory request.
Conformity assessment: Choosing the proof path
Following the risk assessment and documentation preparation, the manufacturer undergoes a conformity assessment procedure. The chosen path depends on the product category:
| Product Category | Procedure | Third-Party Involvement |
| Most products (by default) | Internal control (Module A), manufacturer self-assessment | Not required |
| Important products, Class I (Annex III) | Module A – only if harmonized standards or certification schemes are fully applied; otherwise – third-party assessment | Depends on the application of standards |
| Important products, Class II (Annex III) | Mandatory third-party assessment (EU-type examination or full quality assurance) | Mandatory |
| Critical products (Annex IV) | European cybersecurity certification scheme, if required by a delegated act; otherwise – Class II procedures | Yes, depending on the scheme |
Upon successful completion of the procedure, the manufacturer draws up the EU declaration of conformity and affixes the CE marking. For important products that are free and open-source software, Article 32 provides a simplified pathway via Module A, provided that the technical documentation is publicly accessible.
Harmonized standards and presumption of conformity: What to do now
Products that comply with harmonized standards published in the Official Journal of the EU enjoy a presumption of conformity to the extent covered by those standards. The Commission’s standardization request (M/606) covers around 41 standards from CEN, CENELEC, and ETSI. According to the request schedule, key horizontal standards on secure development and vulnerability handling were expected by August 30, 2026, vertical standards by October 30, 2026, and the remaining horizontal standards by October 30, 2027. The current citation status of standards should be checked in the Official Journal.
Until standards are cited, compliance must be demonstrated directly against the requirements of Annex I. There is no need to wait for them: if the risk assessment, technical documentation, and testing evidence are already structured around Annex I, matching them against standards later boils down to a gap analysis rather than rebuilding the entire evidence base.
Article 14 reporting: Why it already impacts the evidence base
Starting from September 11, 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents affecting product security. Reports are submitted via the ENISA Single Reporting Platform to the relevant national CSIRT and ENISA. Deadlines are calculated from the moment the manufacturer becomes aware of the event:
| Stage | Deadline | Content |
| Early warning | 24 hours | Fact of the event, if possible – EU countries where the product is available |
| Notification | 72 hours | Description of vulnerability or incident, nature of exploitation, measures taken or planned |
| Final report | For vulnerability – 14 days after a patch or mitigation becomes available; for incident – one month after notification | Root cause, severity, impact, measures taken, and, if necessary, recommendations for users |
Such timelines cannot be met without a pre-configured process.
This is why vulnerability handling documentation is part of the evidence base: it shows who decides on event classification, how the moment of “awareness” is recorded, and how the report is prepared. If a manufacturer became aware of an event before September 11, 2026, reporting it under the CRA is not required; however, for events occurring after that date, fines for non-compliance can reach up to 15 million euros or 2.5% of total worldwide annual turnover.
Reporting under the CRA does not replace other obligations regarding the same event. For example, if an incident involves personal data, separate deadlines and requirements of the General Data Protection Regulation (GDPR) apply.
Third-party components and open source
Article 13 requires manufacturers to exercise due diligence regarding third-party components, including open-source code, to ensure they do not undermine product cybersecurity. In practice, this means an SBOM (Software Bill of Materials) is needed not only as a technical artifact, but also as an input for the risk assessment. It is advisable to combine vulnerability checking with open-source license compliance audits, as both processes rely on the same data regarding components and their open-source licenses.
Some risks must be shifted to the contractual domain.
For manufacturers engaging developers or component suppliers, this typically implies the following changes:
- in Master Services Agreements (MSAs) and Statements of Work (SOWs) – requirements for secure development, SBOM transfer, and documentation support;
- in warranties and representations – absence of known exploited vulnerabilities at the time of transfer and a proper remediation process;
- in Service Level Agreements (SLAs) – vulnerability response times aligned with the 24-hour and 72-hour reporting deadlines;
- in indemnification provisions – allocation of liability if a component defect leads to fines or claims.
This directly applies to Ukrainian outsourcing and product companies as well.
If you are developing a product for a manufacturing client, these requirements will most likely come to you contractually. If you are placing a product on the EU market under your own name, you are the manufacturer yourself, and your partners in the EU act as importers or distributors.
Conclusion
For the CRA, a cybersecurity risk assessment is the logical bridge between the product and the requirements of Annex I. A manufacturer who can show what risks they identified, why they chose specific measures, how they verify them, and how they respond to new vulnerabilities will be in a strong position both before the surveillance authority and a corporate client. Reporting is already in effect, so it is best to start with processes and documentation rather than waiting for 2027.
