The Commission explains which products fall under the new European cybersecurity regulations ahead of the first obligations in September.

The European Commission has published practical clarifications for manufacturers and developers who need to apply the Cyber Resilience Regulation, including examples about applications, connected devices, open-source software, cloud services, and product updates. The guidelines come before the obligations to report actively exploited vulnerabilities and serious incidents begin on September 11, 2026, and explain how companies must prepare for the full application of the main requirements by December 11, 2027.

In short

1. The rules cover hardware and software connected directly or indirectly to a device or a network, from phones, laptops, and smart appliances to applications, downloadable programs, components, and certain functions processed remotely.

2. From September 11, 2026, manufacturers must report vulnerabilities for which they have evidence that they are being exploited by attackers and serious incidents affecting the security of their products. The first alert must be sent, in general, within 24 hours of confirming the situation.

3. An update becomes a "substantial modification" when it changes the purpose of the product or introduces new or greater cyber risks that have not been previously assessed. A regular security update is generally not considered such a modification.

4. Manufacturers must establish a support period that reflects the estimated lifespan of the product. This must be at least five years, except for products designed for shorter use.

5. The guidelines pay special attention to micro-enterprises and small and medium-sized enterprises and include 67 practical examples, use case scenarios, diagrams, and decision-making schemes. The document is not legally binding and does not replace the assessment of each product.

The Cyber Resilience Regulation changes how products containing digital components and capable of communicating with other devices or networks are treated in the European Union. Until now, the security of such a product largely depended on the manufacturer's practices and the rules applicable to certain sectors. The new framework introduces common requirements for design, development, market introduction, updates, and handling vulnerabilities.

The targeted products include both physical devices and software programs. A phone, a laptop, a router, a smart watch, a connected refrigerator, or industrial equipment can fall under the rules. The same applies to an application installed on a phone, a program downloaded from the internet, the firmware of a device, an operating system, or a hardware component sold separately.

The connection does not have to be necessarily direct to the internet. A product can fall under the regulation if it exchanges data via cable, Wi-Fi, Bluetooth, radio waves, software interfaces, or through a larger system that is connected to a network. An application that does not initiate the connection itself but runs on a connected device may have a relevant indirect link.

An electronic device is not covered solely because it uses software internally. A dishwasher whose firmware controls the washing programs but cannot connect to other devices or networks does not fall within the general scope of the regulation. The same logic applies to a simple electronic computer, an electronic toy, or a coffee maker without connectivity functions.

The guidelines clarify the difference between user-installed software and services accessed exclusively online. An application downloaded and installed on a phone is a product with digital elements. A program installed on a computer, even if built with web technologies, can also be covered.

A web application used only through a browser is not normally treated as a separate digital product. The situation changes if the online functionality is indispensable to a product and was designed by the manufacturer or under its responsibility. In this case, the remote processing part can become a component of the product in the sense of the regulation.

A smart thermostat that relies on manufacturer-hosted cloud software to receive commands from the mobile application provides an example. If the smart functions could not operate without remote processing, and the respective software was developed by the manufacturer or in its name, the relevant cloud system must be included in the product's security assessment.

The manufacturer does not automatically become responsible for the entire infrastructure of the cloud provider. Its responsibility concerns the software that enables the product's operation and the interfaces through which it communicates with external services. Internal payroll systems, personnel management, or general company management do not become part of the product simply because they belong to the same manufacturer.

When the product depends on a service provided by another company, the manufacturer must continue to assess the risks created by this dependency. A cloud storage service, a customer chat, or an external infrastructure may not directly enter the product, but its compromise can affect users. The manufacturer must introduce measures at the product level and check whether the provider offers adequate security guarantees.

The clarifications also establish how products designed before the full application of the regulation should be treated. The fact that a model was designed before December 11, 2027, does not automatically exclude it if new units are introduced to the market after this date.

The manufacturer is not obliged to redesign an older product when it can demonstrate, through risk assessment and technical documentation, that existing measures ensure an adequate level of security. However, it must complete the conformity assessment, prepare the European declaration of conformity, and apply the CE marking before introducing new units to the market.

Products placed on the market before December 11, 2027, are subject to most requirements only if, after this date, they receive a substantial modification. Reporting obligations represent an exception and will also apply to older products that fall under the regulation.

A substantial modification is not determined solely by the size of the update. The decisive element is the effect on the product's purpose or its risk profile. An apparently minor function can produce a substantial change if it opens a new attack vector or modifies how data is protected.

Adding a feature that allows an application to permanently store authentication data can introduce risks of token theft and session hijacking. If such risks have not been previously analyzed, the update can be considered a substantial modification.

The same is possible if a program that only displayed information gains the ability to control machinery or if an application starts to automatically analyze user content and make decisions that were not part of the original purpose. The modified product must then be treated, for the relevant part, as one newly placed on the market.

An update that fixes a vulnerability without changing the product's purpose and without creating new risks is not normally a substantial modification. This rule allows manufacturers to provide important fixes without having to automatically repeat the entire conformity assessment.

Even an update presented as a security one can become substantial if it fundamentally changes the product's architecture. Switching from local file encryption to an external service that stores and processes all data modifies both functionality and data flows and dependencies of the product.

If another company substantially modifies the product and offers it again on the market, it can become the manufacturer of the modified product. Its responsibility may be limited to the changed part if the modification does not affect the security of the entire product. If the overall security profile is changed, obligations apply to the product as a whole.

The guide separately explains repairs and spare parts. Replacing a defective component with an identical one does not normally transform the product into a new one. A spare part manufactured according to the same specifications can be exempted from separate application of the regulation when it is provided for the repair of an existing product.

A new component that uses different cryptographic mechanisms, different protocols, or other relevant security functions may no longer be considered identical. It must then be evaluated as a separate digital product, even if it performs approximately the same practical function.

Manufacturers must conduct a risk assessment for the entire product, including integrated components and functions processed remotely. The assessment must influence the design, development, production, delivery, and maintenance of the product.

The regulation does not impose a single assessment methodology. The company can choose the tools used, but it must be able to show the authorities how it identified risks, how it assessed them, and what measures it introduced to mitigate them.

The cost or business strategy of the company is not sufficient for accepting a risk. The manufacturer cannot leave an unresolved issue simply because fixing it is expensive or delays the product launch. The level of security must be assessed in relation to the product's purpose, foreseeable use, and the consequences of an attack.

The manufacturer must also analyze the foreseeable ways in which the product may be used differently from its instructions. A device intended for professionals may reach untrained users, and a product recommended for secure networks may be installed in a less protected environment. Foreseeable risks must either be reduced by design or clearly explained to users.

Responsibility cannot be fully transferred to the user. Instructions can help with the safe installation and use of the product, but they cannot replace the security measures that must be introduced by the manufacturer.

For components from third parties, including open-source software, the manufacturer must perform proportional checks with the risk. These may include analyzing the update history, consulting vulnerability databases, checking the support period, reviewing documentation, and conducting additional tests.

A component does not necessarily need to bear the CE marking to be integrated. The manufacturer of the final product remains responsible for ensuring that the component does not compromise the security of the whole.

The guide clarifies in detail the situation of free and open-source software. An individual developer who publishes code for free, without monetizing it and without controlling a commercial product, does not automatically become a manufacturer in the sense of the regulation.

A person who only contributes a modification or a fix to an open-source project is not responsible for the entire program if they do not control the publication, versions, and distribution. Responsibility generally lies with the person or organization that publishes and controls the project.

The fact that a project receives donations or funding for development does not automatically turn it into a commercial activity. The situation may be different if access to the program, updated versions, or security fixes is conditioned in practice on payment or donation.

A free version and a commercial one of the same project may receive different treatments. The organization may be considered a manufacturer for the monetized version and an open-source software administrator for the community version offered without commercial intent.

Companies that integrate a free open-source library into a commercial product must check the risks of the component. They do not transfer the obligations of the final product to the independent developer who published the library for free.

The support period must be established for each product and communicated to the buyer in a clear form, including by indicating the month and year when support ends. The duration must reflect the period in which the product is reasonably expected to be used.

The five-year threshold is a minimum protection, not a standard period for all products. A router, an operating system, a microprocessor, or industrial equipment used for ten years may require a longer support period.

A shorter period than five years is possible when the product is designed for a shorter lifespan. A program created for a temporary situation or a service that stops functioning after the subscription ends may fall into such a category, depending on the specific conditions.

During the support period, the manufacturer must address vulnerabilities of the product and its components. The regulation does not necessarily require a separate patch for each discovered issue. The remedy may consist of an update, disabling a function, changing configuration, or other measures proportional to the risk.

Security updates must be provided without delay and, normally, free of charge. For consumer products, automatic installation must be available when appropriate, with the user having the option to disable or postpone it.

The manufacturer must provide secure mechanisms for distributing updates and inform users. It is not responsible under the regulation if the user refuses to install an update properly made available.

If a serious vulnerability cannot be remedied, the manufacturer may resort to withdrawing or recalling the product. This situation is reserved for cases where the product cannot be brought back into compliance through updates or other appropriate measures.

The first obligations with general application for companies come into force on September 11, 2026, and concern reporting. The manufacturer must notify both the national incident response team designated as coordinator and the European Union Agency for Cybersecurity.

Reporting is mandatory for an actively exploited vulnerability when there is credible evidence that a malicious actor has used it without permission. The mere discovery of a vulnerability by a researcher or during an internal test does not automatically trigger the obligation.

A zero-day vulnerability, for which there is still no remedy, must be reported if the manufacturer has evidence that it is being exploited. If it was found within a researcher reward program and there are no signs of malicious use, the mandatory reporting is not activated.

The company is considered informed when, after an initial assessment conducted without delay, it has a reasonable degree of certainty that the vulnerability is being exploited or that the serious incident has compromised the security of the product.

The first alert must be sent without delay and within 24 hours at most. A more detailed notification must be sent within 72 hours at most. A complete report is required later, depending on the type of event and the moment when a corrective measure becomes available.

The reporting obligation also applies to products placed on the market before December 11, 2027. It continues even after the support period ends when the manufacturer learns of an active exploitation or a serious incident after the regulation comes into effect.

However, there is no obligation to retroactively report situations that the company already knew about before September 11, 2026. If a vulnerability was known, but its exploitation begins or is discovered after this date, the obligation applies.

The manufacturer must also inform affected users, in a manner proportional to the risk. Immediate publication of all technical details is not necessary when this could facilitate new attacks. After remedying the vulnerability, broader information may become appropriate.

The guidelines do not create new obligations and do not modify the text of the regulation. They express the Commission's interpretation and provide companies with examples of practical application, but the binding interpretation of European legislation can only be given by the Court of Justice of the European Union.

The Commission has approved and published the content of the guidelines in the language currently available. The formal adoption of all linguistic versions is planned later, after the completion of translations into the official languages of the Union.

"These guidelines are part of our simplification agenda and help companies to meet their obligations under the Cyber Resilience Regulation in a timely and confident manner," said the Executive Vice-President of the Commission for technological sovereignty, security, and democracy, Henna Virkkunen.

"A cyber-secure Europe and a business-friendly Europe go hand in hand: today's guidelines will help protect products on our market against cyber threats while avoiding unnecessary burdens and legal uncertainty for companies," she added.

The Cyber Resilience Regulation came into force on December 10, 2024. Its main requirements will apply from December 11, 2027, but the obligations regarding the reporting of actively exploited vulnerabilities and serious incidents will begin on September 11, 2026.

The regulation aims for digital products marketed in the EU to be designed and maintained under security conditions, and vulnerabilities to be addressed throughout the support period. Compliant products will bear the CE marking, and the verification of compliance will fall to the national market surveillance authorities.

https://2eu.brussels/ro/news/comisia-explica-ce-produse-intra-sub-noile-reguli-europene-de-securitate-cibernetica-inaintea-primelor-obligatii-din-septembrie