Skip to content

AI-generated content: Responses are generated by AI, automatically assembled and may contain errors. Conformi is a research tool and does not replace legal advice or case-by-case legal review. All responses should be verified using the linked original sources.

Conformi/Knowledge Base/Cybersecurity/CRA
🛡️Cybersecurity & IT

Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements

Analysis from 17 April 20263 sourcesConsolidated version of 20.11.2024 (with corrigenda C1, C2, C3)EUR-Lex Original

Which of our connected products need a cybersecurity overhaul before the Cyber Resilience Act kicks in — and what happens if we miss the deadline?

Any product with digital elements sold in the EU must meet mandatory cybersecurity-by-design requirements by 11 December 2027 — non-compliance exposes manufacturers to fines of up to EUR 15 million or 2.5% of global turnover.

Short Answer

The Cyber Resilience Act (CRA) introduces horizontal cybersecurity obligations for all products with digital elements placed on the EU market, covering both hardware and software including their remote data processing solutions [Art. 2(1)]. Manufacturers must conduct cybersecurity risk assessments, deliver products without known exploitable vulnerabilities, provide security updates for at least five years, and maintain a software bill of materials [Art. 13, Annex I]. Actively exploited vulnerabilities must be reported to ENISA and the relevant CSIRT within 24 hours [Art. 14(2)(a)]. Important products (Annex III) and critical products (Annex IV) face stricter conformity assessment procedures involving third-party audits [Art. 32(2), (3)].

Who is affected

All economic operators — manufacturers, importers, and distributors — placing products with digital elements on the EU market, whether for payment or free of charge [Art. 3(13)]. This includes standalone software, hardware with embedded software, and components. Excluded: medical devices (Reg. 2017/745, 2017/746), motor vehicles (Reg. 2019/2144), aviation products (Reg. 2018/1139), marine equipment (Dir. 2014/90/EU), and products developed exclusively for national security or defence [Art. 2(2)-(7)]. Open-source software stewards have lighter obligations and are exempt from administrative fines [Art. 25, Art. 64(10)(b)].

Deadline

Vulnerability and incident reporting obligations (Art. 14) apply from 11 September 2026. Notified body framework (Chapter IV, Art. 35-51) applies from 11 June 2026. Full application of all remaining obligations from 11 December 2027 [Art. 71(2)]. Products placed on the market before 11 December 2027 are only subject to new requirements if substantially modified, except that Art. 14 reporting applies to all in-scope products regardless [Art. 69(2), (3)].

Risk

Ceiling: EUR 15 million or 2.5% of worldwide annual turnover for non-compliance with essential cybersecurity requirements (Annex I) and manufacturer obligations (Art. 13, 14) [Art. 64(2)]. Secondary tier: EUR 10 million or 2% for other regulatory obligations [Art. 64(3)]. Providing misleading information to authorities: EUR 5 million or 1% [Art. 64(4)]. Micro- and small enterprises are exempt from fines for late early-warning notifications [Art. 64(10)(a)]. Market surveillance authorities may additionally order withdrawal or recall of non-compliant products [Art. 54].

Proof

Legal status

  • In force
  • as of 2026-04-17
  • Consolidated version of 20.11.2024 (with corrigenda C1, C2, C3)

Primary sources

What to do now

Legal / DPO

  • Map every product with digital elements in your portfolio against the scope exclusions in Art. 2(2)-(7) and the important/critical product lists in Annexes III and IV to determine which conformity assessment route applies [Art. 32].
  • Review and update supply chain contracts to include cybersecurity risk assessment obligations and vulnerability handling requirements for third-party components, as required by the manufacturer's due diligence duty [Art. 13(5), (6)].
  • Prepare the EU declaration of conformity (Art. 28, Annex V) and ensure technical documentation (Art. 31, Annex VII) will be retained for at least 10 years or the full support period [Art. 13(13)].

Compliance

  • Establish a vulnerability reporting workflow that can deliver early-warning notifications to the relevant CSIRT and ENISA within 24 hours of discovering an actively exploited vulnerability, with follow-up within 72 hours and a final report within 14 days [Art. 14(2)].
  • Define and document the support period for each product — minimum five years — taking into account expected product lifetime, third-party component support, and ADCO guidance [Art. 13(8)].
  • Set up a coordinated vulnerability disclosure policy and a single point of contact for vulnerability reporting, as required by Annex I Part II and Art. 13(17).

IT / Security

  • Implement secure-by-default configurations, ensure products ship without known exploitable vulnerabilities, and enable automatic security updates that users can disable [Annex I, Part I(2)(a)-(c)].
  • Generate and maintain a software bill of materials (SBOM) covering all components, including open-source dependencies, in a machine-readable format [Annex I, Part II(1)].
  • Build a vulnerability handling process that covers identification, documentation, remediation, and timely delivery of security patches throughout the entire support period [Annex I, Part II].

Product / Engineering

  • Classify each product against Annex III (Class I and II for important products) and Annex IV (critical products) to determine whether self-assessment or third-party conformity assessment is required [Art. 7, Art. 8, Art. 32].
  • Integrate cybersecurity risk assessment into the product development lifecycle — from design through production, delivery, and maintenance — and document the outcome in the technical file [Art. 13(2)-(4), Annex VII].
  • Ensure user-facing documentation (Annex II) includes the support period end-date, instructions for secure installation and decommissioning, and information on how to report vulnerabilities [Art. 13(18), (19)].

Key Terms

Product with digital elements
Any software or hardware product and its remote data processing solutions, including components placed on the market separately, that has a direct or indirect data connection to a device or network [Art. 3(1)].
Software bill of materials (SBOM)
A formal, machine-readable record detailing the components and supply chain relationships within the software elements of a product with digital elements [Art. 3(39)].
Actively exploited vulnerability
A vulnerability for which reliable evidence exists that a malicious actor has exploited it in a system without the system owner's permission [Art. 3(42)].
Support period
The time during which a manufacturer must ensure effective vulnerability handling in accordance with Annex I Part II — at least five years unless the expected product lifetime is shorter [Art. 3(20), Art. 13(8)].
Open-source software steward
A legal person, other than a manufacturer, that systematically provides sustained support for the development of specific free and open-source products intended for commercial activities [Art. 3(14)].
Substantial modification
A change to a product with digital elements after its placing on the market that affects compliance with the essential cybersecurity requirements in Annex I Part I, or that changes the product's intended purpose [Art. 3(30)].
Conformity assessment
The process of verifying whether the essential cybersecurity requirements set out in Annex I have been fulfilled, carried out through self-assessment or third-party evaluation depending on the product category [Art. 3(27), Art. 32].
?

Frequently Asked Questions

Does the CRA apply to pure SaaS products?
The CRA applies to products with digital elements, defined as software or hardware and their remote data processing solutions [Art. 3(1)]. Pure SaaS that does not form part of a product with digital elements falls outside the CRA's scope. However, if the SaaS component is a 'remote data processing solution' without which the product cannot perform one of its functions, it is covered [Art. 3(2)].
Are open-source projects affected?
Free and open-source software made available outside the course of a commercial activity is not subject to manufacturer obligations [Recital 18]. However, 'open-source software stewards' — legal persons systematically supporting commercial open-source products — must put in place cybersecurity and vulnerability handling policies, though they are exempt from administrative fines [Art. 25, Art. 64(10)(b)].
What qualifies as an 'important' or 'critical' product?
Important products are listed in Annex III across two classes: Class I includes items such as identity management systems, browsers, VPNs, operating systems, and routers; Class II includes hypervisors, firewalls, and tamper-resistant microprocessors [Art. 7]. Critical products (Annex IV) include hardware security boxes, smart meter gateways, and smartcards [Art. 8]. Classification determines the applicable conformity assessment route.
What are the reporting deadlines for actively exploited vulnerabilities?
Manufacturers must submit an early-warning notification within 24 hours, a detailed vulnerability notification within 72 hours, and a final report within 14 days after a corrective measure is available [Art. 14(2)]. For severe incidents, the final report is due within one month of the incident notification [Art. 14(4)(c)]. All reports go through ENISA's single reporting platform [Art. 16].
How long must security updates be provided?
Manufacturers must handle vulnerabilities for the entire support period, which must be at least five years unless the product's expected use time is shorter [Art. 13(8)]. Each security update must remain available for at least 10 years or the remainder of the support period, whichever is longer [Art. 13(9)].
What happens to products already on the market when the CRA applies?
Products placed on the market before 11 December 2027 only become subject to CRA requirements if they undergo a substantial modification after that date [Art. 69(2)]. However, the vulnerability and incident reporting obligations under Art. 14 apply to all in-scope products already on the market, regardless of modification [Art. 69(3)].
Is a software bill of materials (SBOM) mandatory to share with customers?
Manufacturers must generate an SBOM covering at minimum the top-level dependencies of the product [Annex I, Part II(1)]. The SBOM must be included in the technical documentation but does not have to be shared with end-users — sharing is optional, though the manufacturer must inform users where to access it if they choose to make it available [Annex II, point 9].
3

Assessment Factors & Checklist

Premium
4

Questions for Your Lawyer

Premium
5

Conclusion & Summary

Premium

Detailed analysis with source links.

Schalten Sie die KI-Analyse frei — mit markierten Fundstellen und direkten Links zu EUR-Lex. 7 Tage kostenlos testen.

Keine Kreditkarte heute. Kündigung jederzeit.