The Cyber Resilience Act: what the Regulation requires and when it applies

A company selling a connected thermostat, a router, an alarm system or plain software installed on its customers’ machines could long treat cybersecurity as a matter of commercial diligence: a selling point, perhaps a contractual clause. Requirements did exist, but they were sectoral and scattered. Regulation (EU) 2024/2847, known as the Cyber Resilience Act, puts a horizontal framework in place: it makes the making available of a product on the Union market conditional on compliance with the essential requirements in Annex I and, before placing on the market, on completing the conformity assessment procedure, drawing up the EU declaration of conformity and affixing the CE marking.¹ Narrow allowances exist for trade fairs, demonstrations and unfinished software distributed for testing, provided it bears a visible mark of non-compliance.²

The shift runs deeper than it looks. The GDPR governs the processing of personal data, from collection through to security. The Cyber Resilience Act governs what an object is, before any data has been processed at all. The two texts have distinct subject matters, but their scopes may overlap, in which case they apply cumulatively.

What the Regulation calls a product

The definition is broad, and that is the first trap. A “product with digital elements” is a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately.³ Three consequences follow directly from that sentence.

First, software on its own may be a product. No enclosure is required: standalone software falls within scope where it is made available on the market in the course of a commercial activity and where its intended or reasonably foreseeable use includes a direct or indirect, logical or physical connection to a device or network.⁴

Second, a component may be a product in its own right. A library, a module or a board placed on the market separately constitutes a distinct product, subject to the same conditions of scope and to the Regulation’s exclusions.

Third, a remote data processing solution may form part of the regulated product. It is covered only where the software is designed and developed by the manufacturer or under its responsibility, and where its absence would prevent the product from performing one of its functions.⁵

That last point settles a question we are often asked, and it is worth quoting in the text’s own terms rather than paraphrasing it. Recital 12 states that cloud functionalities provided by a manufacturer of smart home devices, allowing the device to be controlled remotely, fall within the Regulation, whereas websites that do not support the functionality of a product with digital elements do not.⁶ The exclusion should be stated precisely: it turns on the functional link, not on the genre of the site. A website that does not support the functionality of a product with digital elements does not, on that ground, fall within scope. Providers of cloud computing services may instead fall under the NIS 2 Directive, in particular where they meet the enterprise thresholds recalled in that same recital.⁷

The Regulation also excludes, expressly and by category, products covered by the Regulations on medical devices, on in vitro diagnostics and on the general safety of motor vehicles, along with products certified under civil aviation rules.⁸ Further sectoral limitations may be adopted by delegated act, on condition that the sectoral rules afford the same or a higher level of protection.⁹ Also outside scope are spare parts manufactured to the same specifications as the component they replace, and products developed exclusively for national security or defence purposes.¹⁰

The timeline, and why the first deadline is not 2027

It is widely reported that the Cyber Resilience Act “will apply in 2027”. That is true of most of the text, and false of what arrives first. Article 71 sets one date of entry into force and three successive dates of application.¹¹

The Regulation entered into force on the twentieth day following its publication in the Official Journal, which took place on 20 November 2024, hence on 10 December 2024.¹²

On 11 June 2026, Chapter IV, that is, Articles 35 to 51, becomes applicable. That chapter organises the notification of conformity assessment bodies. It does not directly impose obligations on manufacturers, but it establishes the framework without which products requiring third-party involvement could not be assessed.

On 11 September 2026, Article 14 becomes applicable. This is the deadline most often overlooked: the duty to report actively exploited vulnerabilities and severe incidents applies fifteen months before the rest of the Regulation.

On 11 December 2027, the Regulation applies in full. From that date, a newly placed product must comply with the whole text. Products already placed on the market before that date fall under the Regulation’s requirements only if they undergo a substantial modification; by way of derogation, the reporting obligations in Article 14 apply to them.¹³

What the manufacturer has to do

Article 13 is the heart of the text. It requires products to be designed, developed and produced in accordance with the essential cybersecurity requirements of Annex I, Part I.¹⁴ Compliance must be supported by a cybersecurity risk assessment, documented, updated as appropriate over the support period, and included in the technical documentation.¹⁵ Depending on the product category, conformity assessment may nonetheless rest on the manufacturer’s internal control: the demonstration is demanding, it is not necessarily external.¹⁶ Where an essential requirement does not apply to the product, the technical documentation must include a clear justification for that inapplicability: silence is not an exemption.¹⁷

Four obligations deserve to be singled out, because they bear immediately on how a product is designed and sold.

The support period, and its five-year floor. The manufacturer sets the period during which it will handle vulnerabilities, based on how long the product is expected to be in use and on reasonable user expectations. But that period is at least five years, unless the product is expected to be in use for a shorter time, in which case it matches the expected use.¹⁸ The factors used to set the duration go into the technical documentation: the chosen period must be justified there, not merely disclosed.¹⁹

The end-of-support date, disclosed at the time of purchase. It must be specified, at minimum by month and year, in a clear, understandable and easily accessible manner at the time of purchase and, where applicable, on the product, its packaging or by digital means.²⁰ The duty is first of all one of information: what the manufacturer knows about the end of its product’s life, the buyer must know before buying.

Security updates, available for ten years. Every security update issued during the support period must remain available for at least ten years after its release, or for the remainder of the support period where that is longer.²¹ Fixes must moreover be distributed without delay and free of charge, save where a manufacturer and a business user have agreed otherwise in respect of a tailor-made product.²²

The software bill of materials. The manufacturer must identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies of the product.²³ The wording repays a second reading: the Regulation does not require the full dependency tree, but its first level.

To which are added a single point of contact, genuinely reachable and not limited to automated tools, so that users can report a flaw,²⁴ and two distinct rules on third-party components that should not be conflated. The duty of due diligence when selecting components expressly covers free and open-source components that were not made available on the market in the course of a commercial activity.²⁵ Separately, any vulnerability identified in an integrated component, including an open-source software component, must be reported to the person or entity maintaining it, and any fix shared with them, in a machine-readable format where appropriate.²⁶

Reporting deadlines, applicable from September 2026

Article 14 sets up a twofold reporting chain addressed simultaneously to the CSIRT designated as coordinator and to ENISA, through a single reporting platform.²⁷

For an actively exploited vulnerability: an early warning no later than 24 hours after becoming aware of it; a vulnerability notification no later than 72 hours; then a final report no later than 14 days after a corrective or mitigating measure becomes available.²⁸

For a severe incident having an impact on the security of the product: the same 24-hour and 72-hour deadlines, but a final report within one month of the incident notification.²⁹ An incident is severe where it negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user’s network and information systems.³⁰

Meeting those deadlines presupposes internal procedures able to qualify the event quickly, to identify who decides, and to establish who signs the notification. That is what makes the September 2026 deadline demanding well before the 2027 one, even though it attracts less attention.

Not every product category takes the same route

Two annexes depart from the ordinary regime. Annex III lists important products in two classes: Class I covers, among others, password managers, browsers, operating systems, routers and modems intended for the connection to the internet, smart home general purpose virtual assistants, smart home products with security functionalities including smart door locks and security cameras, and internet connected toys covered by Directive 2009/48/EC that have social interactive features or location tracking features; Class II covers hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers.³¹ Annex IV, shorter, lists critical products: hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes including secure cryptoprocessing, and smart cards and secure elements.³² A product’s classification determines the applicable conformity assessment procedure.³³

Open source, treated separately

The Regulation creates a new figure, the open-source software steward: a legal person, other than a manufacturer, whose purpose is to provide systematic and sustained support for the development of specific free and open-source products intended for commercial activities, and which ensures their viability.³⁴ Its obligations are reduced and adapted: to put in place and verifiably document a cybersecurity policy, to cooperate with market surveillance authorities, and, in defined circumstances, to report vulnerabilities and incidents.³⁵

The individual contributor is not caught by that construction. Recital 18 confines the Regulation to free and open-source software made available on the market, that is, supplied for distribution or use in the course of a commercial activity.³⁶ A voluntary security attestation programme may also be established by the Commission, which is empowered to do so without being required to.³⁷

Penalties

Member States set the penalty regime, but the Regulation itself fixes the ceilings. Non-compliance with the essential requirements of Annex I and with the obligations in Articles 13 and 14 is subject to administrative fines of up to EUR 15 000 000 or, for an undertaking, up to 2.5 % of its total worldwide annual turnover, whichever is higher.³⁸ Breach of the obligations expressly listed in Article 64(3) carries a ceiling of EUR 10 000 000 or 2 %,³⁹ and the supply, in response to a request, of incorrect, incomplete or misleading information to notified bodies or market surveillance authorities, a ceiling of EUR 5 000 000 or 1 %.⁴⁰

Two qualifications deserve to be known, because they are rarely cited. The size of the operator, in particular where it is a microenterprise, an SME or a start-up, is among the factors that must be duly taken into account in setting the amount.⁴¹ And the Regulation intends to exempt microenterprises and small enterprises from fines incurred for missing the 24-hour early warning deadline alone, subject to a drafting caveat worth flagging.⁴²

What the Regulation is not

It is not a data protection regime. A company compliant with the GDPR is not thereby compliant with the Cyber Resilience Act, and the converse holds just as firmly: the two texts share neither subject matter, nor notification criteria, nor legal bases. Nothing prevents a Member State from conferring several competences on a single authority, however, and some deadlines coincide, notably the 72-hour one.

Nor is it the NIS 2 Directive. NIS 2 lays down risk-management and reporting obligations for entities, sector by sector; the Cyber Resilience Act addresses products, category by category. One company may fall under both, on two different grounds, and may have to report a single event under two distinct regimes.

Finally, it is not a text for security specialists. Its heaviest consequences are commercial and documentary: a support period that has to be set, justified and disclosed, an end-of-support date the buyer knows before buying, an inventory of components one has to be able to produce, and a 24-hour deadline that presupposes a decision, not merely a technical team.

A divergence between language versions, worth knowing

The transitional rule in Article 69(3) does not mean the same thing depending on the language in which it is read. The English and Italian versions cover products placed on the market before 11 December 2027, which gives the derogation its purpose: extending the reporting obligations to the installed base. The French version covers products placed on the market on 11 December 2027, which would leave it with nothing to operate on. Both versions are equally authentic.⁴³ A French-speaking reader with only that version to hand will therefore conclude the opposite of what the text means.

What is still to come

The Regulation still provides for the adoption of harmonised standards conferring presumption of conformity, for possible implementing acts specifying the format of the software bill of materials,⁴⁴ and for Member States to lay down their penalty regimes.⁴⁵ This review will follow them as they appear, and will date every update.

The Swiss dimension is the subject of a separate article. Switzerland is not in the internal market, but a Swiss manufacturer is concerned as soon as a product within scope is made available on the Union market, whether directly or through its distribution chain. The Federal Council has moreover instructed the Federal Office for Cybersecurity, together with OFCOM and SECO, to prepare a consultation draft on the cyber resilience of digital products by autumn 2026.⁴⁶

Notes

1. 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, OJ L, 2024/2847, 20.11.2024. Art. 6 for the condition on making available on the market, and Art. 13(12) for the chain running from documentation and conformity assessment to the EU declaration of conformity and the CE marking. ↩

2. Art. 4(2) and (3), subject to Art. 4(4) for safety components covered by other Union harmonisation legislation. ↩

3. Art. 3(1). ↩

4. Art. 2(1), and recital 18 for the commercial activity condition. ↩

5. Art. 3(2). ↩

6. Recital 12. ↩

7. Recital 12, final sentences, referring to Directive (EU) 2022/2555 and to the thresholds in Recommendation 2003/361/EC. ↩

8. Art. 2(2) to (4), referring to Regulations (EU) 2017/745, (EU) 2017/746, (EU) 2019/2144 and (EU) 2018/1139. ↩

9. Art. 2(5). ↩

10. Art. 2(6) and (7). ↩

11. Art. 71(1) for entry into force, Art. 71(2) for the three dates of application. ↩

12. Art. 71(1), read together with the date of publication in the Official Journal, 20 November 2024. It may be noted that the Swiss Federal Council’s press release of 20 August 2025 dates the Regulation’s entry into force to 11 December 2024; the calculation under Art. 71(1) yields 10 December 2024. The difference is of no practical consequence, but it illustrates how readily a secondary date propagates. ↩

13. Art. 69(2) and (3). On the drafting of the latter, see the final section of this article. ↩

14. Art. 13(1). ↩

15. Art. 13(2) to (4), and Annex VII for the content of the technical documentation. ↩

16. Art. 32 for the applicable procedures, and Annex VIII for internal control. ↩

17. Art. 13(4), final sentence. ↩

18. Art. 13(8), third subparagraph. ↩

19. Art. 13(8), fifth subparagraph. ↩

20. Art. 13(19). ↩

21. Art. 13(9). ↩

22. Annex I, Part II, point 8. ↩

23. Annex I, Part II, point 1. ↩

24. Art. 13(17). ↩

25. Art. 13(5). ↩

26. Art. 13(6). ↩

27. Art. 14(1) and (7), and Art. 16 for the single reporting platform. ↩

28. Art. 14(2)(a) to (c). ↩

29. Art. 14(4)(a) to (c). ↩

30. Art. 14(5). ↩

31. Annex III, Classes I and II. ↩

32. Annex IV. ↩

33. Art. 32. ↩

34. Art. 3(14). ↩

35. Art. 24(1) to (3). ↩

36. Recital 18. ↩

37. Art. 25, which empowers the Commission to adopt delegated acts establishing voluntary security attestation programmes, without obliging it to do so or setting a deadline. ↩

38. Art. 64(2). ↩

39. Art. 64(3), which lists the provisions concerned exhaustively. ↩

40. Art. 64(4). ↩

41. Art. 64(5)(c). ↩

42. Art. 64(10)(a). The caveat lies in the drafting: that paragraph derogates “from paragraphs 3 to 9” and disapplies “the administrative fines referred to in those paragraphs”, whereas a breach of Art. 14 is penalised under paragraph 2. Read literally, the exemption would not reach the fine it is meant to disapply. It nonetheless refers expressly to the deadline in Art. 14(2)(a): that is the only reading which leaves it any purpose. ↩

43. Art. 69(3). Versions consulted on 1 August 2026 on EUR-Lex: English, Italian and French. The English reads “placed on the market before 11 December 2027” and the Italian “immessi sul mercato prima dell’11 dicembre 2027”, where the French reads “mis sur le marché le 11 décembre 2027”. ↩

44. Art. 13(24). ↩

45. Art. 64(1). ↩

46. Swiss Federal Council, press release of 20 August 2025, “Federal Council wants to strengthen the cyber resilience of digital products”. ↩