The Cyber Resilience Act is the EU regulation that imposes mandatory cybersecurity requirements on products with digital elements. It applies to every product made available in the European Union. It was adopted as Regulation (EU) 2024/2847 and came into force on 10 December 2024. It covers manufacturers, importers and distributors, and reaches both hardware and software, from a router to a mobile app. Its obligations arrive in stages. The reporting obligations have applied since 11 September 2026. The bulk of the regulation applies from 11 December 2027. Non-compliance is punishable by up to 15 million euros or 2.5% of worldwide turnover.
If you need a lawyer to help you comply with the Cyber Resilience Act, request a free initial assessment.
Any software or hardware product with a logical or physical, direct or indirect data connection to a device or network falls within it. The definition includes the remote data processing solutions associated with the product and components placed on the market separately. The test is connectivity, not the sector or the size of the company that makes it.
That breadth surprises many companies that do not see themselves as technology manufacturers. An industrial machinery company that sells equipment with a connected touch panel is within it. An advisory firm that markets its own management software is within it. A maker of internet-connected toys is within it.
Article 2 excludes seven cases, almost all because they already have their own sector-specific cybersecurity rules.
Free software developed without a commercial purpose is also outside. That exclusion has a nuance. When free software is intended for commercial use, an intermediate figure with its own obligations appears, which is explained further on.
The regulation covers four figures with decreasing intensity. The manufacturer carries the main burden, including the essential requirements of Annex I and the reporting under Article 14. The importer checks that the product it brings into the European market complies. The distributor checks the CE marking and that the manufacturer and importer have done their part. The authorised representative acts on behalf of a manufacturer with no establishment in the Union.
A manufacturer, for the purposes of the regulation, is not whoever physically assembles the product. It is whoever develops a product, or has it developed, and markets it under its own name or trademark. A company that commissions the development of its app and publishes it under its brand is a manufacturer. It makes no difference that it has not written a single line of code.
When the manufacturer is outside the Union, responsibility follows a chain. First the authorised representative is liable. Failing that, the importer. Then the distributor. And as a last resort, the Member State where the largest number of users is located is taken into account.
An importer or distributor is considered a manufacturer in two cases under Article 21. The first is placing the product on the market under its own name or trademark. The second is carrying out a substantial modification of a product already on the market. In both cases it becomes subject to Articles 13 and 14. It takes on the manufacturer’s full obligations and the duty to report vulnerabilities within 24 hours.
It is the quietest legal trap in the regulation, because it does not depend on what the company does but on how it labels what it sells. The white-label model, common in consumer electronics and industrial distribution, turns the distributor into a manufacturer without it noticing. The same happens to an integrator that repackages third-party software under its own brand.
The practical consequence is that a distributor with no technical development capacity takes on the obligation to handle vulnerabilities in a product it does not control. The only reasonable way out is contractual. Before putting your own brand on someone else’s product, three things should be agreed with the original supplier. Access to technical information, a patching commitment and internal deadlines compatible with the 24 hours.
Article 24 creates the figure of the open-source software steward. It is the legal person that provides sustained support for an open-source program intended for commercial use. It is not a manufacturer and does not carry a manufacturer’s obligations. It must adopt a documented cybersecurity policy, handle vulnerabilities effectively and cooperate with the market surveillance authorities.
Article 64 goes further and completely excludes these stewards from administrative fines. It is one of the few exemptions based on who the operator is. It reflects the legislator’s concern not to stifle the European open-source ecosystem.
Classification determines how compliance is demonstrated, not whether the product is covered. There are four levels. Default products, which are all those not listed, allow self-assessment. Important products of class I and II are listed in Annex III. Critical products are listed in Annex IV. The more sensitive the function, the more weight the involvement of an independent third party carries.
| Category | Where it is listed | How conformity is assessed | Examples |
|---|---|---|---|
| Default | Not listed | Self-assessment through internal control, technical file and EU declaration of conformity | Most management software and connected consumer devices |
| Important, class I | Annex III | Self-assessment if harmonised standards are applied. Otherwise, third-party involvement | Browsers, password managers, antivirus software, VPNs, operating systems, routers, smart home products with security functions, connected toys with tracking |
| Important, class II | Annex III | Assessment by a notified body | Firewalls, hypervisors and container runtimes, intrusion detection and prevention systems, tamper-resistant microprocessors |
| Critical | Annex IV | European cybersecurity certification may be required | Hardware security modules, smart meter gateways, smartcards and secure elements |
Classification depends on the product’s core functionality, not on its ancillary functions. An accounting program with a password manager for its own login does not become an important class I product as a result.
For almost a year classification was a source of uncertainty, because the annexes described the categories in generic terms. Implementing Regulation (EU) 2025/2392 of 28 November 2025 published the technical descriptions of each category of important and critical products. That text is now the starting point for any analysis of where a product fits. The 26 categories and their technical descriptions are in our guide to product classification under the Cyber Resilience Act.
The manufacturer must design, develop and produce the product in line with the essential requirements of Annex I. And it must maintain that conformity throughout the support period. It is not a one-off certification step, it is a continuing obligation that survives the sale.
The obligations fall into five groups.
The support period is the piece that requires the most planning. Article 13(8) sets a minimum of five years. A shorter period is only allowed where the product’s expected time of use is shorter, as with an app designed for a specific event. The manufacturer must determine that period, inform the user of it and honour it, even if the product is no longer sold.
Five years of patching commitment force decisions that are not legal ones. A manufacturer that integrates a third-party library with no long-term support is taking on an obligation it will not be able to meet with its own resources.
Since 11 September 2026, the manufacturer has had to report actively exploited vulnerabilities and severe incidents having an impact on the security of the product. The regime is built on three successive communications about the same event. The deadlines are 24 hours, 72 hours and 14 days or one month depending on the case.
Reports are submitted through the single platform managed by ENISA and are addressed to the CSIRT designated as coordinator in the Member State of the main establishment. Since 4 September 2026, Spain has routed its notifications through INCIBE-CERT.
This obligation is the only one in the regulation that already applies to older products. Article 69(3) extends it to all products placed on the market before 11 December 2027, however old they are. The deadlines, the parties concerned and the minimum content of each communication are in our analysis of vulnerability reporting under the Cyber Resilience Act.
A compliant product bears the CE marking and comes with an EU declaration of conformity in which the manufacturer assumes responsibility. It is the same mechanism that already applies to electrical safety or electromagnetic compatibility, now extended to cybersecurity. Without CE marking, the product cannot be made available in the Union from 11 December 2027.
The route to that marking depends on the category. A default product is assessed internally under module A. An important class I product can follow that same route if the manufacturer applies harmonised standards covering the applicable requirements. If it does not apply them, or if the product is class II, a notified body is involved. Critical products in Annex IV may become subject to a European certification scheme.
Notified bodies are the piece that makes all of this possible. The procedures for notifying them have applied since 11 June 2026. The network had to exist before the marking became mandatory. The full procedure, the technical documentation and the declaration are in our guide to CE marking under the Cyber Resilience Act.
The regulation does not come into force all at once. It spreads its obligations over four milestones across three years, and three have already passed.
| Date | What happens | Status |
|---|---|---|
| 10 December 2024 | Entry into force of the regulation | Passed |
| 11 June 2026 | The procedures for notifying conformity assessment bodies apply | Passed |
| 11 September 2026 | The reporting obligations in Article 14 become enforceable | Passed |
| 11 December 2027 | Full application. Essential requirements, CE marking and declaration of conformity | Pending |
Fifteen months separate September 2026 from December 2027. During that period a fully enforceable duty to report coexists with technical requirements that do not yet apply. A manufacturer can be required to report a vulnerability in a product that does not yet have to meet Annex I.
On 27 July 2026 the Commission adopted Communication C(2026) 5252, which contains the guidance on applying the regulation provided for in its Article 26. It is aimed above all at microenterprises and SMEs, and includes 67 practical examples. It is not binding, because the authoritative interpretation of the regulation is for the Court of Justice of the European Union. But it expresses the Commission’s official view and also serves to guide market surveillance authorities and notified bodies. The text is published in the European Commission’s library. These are the clarifications that most change a company’s work.
Many manufacturers will keep selling after 11 December 2027 units of models designed earlier. The guidance clarifies that compliance does not necessarily require redesigning them. The manufacturer has to carry out the risk assessment under Article 13(2), and if it shows that the product already incorporates adequate security measures, it can rely on them.
What does not disappear is the procedure. Those units need their conformity assessment, their EU declaration of conformity and their CE marking. The guidance does lighten the documentary burden. There is no need to reconstruct the design documentation or the tests from the original phase, and any tests that are needed can be grouped by product families.
For the regulation, only software with a free licence granting all rights of use, modification and redistribution, and whose source code is published, counts as free software. A program with a free licence whose code only paying customers receive does not count. Nor is someone who merely contributes code to someone else’s project liable. Responsibility lies with whoever publishes the program and decides its releases.
The guidance sets out when free software is supplied in the course of a commercial activity and becomes subject to the regulation.
By contrast, offering training or consultancy separately on a program anyone can download for free is not enough. Nor is accepting donations, unless in practice they work as a price because they make access to the program or its updates conditional on them.
The guidance devotes a whole section to software that is updated continuously. The test is not the size of the change, but whether it alters the cybersecurity risk and whether that risk was not already covered by the manufacturer’s risk assessment. A new feature that changes the product’s intended purpose will normally be a substantial modification. A feature planned and assessed from the design stage is not. A seemingly minor feature can be. The guidance’s example is the option to stay logged in, which stores authentication tokens on the device.
Security updates are, as a general rule, not substantial modifications. They stop being exempt when they change the product’s intended purpose or add unforeseen risks, for example externally accessible interfaces or dependencies on third-party services. To decide, the guidance proposes four questions.
The consequence matters. A substantially modified product is treated as a new product placed on the market. If someone other than the manufacturer modifies it, that person becomes a manufacturer, although its obligations can be limited to the modified part when the change does not affect the security of the product as a whole. The same proportionality applies to an original manufacturer that, after December 2027, modifies a product placed on the market earlier.
The guidance corrects a widespread reading. The five years in Article 13(8) are a floor. A product expected to be used for longer must have a longer support period. The manufacturer has to state at the time of purchase the end date of support, at least by month and year. And, where technically possible, notify the user when support ends.
For software with successive versions, each substantially modified version needs its own declared support period. Article 13(10) allows vulnerabilities to be fixed only in the latest version if users can update for free and without additional costs. According to the guidance, those additional costs are buying new hardware or replacing infrastructure, not the testing or configuration time that any update involves. And a substantial modification does not automatically restart the support period, which is only recalculated if the product’s expected time of use changes.
The regulation includes the product’s remote data processing solutions within the product. The guidance clarifies that a remote solution forms part of the product when two conditions are met at the same time.
It makes no difference where it runs. An on-premises server at the manufacturer counts the same as a public cloud. Outside it are the company’s internal systems, such as human resources, CRM or integration and deployment environments, telemetry for purely statistical purposes and websites that merely provide information about the product. A third party’s SaaS application does not form part of the product either, but the manufacturer must treat it as a component, assess its risks and exercise due diligence. The guidance suggests including security assurances in service level agreements with those providers.
The deadline runs from when the manufacturer becomes aware of the event. The guidance places this at the moment when, after an initial assessment, it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has compromised its security. That assessment must be carried out immediately.
The guidance adds three clarifications. The obligation is not retroactive, so exploitations known before 11 September 2026 do not have to be reported. A vulnerability in a third-party component that cannot be exploited, or has not been exploited, in the product itself is not subject to mandatory reporting, although it must be reported to whoever maintains the component. And the reporting duty continues after the product’s support period ends.
Spain has not yet formally designated its authorities under the regulation. The draft royal decree that is to do so assigns market surveillance to the Secretary of State for Telecommunications and Digital Infrastructure. It reserves the role of notifying authority for the National Cryptologic Centre (CCN). The Spanish competition authority (CNMC) issued its report IPN/CNMC/007/26 (in Spanish) on 13 May 2026 and the text is still being processed.
Two things that are often confused should be kept apart. INCIBE-CERT being listed by ENISA since 4 September 2026 as the coordinating CSIRT settles who receives the reports. It does not settle who supervises the market or who conducts penalty proceedings. The European channel came into service before the national enforcement arm.
The lack of designation does not suspend any obligation. The regulation is directly applicable and needs no national implementing law to be binding. What remains unresolved is the Spanish penalty machinery, not the existence of the duty. It is the same pattern already seen in the European digital regulatory framework with other recent laws.
Article 64 sets three tiers of administrative fines. In each of them the higher of the fixed amount and the percentage of worldwide annual turnover for the preceding financial year applies.
There are two exemptions that are hardly ever mentioned and that change the risk calculation for many companies. Microenterprises and small enterprises cannot be fined for missing the 24-hour early warning deadline. Open-source software stewards cannot be fined for any infringement of the regulation.
The SME exemption is limited and should be read carefully. It covers the 24-hour deadline, not the duty to report. A small company that reports late will not be penalised for the delay. One that does not report at all remains exposed to the highest tier. Which infringement falls in each tier and what Spain still lacks in order to impose penalties is explained in our analysis of Cyber Resilience Act penalties.
The CRA regulates the product. The NIS2 Directive regulates the organisation that provides an essential or important service. The same company can be subject to both on different grounds, and the reporting duties do not replace each other. A software manufacturer that also operates critical infrastructure reports twice, through different channels and with its own deadlines.
With the EU AI Act the relationship is cumulative. A high-risk AI system made available as a product with digital elements must meet the cybersecurity requirements of both texts. The two are expressly linked: under Article 12 of the CRA, a high-risk AI system that meets the CRA’s essential requirements is deemed to meet the AI Act’s cybersecurity requirements.
There is a third front that almost nobody talks about. Directive (EU) 2024/2853 on liability for defective products includes software within the concept of product. And it accepts that a product can be defective because of a lack of security updates. The technical file the CRA requires you to keep will be your evidence of diligence in a civil damages claim. It is the reading that appears least in technical analyses and carries the most weight when there is real harm.
A company in Galicia imports video surveillance cameras from an Asian manufacturer and sells them under its own brand in large retail stores. It does not develop firmware and has no technical department. It considers itself a distributor and assumes its obligations are limited to checking the CE marking.
Article 21 says otherwise. By placing the product on the market under its own name, that company is a manufacturer for the purposes of the regulation. The essential requirements of Annex I, the technical file and the EU declaration of conformity are its responsibility. So are a support period of at least five years and the 24-hour reporting of any exploited vulnerability.
Annex III lists among important class I products smart home products with security functions, and expressly mentions security cameras. If the model is marketed for home use, conformity assessment is no longer free self-assessment. The classification is not automatic and has to be analysed product by product. The units sold in 2025 are still on the market, so the reporting duty already applies to it. CE marking, by contrast, will not be required until December 2027.
The solution is not to stop selling. It is to renegotiate the contract with the Asian manufacturer. Access to the SBOM, a patching commitment compatible with the 24 hours and a split of the cost of updates during the support period. It is contractual work, not technical work.
The regulation came into force on 10 December 2024 and its obligations arrive in stages. Since 11 September 2026 it has been mandatory to report actively exploited vulnerabilities and severe incidents. The rest of the regulation, including the essential requirements of Annex I and CE marking, applies from 11 December 2027.
Yes. The regulation does not distinguish between hardware and software. It reaches any product with a direct or indirect data connection to a device or network, including mobile apps, management software and the remote data processing solutions associated with the product. Most of this software fits the default category, which allows self-assessment.
Yes. Article 21 treats as a manufacturer any importer or distributor that places a product on the market under its own name or trademark, as well as one that carries out a substantial modification of a product already on the market. It becomes subject to Articles 13 and 14, with the manufacturer’s full obligations and the duty to report within 24 hours.
It depends on the product’s category. Default products are self-assessed through internal control. Important class I products in Annex III allow self-assessment if the manufacturer applies harmonised standards covering the applicable requirements. Important class II products require the involvement of a notified body, and critical products in Annex IV may require European cybersecurity certification.
Article 13(8) sets a support period of at least five years. A shorter period is only allowed where the product’s expected time of use is under five years. The manufacturer must determine that period, inform the user of it and maintain it even if the product is no longer sold.
The regulation is directly applicable and binding without any national implementing law. What is pending in Spain is the formal designation of the market surveillance authorities and of the penalty procedure, not the existence of the duty. A delay in designation does not suspend the obligation. Whether breaches committed before the Spanish penalty regime exists can be penalised later is an open question, but measures on the product and civil liability do not depend on it.
The Cyber Resilience Act redistributes responsibility along the whole supply chain, and allocates it on criteria that do not match companies’ commercial intuition. If you sell connected products or software, the scope analysis is best done before December 2027, not after. At Innovatech we review how your products are classified, the contractual allocation of risk with your suppliers and your internal reporting process. Write to us and we will give you a free initial assessment.
Marta Suárez-Mansilla is Managing Partner of Innovatech Legal and a Spanish lawyer (abogada), Madrid Bar (ICAM), working in technology law. She completed Harvard Law School's Copyright course and BerkeleyX's Blockchain programme, and has advised technology companies for more than eight years.