The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847. It creates horizontal cybersecurity requirements for products with digital elements placed on the EU market. For software and hardware manufacturers, the CRA turns product security into a lifecycle compliance obligation.
Sources: Regulation (EU) 2024/2847, European Commission CRA summary, European Commission CRA page, ENISA CRA materials.
Key takeaways
- The CRA entered into force on 10 December 2024.
- Main obligations apply from 11 December 2027.
- Article 14 reporting obligations apply earlier, from 11 September 2026.
- The CRA applies to hardware and software products with digital elements made available on the EU market, subject to defined exclusions.
- Manufacturers must address security by design, vulnerability handling, conformity assessment, technical documentation, and CE marking.
- Non-compliance with essential cybersecurity requirements and Articles 13 and 14 can lead to fines up to EUR 15 million or 2.5% of worldwide annual turnover.
Scope of this article
This article explains CRA obligations for manufacturers, importers, distributors, and software teams. It does not replace product-specific legal analysis or conformity-assessment planning.
What is the Cyber Resilience Act?
The CRA is a product-security regulation. It applies across sectors and targets products with digital elements, including software, hardware, and remote data processing solutions that are necessary for a product function. The Commission describes it as a horizontal framework for secure hardware and software in the EU market.
Application timeline
| Date | Milestone | Operational consequence |
|---|---|---|
| 10 December 2024 | Entry into force | Preparation period starts. |
| 11 June 2026 | Chapter IV applies | Conformity-assessment body notification rules apply. |
| 11 September 2026 | Article 14 applies | Reporting obligations for actively exploited vulnerabilities and severe incidents start. |
| 11 December 2027 | Main application date | Core CRA obligations apply to products with digital elements. |
Who is in scope?
The CRA covers economic operators such as manufacturers, authorised representatives, importers, and distributors. The most intensive obligations sit with manufacturers because they control design, development, documentation, vulnerability handling, and conformity assessment.
Open-source software requires careful analysis. The regulation distinguishes non-commercial open-source activity from commercial activity and also introduces the role of open-source software steward. Do not assume every repository is out of scope.
Product categories
| Category | Practical reading | Compliance impact |
|---|---|---|
| Standard products | Products with digital elements not listed as important or critical. | Manufacturer obligations and conformity assessment apply. |
| Important class I | Products listed in Annex III with material cybersecurity relevance. | More structured conformity expectations. |
| Important class II | Higher-risk products listed in Annex III. | Stronger conformity-assessment burden. |
| Critical products | Products listed in Annex IV. | Potential certification relevance and higher assurance expectations. |
Main manufacturer obligations
- Design, develop, and produce products according to essential cybersecurity requirements.
- Document cybersecurity risk assessment and technical controls.
- Handle vulnerabilities during the support period.
- Provide security information and instructions to users.
- Run the appropriate conformity-assessment route.
- Apply CE marking when requirements are met.
Vulnerability and incident reporting
Article 14 introduces reporting duties for actively exploited vulnerabilities and severe incidents affecting product security. The Commission summary states that these reporting obligations apply from 11 September 2026. Product teams should prepare intake, triage, evidence, and disclosure workflows before that date.
The reporting obligations apply from 11 September 2026: deadlines, content, the ENISA platform and the competent CSIRT are in our guide to CRA Article 14.
Coordination with NIS 2 and other EU rules
NIS 2 focuses on entities and their cybersecurity risk-management obligations. CRA focuses on products with digital elements. A software vendor can be affected by both: NIS 2 as an entity and CRA as a product manufacturer. Existing Aegister articles on NIS 2, EU Cybersecurity Act revision, Cyber Solidarity Act, and CRA readiness funding provide adjacent context.
Operational checklist
- Inventory products and digital components placed on the EU market.
- Classify each product category and economic-operator role.
- Map secure-by-design controls to the product lifecycle.
- Define vulnerability intake, triage, remediation, and disclosure workflow.
- Prepare technical documentation and evidence repository.
- Assess conformity route and CE-marking plan.
- Coordinate CRA reporting with NIS 2, DORA, or sector incident processes.
Secure development lifecycle under the CRA
Manufacturers should translate CRA obligations into the product lifecycle. The practical lifecycle includes product classification, threat modeling, secure design review, dependency control, vulnerability testing, release approval, security update process, and end-of-support communication. Each step should leave evidence.
| Lifecycle step | Evidence to keep |
|---|---|
| Product classification | Scope analysis, category decision, role assessment. |
| Secure design | Threat model, architecture review, security requirements. |
| Build and dependency control | SBOM, dependency review, signing records. |
| Testing | Security test results, vulnerability remediation notes. |
| Release | Conformity evidence, user security instructions, CE documentation. |
| Post-market | Vulnerability intake, patch records, notification evidence. |
Importer and distributor checkpoints
Importers and distributors should not treat CRA as only a manufacturer problem. They need evidence that products are properly identified, accompanied by required documentation, and handled in a way that does not undermine conformity. Procurement teams should therefore request product-security documentation before market placement or distribution.
Vulnerability-handling workflow
- Receive vulnerability reports through a monitored channel.
- Triage exploitability, affected versions, and product-security impact.
- Assign remediation owner and target date.
- Prepare user communication and update guidance.
- Assess whether Article 14 reporting duties are triggered.
- Preserve decision logs and technical evidence.
Penalty and governance implications
The CRA fine ceiling for essential cybersecurity requirements and Articles 13 and 14 is high enough to make product security a board-level risk. Compliance should therefore be tracked in product governance, not left only to engineering teams.
Support-period planning
CRA vulnerability handling is not a one-time release task. Manufacturers must plan how long security updates, vulnerability intake, and user communications will be supported. Regulation text and official summaries should be checked for the product category, but the operational point is simple: the support period must be defined, communicated, and resourced.
Technical documentation pack
- Product description and intended use.
- Cybersecurity risk assessment and design decisions.
- Essential requirement mapping.
- SBOM or component inventory where applicable.
- Testing records and vulnerability remediation notes.
- Conformity assessment evidence.
- User security instructions and support-period information.
Product team operating model
CRA readiness requires product, engineering, security, legal, and support teams to work together. Engineering owns secure implementation. Security owns threat modeling and validation. Legal and compliance own conformity interpretation. Support owns user communication and vulnerability intake. Product management owns lifecycle decisions and support-period commitments.
Legacy and substantial modification risk
Products already on the market before the main application date still need analysis when they are substantially modified. Product teams should define what counts as a security-relevant change, who approves it, and when technical documentation must be refreshed. This should be part of release governance.
Manufacturers building or refreshing the CRA program often benefit from external CISO support to bridge product engineering, cybersecurity, and legal. Aegister's Virtual CISO service covers product-security governance, vulnerability handling design, conformity-assessment readiness, and coordination with NIS 2 obligations where both regimes apply.
FAQ
When does the CRA apply?
The CRA entered into force on 10 December 2024. Article 14 reporting applies from 11 September 2026. The main obligations apply from 11 December 2027.
Does the CRA apply to software?
Yes, where software is a product with digital elements made available on the EU market, subject to the regulation’s scope and exclusions.
Is CE marking enough?
No. CE marking is the visible outcome of conformity. The underlying evidence, risk assessment, vulnerability handling, and documentation matter.
