With the Cyber Resilience Act (Regulation (EU) 2024/2847, hereinafter CRA), the Union legislator has established horizontal and binding cybersecurity requirements for products with digital elements, thereby subjecting a field previously shaped primarily by voluntary standards to a uniform legal framework. The CRA entered into force on 10 December 2024 but phases in its obligations for manufacturers, importers, and distributors over time, reaching full applicability only on 11 December 2027.

By contrast, one central set of obligations has been brought forward: from 11 September 2026, the reporting obligations under Art. 14 CRA for actively exploited vulnerabilities and severe security incidents will apply. Companies therefore face the question of whether they even qualify as manufacturers subject to reporting – and if so, what exactly must be reported and how.

I. Who Is Affected by the New Reporting Obligations?

The reporting obligations under Art. 14 CRA apply exclusively to manufacturers. Importers and distributors are subject to their own inspection, monitoring, and cooperation obligations but are not addressees of the reporting and early-warning duties. The threshold question is therefore whether a company is to be regarded as a manufacturer within the meaning of the CRA for a given offering, and whether that offering constitutes a product with digital elements falling within the scope of the Regulation.

The manufacturer concept follows a functional approach. A manufacturer is any person who makes available a product with digital elements under its own name or trademark in the course of a commercial activity (Art. 3 No. 13 CRA). This captures not only classic hardware producers but also pure software providers. Of further practical significance is the fact that importers and distributors who market a product under their own name or trademark, or who substantially modify a product already placed on the market, are themselves deemed manufacturers under Art. 21 CRA and are thus also subject to the reporting obligations. A company’s self-classification as a mere reseller does not shield it from the manufacturer role (as we reported in Data Protection Update No. 243).

The decisive factor for whether an entity is affected is then the concept of a product with digital elements. Under Art. 3 No. 1 CRA, this is a software or hardware product, including its remote data processing solutions, provided that the intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network. The scope is therefore broad, ranging from embedded software in connected devices through standalone software to standalone hardware. The guidance of the European Commission on the application of the CRA (Communication C(2026) 5252), published on 27 July 2026, elaborates on the scope in numerous places and provides an essential orientation aid for case-by-case classification—though it is not legally binding.

Typically affected are, first of all, manufacturers of connected hardware. These include providers of IoT and smart-home devices such as connected thermostats, cameras, or household appliances, as well as producers in mechanical and plant engineering whose products contain connected controllers or communication modules. Industrial control systems, network components such as routers, and the associated embedded software also regularly fall within the scope. The CRA does not depend on the mere presence of electronics but on the product’s ability to exchange digitally communicated data. A product whose electrical signals merely trigger a function or supply power without transmitting digitally encoded information does not, on its own, establish a data connection.

Standalone software is likewise captured. The Commission’s guidance highlights a practically important distinguishing criterion: software falls within the scope if it is made available to the user and executed on the user’s information system. This is the case, for example, for an application downloaded from an app store and installed on the end device, or for a locally installed desktop application, even if it was developed using web technologies. By contrast, software that is exclusively executed remotely and merely accessed by the user via a browser is, according to the guidance, not in itself a product with digital elements. This concerns in particular pure web and SaaS applications as well as websites that merely provide information. Such offerings fall within the scope only if they support the function of a product with digital elements and are thus to be classified as a remote data processing solution.

An underestimated use case concerns products consisting of hardware and separately provided software. According to the Commission’s guidance, hardware and software form a single product with digital elements if the software is required for the intended function of the hardware – even if it is obtained through a separate channel such as an app or a download. A connected printer with the drivers required for its operation, or a fitness wearable that only fulfils its function with the associated smartphone application, are therefore each to be regarded as a single product. For manufacturers of such combinations, this means that the reporting obligation extends to the interplay of the device and its accompanying software.

Special rules apply to free and open-source software (Free and Open-Source Software, FOSS) under Recitals 15, 18, and 19 of the CRA and the Commission’s guidance. The mere publication of such software does not in itself constitute placing on the market. FOSS is captured only if it is made available in the course of a commercial activity – for example, for a fee, through monetization of other services via the software, or through access conditioned on a donation.

By contrast, products that are already subject to certain other sectoral Union regulations with a cybersecurity dimension are entirely excluded. Under Art. 2(2) CRA, the Regulation does not apply, in particular, to products governed by the rules on motor vehicles (Regulation (EU) 2019/2144) or certain vehicle categories (Regulation (EU) No. 168/2013). According to the Commission’s guidance, this extends to components intended exclusively for installation in such vehicles, whereas generic parts that are also offered outside the supply chain through generally accessible distribution channels remain subject to the CRA. For further product groups such as medical devices, separate sectoral regimes exist that require an independent assessment.

Finally, the temporal scope of the reporting obligation reaches further than the date of full applicability might suggest. Under Art. 69(3) CRA, the obligation of Art. 14 CRA extends to all products with digital elements falling within the scope that were made available on the Union market before 11 December 2027. For the reporting obligation, what matters is the existing stock in the market, regardless of whether the product in question will ever be subject to the product requirements applicable from December 2027 or to CE marking.

II. Reporting Procedure Under Art. 14 CRA

Art. 14 CRA obliges manufacturers to report two types of events: actively exploited vulnerabilities contained in a product with digital elements (Art. 14(1) CRA) and severe security incidents that affect the security of such a product (Art. 14(3) CRA). An incident is deemed severe under Art. 14(5) CRA if it negatively affects or may affect the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or if it has led or may lead to the introduction or execution of malicious code. Both trigger criteria are narrower than they first appear, since not every known vulnerability is captured but only its actual active exploitation.

Reporting takes place in stages. Under Art. 14(2) and (4) CRA, an early warning must first be issued within 24 hours of becoming aware of the event; within 72 hours a vulnerability or incident notification follows, providing further details on the nature, impact, and measures taken. The final report must be submitted no later than 14 days after the availability of a corrective or risk-mitigation measure in the case of actively exploited vulnerabilities, or within one month after the 72-hour notification in the case of severe security incidents.

The commencement of the time limit depends on when awareness is gained. According to the Commission’s guidance, awareness does not arise as early as the first suspicion but only when the manufacturer, following an initial assessment, can assume with sufficient certainty that active exploitation or an impairment of product security exists. At the same time, the guidance emphasizes that this assessment must be carried out promptly and that the commencement of the time limit must not be deferred by a delayed examination.

The addressees are two bodies simultaneously: the CSIRT designated as coordinator and ENISA (Art. 14(1) and (3) CRA). Submission is made via the single reporting platform established under Art. 16 CRA, which is operated by ENISA. The platform is currently still in its testing phase and is scheduled to be operational by 11 September 2026. The locally competent CSIRT is determined under Art. 14(7) CRA generally by reference to the manufacturer’s main establishment, i.e., the Member State in which cybersecurity decisions regarding the products are predominantly made. The formal designation of CSIRTs by the Member States is still pending. In Germany, CERT-Bund, which is housed at the BSI, is expected to assume this role. For manufacturers without an establishment in the Union, a tiered fall-back connecting factor applies. The identification of the competent CSIRT and prior registration on the platform should be clarified early, since a report within 24 hours is otherwise practically unachievable.

In addition, Art. 14(8) CRA establishes a separate obligation to inform the affected users – and, where appropriate, all users—about the vulnerability or incident as well as possible remedial measures. According to the Commission’s guidance, this information is to be handled on a risk-based approach and does not necessarily require public disclosure, since premature disclosure of technical details may increase risk particularly in sensitive deployment environments. If the manufacturer fails to fulfil its information obligation in time, the CSIRTs may themselves inform the users.

The detailed modalities of official further dissemination are governed by Delegated Regulation (EU) 2026/881. It specifies the conditions under which the initially involved CSIRT may temporarily defer dissemination of a notification to the other competent CSIRTs – for example, where a patch is to be provided at short notice or a coordinated disclosure procedure is still ongoing. Finally, it should be noted that a notification under Art. 14 CRA does not replace other reporting obligations. Since the same root cause may simultaneously trigger obligations under the NIS 2 Directive or under Art. 33 GDPR, the respective connecting factors should be clarified in advance.

III. Recommendations for Manufacturers

• Determine manufacturer role and product inventory: As a first step, it should be documented for each product whether the company is a manufacturer within the meaning of the CRA for that product, including in cases of own-brand distribution or substantial modification under Art. 21 CRA. Since the reporting obligation under Art. 69(3) CRA extends to the market stock made available before 11 December 2027, this must include not only the current portfolio but also legacy products still in the market. The basis for this is a Software Bill of Materials (SBOM) for each product, without which it cannot be reliably assessed whether a publicly disclosed vulnerability affects one’s own product.
• Identify the competent CSIRT and set up platform access: Based on the main establishment under Art. 14(7) CRA, the CSIRT designated as coordinator must be identified, and access to the single reporting platform must be set up and tested in advance. Those who begin registration only when an event occurs will regularly be unable to meet the 24-hour deadline.
• Establish the internal decision chain before an emergency: For the 24-hour deadline, the internal assessment and approval chain is the critical factor. It must be determined in particular who triages incoming reports and performs the initial assessment relevant to the commencement of the time limit, by what criteria active exploitation or a severe incident within the meaning of Art. 14(5) CRA is affirmed, and who authorizes the notification. Since actively exploited vulnerabilities and incidents are not bound to business hours, this chain must be reachable and capable of making decisions outside regular working hours.
• Clarify interfaces with other reporting obligations and the supply chain: Since the same root cause may simultaneously trigger reporting obligations under the NIS 2 Directive or under Art. 33 GDPR, these procedures should be coordinated with the CRA notification, and the respective applicable deadlines and addressees should be allocated in advance. In addition, supply agreements should include information and notification obligations regarding vulnerabilities in supplied components, so that the manufacturer can meet the Art. 14 CRA notification and the reporting obligations to the component manufacturer under Art. 13(6) CRA within the prescribed time limits.

IV. Conclusion and Outlook

With the reporting obligations of Art. 14 CRA, the first set of CRA obligations takes effect on 11 September 2026 – well before the Regulation becomes fully applicable. For manufacturers, the real challenge lies less in the technical detection of vulnerabilities and incidents than in organization. The short 24-hour early-warning deadline can only be met if the manufacturer role, product inventory, competent CSIRT, platform access, and internal decision-making pathways have been clarified in advance. Since the obligation under Art. 69(3) CRA also covers existing stock already in the market, this applies not only to future products but also to products already placed on the market.

At the same time, the legal landscape remains in flux. The Commission’s guidance of 27 July 2026 clarifies key interpretive questions but is not legally binding and does not preclude further clarification through additional guidance, harmonized standards, and the practice of market surveillance authorities. Reporting and response processes should therefore not be implemented in isolation but embedded from the outset in CRA compliance as a whole.

This article was created in collaboration with our student employee Emily Bernklau.