Cyber Resilience Act: what it is and who it applies to

The Cyber Resilience Act is Regulation (EU) 2024/2847, the EU law that sets cybersecurity requirements for products with digital elements: hardware and software that connect, directly or indirectly, to a device or a network. It applies in full from 11 December 2027, but the duty to report actively exploited vulnerabilities and severe incidents has applied since 11 September 2026.

The question most readers bring is practical: does it reach my organisation, and by when? This guide answers with the criteria in the text and with the real timeline, which has three dates rather than one.

What the Cyber Resilience Act is

The full title is 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. It was published in the Official Journal of the European Union on 20 November 2024 and entered into force on the twentieth day after publication, 10 December 2024.

It is a regulation, not a directive, so it applies directly in every Member State: there is no national transposition to wait for, unlike the NIS2 Directive. Member States still designate market surveillance authorities (Article 52) and lay down penalty rules within the ceilings of Article 64.

Article 1 covers four things: rules for making these products available on the market, essential requirements for their design, development and production, requirements for the vulnerability handling processes manufacturers run while the products are in use, and market surveillance. In practice it brings cybersecurity into the logic of CE marking: a product that does not meet the requirements cannot be placed on the EU market.

Does it apply to your organisation? Four checks

Scope is settled in four steps. The first two tell you whether you are in; the other two tell you how much work it means.

1. The product has a data connection

Under Article 2(1), the regulation applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes "a direct or indirect logical or physical data connection to a device or network". Article 3(1) defines a product with digital elements broadly: any software or hardware product and its remote data processing, including software or hardware components placed on the market separately.

Two details widen the scope more than most people expect. The connection can be indirect, so a component that talks only to another device, which in turn goes online, is in. And the definition of manufacturer covers products marketed "whether for payment, monetisation or free of charge", so software given away as part of a commercial activity is in too.

What counts is the EU market, not where the manufacturer is based. A company in the United States or the United Kingdom that sells connected products in the EU is within reach of the regulation, and Article 14(7) tells it which national CSIRT receives its reports when it has no main establishment in the Union.

2. Your role in the supply chain

The heaviest obligations, Articles 13 and 14, sit with the manufacturer: whoever develops or manufactures the product, or has it designed, developed or manufactured, and markets it under its own name or trademark. Article 21 extends this:

• an importer or distributor is considered a manufacturer, and is subject to Articles 13 and 14, when it places a product on the market under its own name or trademark;
• the same applies when it carries out a substantial modification of a product already on the market, meaning a change that affects compliance with the essential requirements or changes the intended purpose for which the product was assessed;
• Article 22 applies the same logic to anyone else who substantially modifies a product and makes it available on the market, for the part affected by the change, or for the entire product if the change affects its cybersecurity as a whole.

In practice: a white-label device sold under your brand makes you the manufacturer; a machine with an embedded software module, sold under your brand, makes you the manufacturer; a significantly customised third-party product that you resell makes you the manufacturer for the modified part, or for the whole product. Who wrote the code does not move the responsibility.

3. What is excluded

The exclusions in Article 2 are precise: products covered by the regulations on medical devices and in vitro diagnostic medical devices (Regulations (EU) 2017/745 and 2017/746) and on motor vehicle type-approval (Regulation (EU) 2019/2144), products certified under the civil aviation regulation (Regulation (EU) 2018/1139), marine equipment under Directive 2014/90/EU, spare parts that replace identical components, and products developed or modified exclusively for national security or defence purposes or designed to process classified information.

Software delivered as a service needs its own paragraph. Remote data processing is in scope only when the software behind it is designed and developed by the manufacturer, or under its responsibility, and the product could not perform one of its functions without it (Article 3(2)). Recital 12 gives the example: cloud functions that let users control a smart home device remotely are in; cloud services designed and developed outside the responsibility of a product manufacturer are not, and "Directive (EU) 2022/2555 applies to cloud computing services and cloud service models, such as Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS)". As a rule, then, a business application sold by subscription and used through a browser is out, while the app that controls a device and the back end it depends on, both built by the device maker, are in. The check is made case by case against the definition.

4. Whether the product is important or critical

If you are in scope, the category decides how you show conformity. Annex III lists important products in two classes, by core functionality. Class I has 19 categories, among them identity and privileged access management, browsers, password managers, VPN products, SIEM systems, operating systems, routers, modems and switches, and smart home products with security functions. Class II has four: hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors and tamper-resistant microcontrollers. Annex IV lists critical products: hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes, and smartcards or similar devices, including secure elements.

The trade name of a product does not settle its category. The technical description of each category is in Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025, published in the Official Journal on 1 December 2025.

Classification matters because it changes the conformity assessment procedure (Article 32):

• products that are neither important nor critical can use internal control (module A);
• class I products can use internal control only if the manufacturer fully applies harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial; otherwise a notified body is involved;
• class II products always go through EU-type examination, full quality assurance or a European certification scheme;
• critical products use a European cybersecurity certification scheme where Article 8(1) requires one, and otherwise one of the class II procedures.

That is why Chapter IV, on notified bodies, applied before the rest.

The timeline: three dates, not one

This is where most of the errors in circulation come from. Article 71(2) sets three separate dates.

1. 11 June 2026: Chapter IV (Articles 35 to 51) applies, the rules on notifying authorities and notified bodies.
2. 11 September 2026: Article 14, the manufacturers' reporting obligations, applies. This date has passed: reporting is already required.
3. 11 December 2027: everything else applies, including the essential requirements, CE marking, the EU declaration of conformity, technical documentation and conformity assessment.

The transitional rule in Article 69 deserves a careful read. Article 69(2) says that products placed on the market before 11 December 2027 are subject to the regulation only if they undergo a substantial modification from that date. Article 69(3) then makes an explicit exception: the Article 14 obligations apply to all in-scope products placed on the market before 11 December 2027. The installed base is not exempt from reporting, even where it is exempt from the product requirements until a substantial modification.

What it requires in practice

Product requirements

Annex I, Part I, lists the essential requirements, applied on the basis of the cybersecurity risk assessment that Article 13 requires manufacturers to carry out and document. The ones that take most effort to demonstrate: no known exploitable vulnerabilities when the product is made available, a secure by default configuration, vulnerabilities that can be fixed through security updates, access control with reporting of possible unauthorised access, confidentiality and integrity of data, availability of essential functions also after an incident, a limited attack surface, and recording and monitoring of relevant internal activity.

Vulnerability handling and the support period

Annex I, Part II, is about processes, and for many organisations it is the part that is missing:

• a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies;
• remediation without delay, with security updates provided separately from functionality updates where technically feasible;
• regular tests and reviews of the security of the product;
• public disclosure of fixed vulnerabilities once an update is available;
• a coordinated vulnerability disclosure policy, with a contact address for reports;
• secure distribution of updates, disseminated without delay and, except for tailor-made products where agreed otherwise with a business user, free of charge.

This ties in with the support period in Article 13(8). The manufacturer sets it to reflect how long the product is expected to be in use, but the text sets a floor: at least five years, unless the product is expected to be in use for less. Each security update made available during the support period stays available for at least ten years after it is issued, or for the rest of the support period if that is longer (Article 13(9)). The end date of the support period, at least month and year, is stated clearly at the time of purchase (Article 13(19)).

For equipment with a long working life this is the clause with the largest cost: it commits development effort to versions that would otherwise be closed. The regular tests and reviews of Part II are the kind of work a recurring vulnerability management programme covers, not a one-off check before launch; our overview of vulnerability management tools covers how teams run that cycle.

Reporting: 24 hours, 72 hours, final report

Article 14, the part that already applies, covers two events, notified simultaneously to the CSIRT designated as coordinator and to ENISA through the single reporting platform of Article 16: actively exploited vulnerabilities contained in the product, and severe incidents having an impact on the security of the product.

A vulnerability is actively exploited when "there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (Article 3(42)). Under Article 14(5), an incident is severe when it affects, or can affect, sensitive or important data or functions of the product, or when it has led or can lead to malicious code being introduced or run in the product or in a user's systems. The steps:

• early warning within 24 hours of the manufacturer becoming aware of it;
• notification within 72 hours, with general information on the product, the nature of the exploit or incident, and corrective or mitigating measures, including those users can take;
• final report within 14 days after a corrective or mitigating measure is available, for a vulnerability, or within one month of the 72-hour notification, for a severe incident.

The report goes to the CSIRT of the Member State where the manufacturer has its main establishment in the Union, the one where decisions on product cybersecurity are predominantly taken. A manufacturer with no main establishment in the Union follows the order in Article 14(7): the Member State of its authorised representative, then of its importer, then of its distributor (in each case the one handling the highest number of its products), then the Member State where most of its users are located.

Article 14(8) adds a duty towards the market: the manufacturer informs impacted users, and where appropriate all users, of the vulnerability or incident and, where necessary, of the mitigation measures they can take. The sequence resembles NIS2 incident reporting, but one does not replace the other: under NIS2 an entity reports an incident affecting its own services; under the Cyber Resilience Act a manufacturer reports a flaw in a product it has placed on the market, which reaches every user who installed it.

Penalties

Article 64 leaves the penalty rules to Member States but sets the ceilings for administrative fines, in each case whichever amount is higher:

• up to EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, for non-compliance with the essential requirements of Annex I and the obligations in Articles 13 and 14;
• up to EUR 10 million or 2% for the obligations listed in Article 64(3), which include those of authorised representatives, importers and distributors, the EU declaration of conformity, CE marking, technical documentation and conformity assessment;
• up to EUR 5 million or 1% for supplying incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in reply to a request.

Article 64(10) sets two exemptions, and it should be read in its corrected wording. A corrigendum published on 2 July 2025 changed its opening from "paragraphs 3 to 9" to "paragraphs 2 to 9", so the exemption also covers the top tier of fines. As corrected, the fines in paragraphs 2 to 9 do not apply to manufacturers that qualify as microenterprises or small enterprises for failing to send the 24-hour early warning on time (Article 14(2)(a) or 14(4)(a)), nor to any infringement by open-source software stewards.

Cyber Resilience Act and NIS2: two scopes that meet

The two laws are different and are best kept apart. NIS2 looks at who provides services in listed sectors and asks for risk-management measures on the organisation's own systems; the Cyber Resilience Act looks at what you place on the market. An organisation can be outside one and inside the other, or inside both with two separate compliance tracks. For the NIS2 side, our NIS2 compliance service starts from the sector and size criteria of the directive.

Where they meet is the supply chain, which is why this regulation lands on the desks of companies that were not following it. NIS2 entities manage the cybersecurity risk of their suppliers, and Article 5(2) of the Cyber Resilience Act asks Member States to take compliance with the essential requirements, including the manufacturer's ability to handle vulnerabilities effectively, into consideration when they procure in-scope products. In practice this means questionnaires, contract clauses and requests for evidence passed down the chain, the same pattern described in our guide to third-party risk management. A supplier of components to a regulated customer will be asked for its documentation before December 2027, not in December 2027.

Where to start now

With Article 14 already applying and full application in December 2027, the useful work over the coming months follows an order. Five steps.

1. Inventory the products you place on the EU market under your name, software included, noting whether each has a direct or indirect data connection.
2. Assign a role for each product, in the light of Articles 21 and 22: manufacturer, importer, distributor, or manufacturer in practice because you rebrand or modify.
3. Classify what remains in scope, against Annexes III and IV and Implementing Regulation (EU) 2025/2392: the class decides whether you need a notified body.
4. Run the part that already applies: who monitors vulnerabilities in your products, who decides whether one is actively exploited, who sends the early warning within 24 hours and with what data. It is a process with names and rotas, not a written procedure filed away.
5. Build the Part II processes: software bill of materials, coordinated disclosure policy, the rhythm of security testing, the decision on the support period and how you state it.

The last two steps are organisational before they are technical, and they are what a customer will ask about first, well before a market surveillance authority does.

If you are mapping your products against the regulation and want to discuss how to set up vulnerability monitoring and the reporting process, see how we work on cybersecurity: we start from what you already have in place.

In short: the Cyber Resilience Act is Regulation (EU) 2024/2847 on products with digital elements, in force since 10 December 2024 and fully applicable from 11 December 2027, with the Article 14 reporting obligations applying since 11 September 2026. It reaches manufacturers, and also those who sell under their own brand or make a substantial modification. The real work is not the certificate: it is knowing which products you have on the market, who answers for them and how you handle their vulnerabilities for as long as they are in use.