Cyber Resilience Act (Reg. EU 2024/2847)¶
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is the first horizontal Union act imposing cybersecurity requirements across the entire lifecycle on products with digital elements (PDEs) placed on the European market. It is the regulatory cornerstone for the security of hardware and software products and integrates — without overlapping — with the other Digital Decade acts: NIS2 (on entities), the GDPR (on personal data), the AI Act (on AI systems), the PLD (on liability for defective products), the DSA (on intermediary services) and the EU data package (Data Act + DGA).
Identifiers¶
| Title | Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) |
| CELEX | 32024R2847 |
| OJ EU | L 2024/2847 of 20.11.2024 |
| Adoption date | 23 October 2024 |
| Entry into force | 10 December 2024 |
| Full applicability | 11 December 2027 (with early application of certain provisions: see Status of applicability) |
| Rectifications | none as of the publication date of this page |
Structure¶
- 8 chapters (I–VIII) covering a total of 71 articles
- 130 recitals
- 8 annexes (I–VIII):
- I — Essential cybersecurity requirements
- II — Information and instructions to the user
- III — Important products with digital elements (classes I and II)
- IV — Critical products with digital elements
- V — EU declaration of conformity
- VI — Simplified EU declaration of conformity
- VII — Contents of the technical documentation
- VIII — Conformity assessment procedures
Scope of application¶
The CRA applies to products with digital elements (PDEs) — defined as software or hardware products and their remote data processing solutions, including software or hardware components placed on the market separately — whose intended or reasonably foreseeable purpose includes a direct or indirect logical or physical connection to a device or network (Article 2).
Excluded from the scope (Article 2(2)–(7)):
- medical devices, in vitro diagnostic medical devices, motor vehicles, civil aviation products, marine equipment (covered by sectoral legislation);
- products developed or modified exclusively for national security or military purposes;
- free and open-source software developed or supplied outside a commercial activity (Article 2(6) and recitals 18-19); the regulation establishes a non-commercial carve-out but extends a lighter regime to certain FOSS operators (open source software stewards, Article 24).
The CRA introduces three product categories of increasing complexity:
- standard products (default): conformity assessment based on manufacturer self-assessment with CE marking;
- important products (Annex III, classes I and II — e.g. browsers, password managers, network management systems, firewalls, microcontrollers, smart speakers): enhanced conformity assessment, possibly with notified bodies;
- critical products (Annex IV — hardware with secure boxes, smart meter gateways, smart cards): mandatory conformity assessment with a notified body and, where required, European Cybersecurity Certification (Reg. (EU) 2019/881).
Manufacturers are subject to the substantive obligations of Chapter II: compliance with essential requirements (Annex I), cybersecurity risk assessment, provision of security updates throughout the support period (typically 5 years), notification of actively exploited vulnerabilities and severe incidents through the ENISA-managed Single Reporting Platform (Article 14), technical documentation (Annex VII), CE marking.
Septuple cross-references with the AI Act, GDPR, Data Act, DGA, PLD, DSA and NIS2¶
The CRA interacts with seven EU acts published on this site: the AI Act (for AI systems that are PDEs — dual conformity), the GDPR (for the integrity of personal data integrated into the CRA essential requirements), the Data Act (because many PDEs are connected products that generate data within the meaning of the Data Act), the DGA (for the security of data intermediation services operating on PDEs), the PLD (for manufacturer liability where products are defective, with CRA cybersecurity contributing to the notion of non-defectiveness), the DSA (for moderation and recommendation software of online platforms qualifying as PDEs) and the NIS2 (horizontal pairing: the CRA regulates products, NIS2 regulates entities).
CRA ↔ AI Act axis (AI systems as products with digital elements)¶
| CRA | AI Act | Nature of the intersection |
|---|---|---|
| Art. 2(1); art. 3(1) ('product with digital elements') | AI Act, art. 3(1) ('AI system') | AI systems that are software placed on the market as products typically fall within the CRA notion of PDE: the two regimes cumulate on the same product |
| Art. 12 (high-risk AI systems); recital 50 | AI Act, art. 6; Annex III | Lex specialis: for AI Act high-risk AI systems, compliance with the AI Act cybersecurity requirements (art. 15) is presumed to satisfy the CRA essential requirements (Annex I) within the scope covered by the AI Act. Avoids double certification for the same risks |
| Annex I, section 1 (essential requirements); art. 13(5) (risk assessment) | AI Act, art. 15 (accuracy, robustness, cybersecurity); art. 9 (risk management system) | Technical convergence: CRA requirements on robustness, integrity, confidentiality and availability of data and AI Act requirements on accuracy, robustness and cybersecurity rely on the same technical standards (harmonised norms) |
| Art. 14 (vulnerability and severe incident notification via the Single Reporting Platform) | AI Act, art. 73 (notification of serious incidents to authorities) | Parallel notifications: the same event (security incident on AI-PDE system) may require notification both via the CRA Single Reporting Platform and to the AI Act market surveillance authority; the CRA provides for coordination to avoid duplication (recital 76) |
| Annex III, class II (systems handling access/identity: PAM, IDM, key management) | AI Act, Annex III, points 1, 6 (biometric identification; law enforcement) | Biometric AI and identity management systems are simultaneously CRA important products (class II) and AI Act high-risk AI systems: maximum assessment regime under both |
CRA ↔ GDPR axis (integrity of personal data in the essential requirements)¶
| CRA | GDPR | Nature of the intersection |
|---|---|---|
| Art. 2(8); recital 17 | All of the GDPR | Without prejudice clause: the CRA applies without prejudice to the GDPR; the GDPR prevails in case of conflict |
| Annex I, section 1, points 2(b), 2(e), 2(f) (confidentiality, integrity, availability of data and functions) | GDPR, art. 5(1)(f) (integrity and confidentiality principle); art. 32 (security of processing) | Substantive convergence: CRA essential requirements on confidentiality, integrity and availability mirror the GDPR security principle on the product side; a CRA-compliant PDE contributes — but is not on its own sufficient — to the controller's GDPR compliance |
| Annex I, section 1, point 2(h) (data minimisation in the product) | GDPR, art. 5(1)(c) (minimisation principle); art. 25 (data protection by design) | Substantive cross-reference: the CRA mandates security/privacy by design at product level, giving operational effect to GDPR data protection by design on the hardware/software dimension of processing |
| Art. 14 (notification of exploited vulnerabilities and severe incidents); art. 11 (coordinated vulnerability disclosure) | GDPR, arts. 33, 34 (data breach notification to the authority and to the data subject) | Distinct but coordinated notifications: the CRA notifies product vulnerabilities to ENISA/CSIRTs; the GDPR notifies personal data breaches to the supervisory authority; the same event (e.g. exploited vulnerability causing personal data exfiltration) may trigger both obligations |
| Chapter VI — arts. 60-63 (confidentiality); recitals 121, 122 | GDPR, art. 35 (DPIA) | Data collected by CRA market surveillance authorities may include personal information; their processing is GDPR-bound and may require a DPIA |
| Recital 16 | All of the GDPR | Systematic recognition: cybersecurity of products is a technical precondition for the effectiveness of GDPR safeguards; the CRA is an enabling instrument for data protection |
CRA ↔ Data Act axis (connected products and generated data)¶
| CRA | Data Act | Nature of the intersection |
|---|---|---|
| Art. 3(1) ('product with digital elements') | Data Act, art. 2(5) ('connected product') | Frequent overlap: 'connected products' under the Data Act (IoT, devices that generate data) are mostly also PDEs under the CRA. The same product is subject to CRA cybersecurity requirements and to Data Act access/portability obligations |
| Annex I, section 1, points 2(b), 2(e), 2(f) (integrity and availability) | Data Act, Chapter II — arts. 3-7 (data access and sharing); recital 8 (security) | Interoperability precondition: access to connected-product data foreseen by the Data Act presupposes integrity and availability of the product and the data — guaranteed by the CRA. Without the CRA, the Data Act would be operationally fragile |
| Art. 13(8) (duration of the support period); Annex I, section 2 (vulnerability handling) | Data Act, Chapter VI — arts. 23-31 (cloud switching) | Cloud services connected to PDEs are governed by the Data Act (portability, interoperability) and by the CRA (cybersecurity of related services as components of the PDE) |
| Art. 23 (importers and distributors); art. 24 (open source software stewards) | Data Act, art. 2, points 13, 14 ('data holder', 'data recipient') | The CRA economic roles (manufacturer, importer, distributor) and the Data Act functional roles (data holder/recipient) do not coincide but may cumulate in the same operator |
CRA ↔ DGA axis (data intermediation services and digital products)¶
| CRA | DGA | Nature of the intersection |
|---|---|---|
| Art. 2(1); art. 3(1) (PDE) | DGA, art. 2(11) ('data intermediation service') | Data intermediation service providers that operate via software or platforms typically fall within the CRA scope (the software is a PDE); dual conformity: CRA essential requirements + DGA operational requirements |
| Annex I, section 1 (essential requirements) | DGA, art. 12 (conditions for providing data intermediation services) | Convergence: DGA security requirements for intermediation services (art. 12(h), (m)) find technical implementation in the CRA essential requirements for the software delivering the service |
| Chapter III — arts. 26-32 (notified bodies) | DGA, Chapter IV — arts. 16-25 (data altruism organisations) | Technical platforms of DGA data altruism organisations — when software — are PDEs subject to the CRA conformity assessment regime |
CRA ↔ PLD axis (cybersecurity and product non-defectiveness)¶
| CRA | PLD | Nature of the intersection |
|---|---|---|
| Annex I (essential requirements); art. 13 (manufacturer obligations) | PLD, recital 32; art. 7(2)(f) | Substantive cross-reference: compliance with CRA cybersecurity requirements contributes to the non-defectiveness of the product under the PLD; conversely, unpatched vulnerabilities can integrate defectiveness under the PLD |
| Art. 13(8) (support period and security updates); Annex I, section 2 (vulnerability handling) | PLD, recitals 50, 51; art. 11(2) | PLD exemption excluded: the manufacturer is not exonerated from PLD liability by invoking the defectiveness came after marketed defence where the defect arises from failure to release security updates within the CRA support period |
| Art. 14 (severe incident notification); Annex I, section 1, points 2(c), 2(d) (secure-by-default configuration) | PLD, art. 7(2) (presumption of defectiveness in complex cases) | CRA documentation (vulnerability notifications, risk assessments, technical documentation) may constitute a relevant evidentiary element in PLD proceedings to demonstrate defectiveness or to trigger the simple presumption |
| Art. 3(1) (PDE includes software) | PLD, art. 4(1); recital 13 | Definitional consistency: software is a product under both acts; the CRA manufacturer is typically the PLD manufacturer |
CRA ↔ DSA axis (moderation and recommendation software)¶
| CRA | DSA | Nature of the intersection |
|---|---|---|
| Art. 3(1) (PDE includes software) | DSA, art. 3(s), (t) ('recommender system', 'content moderation') | Automated moderation and recommender systems of online platforms are software and therefore typically PDEs subject to the CRA, on top of being subject to DSA algorithmic transparency obligations |
| Annex I, section 1 (essential requirements) | DSA, Chapter III, section 5 — art. 34 (VLOPs systemic risk assessment) | Cumulation for VLOPs/VLOSEs: DSA systemic risk assessment includes risks to public security and to fundamental rights; the CRA covers the technical cybersecurity of the algorithmic systems used |
| Art. 14 (notification of vulnerabilities and severe incidents) | DSA, art. 32 (notification of suspected criminal offences) | Distinct notifications: CRA notification concerns product vulnerabilities, DSA notification concerns illegal content; a single event (compromise of a recommender system spreading illegal content) may trigger both |
CRA ↔ NIS2 axis (products vs entities — horizontal pairing)¶
CRA and NIS2 are the two horizontal pillars of EU cybersecurity: the CRA disciplines products (cybersecurity by design across the lifecycle), NIS2 disciplines entities (risk management and incident reporting for essential and important entities). The two regimes are complementary and operate cumulatively: an NIS2 entity uses CRA products, and the two together constitute the European cybersecurity baseline.
| CRA | NIS2 | Nature of the intersection |
|---|---|---|
| Recitals 2, 3; entire framework | All of NIS2, in particular art. 1 | Structural pairing: the CRA ensures that products placed on the market are secure by design; NIS2 ensures that the entities using them have adequate risk management measures. Together they realise the EU cybersecurity baseline |
| Art. 14 (notification of exploited vulnerabilities and severe incidents via the Single Reporting Platform) | NIS2, art. 23 (significant incident reporting) | Complementary notifications: the manufacturer notifies product vulnerabilities to ENISA/CSIRTs via the CRA; the NIS2 entity affected by the incident notifies the national CSIRT under NIS2. CRA recital 76 provides for coordination to avoid duplication |
| Art. 13(8) (support period and security updates) | NIS2, art. 21 (risk management measures); Annex I (sectors of high criticality) | Trust chain: NIS2 essential entities (energy, transport, health, etc.) rely on CRA products for which the manufacturer maintains responsibility for updates throughout the support period; NIS2 obliges the entity to coherent patch management |
| Annex III, class II; Annex IV (important and critical products) | NIS2, Annex I, II (sectors) | Alignment between CRA critical product categories and NIS2 critical sectors: CRA important/critical products are typically those used in NIS2 sectors (e.g. firewalls, IDM, smart meters) |
| Chapter IV — arts. 33-46 (notification of conformity assessment bodies) | NIS2, art. 24 (use of European cybersecurity certification schemes) | Common certification schemes: CRA conformity assessment procedures may rely on European certification schemes (Reg. (EU) 2019/881) that NIS2 may impose on essential entities |
| Recital 76 | NIS2, art. 23; art. 30 (information sharing) | Operational cooperation: CRA market surveillance authorities cooperate with NIS2 CSIRTs and competent authorities for sharing information on vulnerabilities and incidents |
Septet of definitions¶
Seven key concepts run simultaneously across the CRA and the other seven acts, with the CRA introducing its own technical vocabulary (PDE, manufacturer, support period, exploited vulnerability):
| Concept | CRA | AI Act | GDPR | Data Act | DGA | PLD | DSA | NIS2 |
|---|---|---|---|---|---|---|---|---|
| Product / system | art. 3(1) (PDE) | art. 3(1) (AI system) | n/a | art. 2(5) (connected product) | n/a | art. 4(1) | n/a | n/a |
| Manufacturer / provider | art. 3(12) | art. 3(3), (4) | art. 4(7), (8) | art. 2(13), (14) | art. 2(11) | art. 4(10) | art. 3(b) | art. 6(38) |
| Personal data | recital 17 (GDPR cross-reference) | art. 3(50) | art. 4(1) | art. 2(3) | art. 2(3) | art. 4(6) | (implicit GDPR cross-reference) | art. 6(14) (GDPR cross-reference) |
| Vulnerability / incident | art. 3(41), (42) | art. 3(49) (severe incident) | art. 33 (personal data breach) | n/a | n/a | n/a | n/a | art. 6(6) (incident); art. 6(8) (vulnerability) |
| Cybersecurity / security by design | Annex I; art. 13 | art. 15 | art. 32 | (relevant) | n/a | (substantive cross-reference) | n/a | art. 21 |
| Related service / remote data processing | art. 3(2) | n/a | n/a | art. 2(6) | n/a | art. 4(4) (component) | n/a | n/a |
| Security notification / reporting | art. 14 | art. 73 | arts. 33, 34 | n/a | n/a | n/a | art. 32 | art. 23 |
Amendments and rectifications¶
As of the publication date of this page, the CRA has received no rectifications or amendments.
The CRA itself amends:
- Reg. (EU) No 168/2013 (type-approval of two- or three-wheeled vehicles);
- Reg. (EU) 2019/1020 (market surveillance);
- Directive (EU) 2020/1828 (representative actions).
Status of applicability¶
The CRA has been in force since 10 December 2024. Full applicability is staggered (Article 71):
- 11 September 2026: provisions on notification of conformity assessment bodies (Chapter IV) and delegated functions become applicable;
- 11 December 2026: obligations on notification of exploited vulnerabilities and severe incidents (Article 14) become applicable — first operational impact for manufacturers;
- 11 December 2027: full applicability of all substantive obligations, including the CE marking for cybersecurity of PDEs.
Related glossary terms¶
Entries from the AI-centric glossary relevant to this act:
- AI system
- Safety component
- CE marking
- Harmonised standard
- Common specification
- Conformity assessment
- Notified body
- Substantial modification
Official sources¶
- Full official text on EUR-Lex (CELEX 32024R2847)
- Official European Commission page — Cyber Resilience Act
- ENISA — Cyber Resilience Act
- Reg. (EU) 2019/881 (Cybersecurity Act) — cybersecurity certification framework
- Directive (EU) 2022/2555 (NIS2) — sister act on entities