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) (Text with EEA relevance)

1. Official source details

Official 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) (Text with EEA relevance)

Issuing authority

European Parliament and Council of the EU

Document type

Regulation

Publication date

23 October 2024

Identifier

CELEX 32024R2847

Official source

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847 (opens official source in a new tab)

Collected via

EUR-Lex / EU Publications Office

2. Executive summary

3. Legal status and effective date

Binding — adopted regulation (Binding legislation)

Effective / application date: 23 October 2024 (Date of adoption of the Regulation by the European Parliament and the Council.); 20 November 2024 (Publication in the Official Journal L series.); 10 December 2024 (Start of the five-year period for which the power to adopt delegated acts is conferred on the Commission.); 11 December 2025 (Deadline for the Commission implementing act specifying technical descriptions of important (Annex III) and critical (Annex IV) product categories.); 11 December 2025 (Deadline for Commission delegated acts on the terms and conditions for delaying dissemination of notifications on cybersecurity-related grounds.); 11 June 2026 (Application of the provisions on notification of conformity assessment bodies (stated in recital 126).); 11 September 2026 (Application of the reporting obligations for actively exploited vulnerabilities and severe incidents (stated in recital 126).); 11 December 2027 (General date of application of the Regulation (stated in recital 126). From the same date, Directive (EU) 2020/1828 applies to consumer representative actions concerning CRA infringements.)

4. Relevant articles

• Article 15 — “the achievement of the level of cybersecurity protection required under Article 15 of Regulation (EU) 2024/1689 is demonstrated in the EU declaration of conformity issued under this Regulation.”
• Article 43 — “For the products with digital elements and cybersecurity requirements referred to in paragraph 1 of this Article, the relevant conformity assessment procedure provided for in Article 43 of Regulation (EU) 2024/1689 shall apply.”
• Article 57 — “Manufacturers of products with digital elements as referred to in paragraph 1 of this Article may participate in the AI regulatory sandboxes referred to in Article 57 of Regulation (EU) 2024/1689.”

5. Potentially affected stakeholders

Providers, Importers, Distributors, Enterprise AI users, Public-sector organisations, Notified bodies, Other explicitly affected parties

6. Practical implications

Organisations that provide high-risk AI systems embedded in, or delivered as, connected hardware or software products will need to manage cybersecurity compliance under two regimes. They may be able to use CRA conformity, documented in the CRA EU declaration of conformity, to demonstrate the cybersecurity element of AI Act Article 15. However, accuracy and robustness obligations under Article 15 remain separate. The conformity assessment route depends on whether the product is listed as important (Annex III) or critical (Annex IV) under the CRA and on which AI Act route would otherwise apply. Where the AI Act Annex VI internal control route would apply to an important or critical product, CRA procedures govern the cybersecurity requirements, which may involve third-party assessment. Notified bodies under the AI Act may also assess CRA Annex I requirements, subject to the CRA Article 39 condition. Beyond the AI Act interface, the CRA creates the following manufacturer obligations: - vulnerability handling for the support period; - early warning notifications to the CSIRT designated as coordinator and ENISA within 24 hours; - information to impacted users; - documentation retention for at least 10 years or the support period, whichever is longer; - due diligence over third-party and open-source components. The Regulation also defines obligations and scope for importers, distributors and open-source software stewards, but the detailed importer and distributor articles are not included in the excerpt provided. Member States must take CRA compliance, including manufacturers' ability to handle vulnerabilities, into consideration when procuring in-scope products (Article 5(2)). Several elements depend on later Commission implementing or delegated acts, such as technical descriptions of product categories, SBOM format and notification formats.

Binding nature: Binding. The official classification is an adopted regulation of the European Parliament and of the Council, Regulation (EU) 2024/2847, published in the Official Journal L series on 20.11.2024. The operative articles (for example Articles 12, 13 and 14) impose legal obligations. The recitals, including recital 51 on AI-specific risks and recital 126 on application dates, explain and interpret the operative provisions but are not themselves operative obligations. The article setting the entry into force and application dates is not included in the excerpt, so the application dates cited here come from recital 126. Commission guidance foreseen by the Regulation, for example on substantial modification and support periods, would not itself be binding law. Several provisions require further implementing or delegated acts before their detail is fixed.

7. Suggested control considerations

• Consider updating the AI system inventory to flag high-risk AI systems that are also products with digital elements within CRA scope, and record whether each falls under CRA Annex III (important, class I or II) or Annex IV (critical).
  Both the presumption of conformity with AI Act Article 15 cybersecurity requirements and the applicable conformity assessment route depend on dual classification under both regimes.
  Evidence: “products with digital elements which fall within the scope of this Regulation and which are classified as high-risk AI systems pursuant to Article 6 of that Regulation shall be deemed to comply with the cybersecurity requirements set out in Article 15 of that Regulation where:”
• Consider reviewing the conformity assessment pathway for each dual-scope AI product, including whether the CRA derogation for important or critical products overrides the AI Act Annex VI internal control route, and confirm whether the intended notified body holds competence under both regimes.
  The CRA derogation may require stricter, potentially third-party, assessment for the cybersecurity requirements than the AI Act internal control route alone. Notified body competence also depends on a specific condition.
  Evidence: “provided that the compliance of those notified bodies with the requirements laid down in Article 39 of this Regulation has been assessed in the context of the notification procedure under Regulation (EU) 2024/1689.”
• Consider reviewing technical documentation and the cybersecurity risk assessment for high-risk AI products so that they explicitly address AI-specific threats such as data poisoning and adversarial attacks, and so that the EU declaration of conformity demonstrates the Article 15 level of cybersecuri
  The presumption under Article 12(1) requires demonstration in the EU declaration of conformity. The recitals indicate that AI-specific risks should be covered in the risk assessment, which may be integrated with other risk assessments.
  Evidence: “including AI specific vulnerabilities such as data poisoning or adversarial attacks, as well as, as relevant, risks to fundamental rights, in accordance with Regulation (EU) 2024/1689.”
• Consider assessing logging, monitoring and incident escalation controls against CRA reporting timelines: early warning within 24 hours, notification within 72 hours, and final reports. Assign clear accountability for submissions via the single reporting platform and for informing users.
  Mandatory reporting of actively exploited vulnerabilities and severe incidents requires detection and escalation capabilities and is expected to apply ahead of the main application date.
  Evidence: “an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it”
• Consider reviewing AI third-party risk management, covering models, libraries and open-source components, to evidence due diligence, maintain an SBOM and define how vulnerabilities found in components are reported upstream.
  Manufacturers must exercise due diligence over third-party components, including non-commercial open-source components, and report vulnerabilities found in components to their maintainers.
  Evidence: “manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.”
• Consider reviewing product lifecycle governance so that support periods are defined and documented, security updates remain available for the required period, and documentation retention controls are in place. Reflect these points in audit methodology and control testing.
  The CRA sets a minimum support period and update availability and retention obligations that internal audit can test.
  Evidence: “Without prejudice to the second subparagraph, the support period shall be at least five years.”

8. References and official links

• EUR-Lex / EU Publications Office (opens official source in a new tab) (first retrieved 13 November 2026, 11:35 UTC)
• Regulation (EU) 2024/1689 (Artificial Intelligence Act) on EUR-Lex (opens official source in a new tab)

The analysis is based on an excerpt that ends partway through Article 16. The article on entry into force and application, Annexes I to VII, the conformity assessment provisions (Article 32), the notified body requirements (Article 39), the penalties articles and the amending provisions are not included. The application dates are therefore taken from recital 126, and the excerpt does not state the entry into force date. The AI Act interplay rests on Article 12 and recital 51. The CRA's terminology ('manufacturer', 'importer', 'distributor') differs from the AI Act's 'provider' and 'deployer'. The stakeholder mapping to 'providers' reflects AI Act providers who act as CRA manufacturers of high-risk AI products, and 'other' covers open-source software stewards and CRA manufacturers generally. 'Enterprise_users' reflects users' entitlement to vulnerability and incident information and to security updates. 'Public_sector' reflects procurement under Article 5(2). The CRA does not impose AI Act deployer obligations, so deployers are not listed.

Input truncated for analysis.

9. Last source verification

13 November 2026, 12:18 UTC · first retrieved 13 November 2026, 11:35 UTC