The EU’s new Cyber Resilience Act (CRA) sets out a comprehensive framework of cybersecurity requirements for products with digital elements. While most of its provisions will apply starting December 11, 2027, certain obligations—most notably, reporting duties for manufacturers—will kick in earlier, on September 11, 2026.
In a previous blog post, we offered an overview of the CRA and its broader context. In this article, we’re narrowing the focus to a key actor in the CRA’s ecosystem: the manufacturer. We’ll explore what qualifies someone as a manufacturer under the regulation, and what responsibilities that role carries under the new law.
Am I a manufacturer?
Manufacturers are defined in Article 3‘s 13th definition:
‘manufacturer’ means a natural or legal person who develops or manufactures products with digital elements or has
products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge
Manufacturer is the main role responsible for compliance with the CRA. In the case of products being designed and manufactured outside of the EU, the obligations of the manufacturer will fall onto the importer.
If you’re making a device and selling it, you’re a manufacturer. If you were only making a component of it, say the SoC that is then integrated in a device, you would not be the manufacturer of the end device, but because you would be selling this SoC to the device’s manufacturer, you would be the manufacturer for the SoC. In that capacity, you hold a responsibility in regard to the CRA, and the end device manufacturer will rely on you to provide them with your technical documentation, including the EU declaration of conformity.
Are you developing a closed-source Android or iOS app? To the CRA, you’re a manufacturer! You will be responsible for ensuring that your app does not contain any vulnerabilities, and this extends to your dependencies. Among other things, you will have to review the libraries your app is using and their versions, and make sure that they do not have any known vulnerabilities.
Now that you should have an idea whether you’re a manufacturer in the eyes of the CRA, let’s dive into the obligations that come with that.
Reporting obligations
These obligations come first because they will be the first to apply, in September 2026. Manufacturers have different reporting obligations to different parties, all described in Article 14:
- the central reporting platform of ENISA, the EU cybersecurity agency must be notified of any vulnerabilities known to be exploited in the product. As mentioned in the first blog post in this series, ENISA will rely on the CSIRTs network to achieve that. And since our previous blog post, the French CSIRT has now set up an online form. After this, the CSIRT should synchronize with ENISA.
- impacted users (or all users by default) must be notified of severe incidents impacting the product’s security
Additionally, manufacturers have the obligation to report vulnerabilities they identify in a component of their product to the manufacturer of the component, or the maintainer in the case of an open-source project.
Initial obligations
These obligations are relevant to manufacturers from the very beginning of the product’s lifecycle. Indeed, they will apply as soon as the product hits the EU market, and some will be much easier to comply with if taken into account at the start.
Cybersecurity risk assessment
This is the task that will come first in the list of manufacturer obligations, as it is intended to inform the entire lifecycle of the product, including planning and design. Its aim is to catalogue:
- the intended use and conditions of use of the product
- the cybersecurity risks that apply to the product in this use
- actions put in place to mitigate those risks or their consequences
This should include threat modelling for the product, and will greatly benefit from accumulating evidence of actions put in place as they are introduced.
EU declaration of conformity & CE marking
The declaration of conformity is documented in Annex V, the simplified version is documented in Annex VI.
Manufacturers will need to write a declaration of conformity for their product before it enters the market. This declaration aims to track the conformity of the product, and information about its manufacturer.
The rules for the CE marking are described in Articles 29 and 30.
Neither is specific to the CRA, the only change here is the scope of the products to which this obligation applies, and how to handle details specific to products with digital elements.
User information and instructions
This is documented in Annex II. The main takeaways here are, that manufacturers need to inform the users of:
- Their vulnerability handling policy, including where to report issues
- The product’s intended security environment, and its security properties
- The product’s security support, including updates
- Detailed instructions for the secure commission, usage and decommission of the product
Technical documentation
The technical documentation that manufacturers must include is regulated in Article 31, and its minimal components are described in Annex VII.
- the user information and instruction above
- the cybersecurity risk assessment described previously
- the support period and what was considered in establishing it
- if harmonised standards were applied, their list and which parts were applied if they were not fully applied.
- the EU declaration of conformity
- the Software Bill Of Materials (SBOM)
Continuous obligations
These obligations apply during the support period (details below), which is to say during the lifetime of the product, not to be confused with the time span that it is being produced.
Most of them involve a continuous effort to ensure compliance, in the form of documentation, updates and support to users.
Identification
The product must be identifiable, using e.g. a serial or batch number. In the case of software, that would be the software’s version.
The support period
The support period is introduced in the CRA’s Article 13, paragraph 8. Determining it is left to the manufacturer by taking into account how long the product is supposed to last, as well sa how long similar products are supported, and how long core components of the product are expected to remain available.
The minimum duration of the support period is expected to be 5 years, unless the product is expected to be used for less than that.
The support period is important because it is the minimal duration that manufacturers are expected to fulfill several continuous obligations.
Elements considered in determining the support period must be documented in the technical documentation.
It must be specified at time of purchase, and a notification to users must be displayed that the end of it is reached where possible.
For the duration of the support period, the following is expected of manufacturers:
- updating the cybersecurity risk assessment
- updating the declaration of conformity (available min. 10 years)
- updating the technical documentation (available min. 10 years)
- vulnerability handling, see Annex I part II
- availability of security updates (min. 10 years)
- information and instructions to the user (available min. 10 years)
Integration of components
The regulation is slightly vague regarding integrating components into a product, calling for “exercising due diligence”. This includes open source software as components.
If the component meets the definition of a product being placed on the market, the user information must include documentation for the integrator to help comply with the CRA’s cybersecurity requirements.
The CRA also reinforces the duty of the manufacturer to report issues found in those components to their manufacturer.
The CRA makes a big exception to its regulatory regime for Open-Source software. The key criterion here is monetization. Publishing Open-Source software is not considered placing a product on the market unless it is being monetized, meaning the publisher/maintainer is not subject to a manufacturer’s obligations. That also goes even if that component is being integrated into commercial products, and even if the manufacturers of those products support and/or contribute to the development (including by providing hosting or infrastructure).
The maintainer of the software would instead fall under a different, much lighter regulatory regime: that of Open-Source steward, which we’ll discuss in a later blog post.
Because the obligations of this regime are more lax, those components cannot bear the CE marking.
It should be noted, however, that manufacturers integrating those components will still have to meet their obligations to the CRA, even regarding these Open-Source components, e.g. by reporting vulnerabilities to the maintainers.
Final obligations
These obligations are relevant to manufacturers that are ceasing their operations. The paragraph detailing them is short:
23. A manufacturer that ceases its operations and, as a result, is not able to comply with this Regulation shall inform, before the cessation of operations takes effect, the relevant market surveillance authorities as well as, by any means available and to the extent possible, the users of the relevant products with digital elements placed on the market, of the impending cessation of operations.
Conclusion
Overall, the CRA is raising the floor for what is considered due diligence in the context of cybersecurity, and spelling out some expectations of manufacturers putting a product onto the market.
It strongly reinforces the need for manufacturers to documents technical decisions taken in regards to cybersecurity risks, and to make the documentation available to the public.
It also establishes a clear expectation of security support for a multi-year period, so that it is no longer possible to release a product without caring about it lifecycle.