CRA reporting obligations for electronics manufacturers

In traditional EU product harmonisation legislation such as RED, LVD or EMC Directive, post-market obligations exist (cooperation with market surveillance authorities, complaint handling, corrective action when non-conformities are identified), but they are largely reactive. You respond when something is requested or when a problem becomes apparent.

CRA reporting changes this. Article 14 requires active, time-bound notification to EU authorities when specific security events are detected, not after a market surveillance authority requests information, but proactively, within 24 hours. For manufacturers in the electronics sector, this is structurally different from anything the existing regulatory framework demands.

There is another important distinction. The reporting obligation also applies to products already placed on the EU market, including products shipped before the CRA becomes fully applicable. A connected product that has been in service for years is covered by the reporting obligation from 11 September 2026, provided it falls within the scope of the regulation. The implications of this for manufacturers with an active product portfolio are significant, and are covered in detail further in this article.

Article 14 establishes two separate categories of reportable events. Each has its own definition, its own trigger, and its own reporting timeline. Understanding the distinction is important, because the deadlines and the content of each notification are different.

The CRA defines an actively exploited vulnerability as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (Article 3(42)). The key word is *reliable evidence of malicious exploitation*. The mere existence of a vulnerability does not trigger the obligation.

What does trigger the obligation: a customer reports that an attacker gained unauthorized access through a known weakness in your product's firmware. A security researcher publishes evidence that a vulnerability in your product's communication stack is being exploited in the field. A governmental cybersecurity agency notifies you that a vulnerability in a component your product uses has been exploited in attacks targeting deployed units.

Equally important is what does *not* trigger it. Vulnerabilities discovered through authorised activities such as penetration testing, bug bounty programmes, security assessments commissioned by the manufacturer; these are not actively exploited vulnerabilities, provided there is no evidence of prior malicious exploitation. A zero-day vulnerability discovered by an ethical hacker, for which there is no evidence of exploitation by a malicious actor, is not subject to mandatory reporting. Nevertheless, the manufacturer can still report it voluntarily under Article 15 of the CRA.

The second category covers incidents that have a severe impact on the security of the product with digital elements. Article 14(5) defines the severity threshold: an incident qualifies if it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. It also qualifies if it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user.

For electronics manufacturers, this could include scenarios such as evidence that a compromised over-the-air update mechanism has delivered unauthorized firmware to deployed units, detection of data exfiltration through a product vulnerability, or confirmation that malicious code has been injected into products through a supply chain compromise affecting a firmware component.

The reporting deadlines begin when the manufacturer becomes aware that a vulnerability is being actively exploited or that a severe incident has occurred. The CRA does not prescribe how a manufacturer should become aware. What matters is the moment when the manufacturer has sufficient evidence to determine that the event qualifies as reportable.

The CRA Commission guidance recognises that this determination may not always be immediate. In some cases, it will be clear from the outset. In others, it may take time to establish whether a vulnerability is being actively exploited or whether an incident meets the severity threshold. The emphasis, however, is on prompt action to carry out the initial assessment, particularly where the vulnerability may pose a significant risk.

The practical implication is that manufacturers need an internal process capable of receiving, triaging, and escalating security events quickly enough to meet the 24-hour early warning deadline. This is not something that can be improvised when an event occurs.

Both categories of reportable events follow a three-stage notification structure. The manufacturer submits progressively more detailed information as the internal investigation advances. All notifications are submitted through ENISA's Single Reporting Platform (covered in a separate section below).

This is where CRA reporting becomes particularly relevant for hardware manufacturers, and where the practical challenges differ most from those faced by pure software companies.

Most connected electronic products contain firmware and software components from multiple sources. The wireless module comes with the chipset vendor's protocol stack. The embedded operating system may be a commercial RTOS or a Linux-based distribution maintained by a third party. Communication libraries, cryptographic implementations, bootloaders, companion applications. The software supply chain in a typical connected hardware product involves components the manufacturer did not develop and often does not have the ability to modify directly.

Under the CRA, the manufacturer who places the product on the EU market is responsible for reporting actively exploited vulnerabilities contained in the product, regardless of where those vulnerabilities originate. If a vulnerability in a third-party Wi-Fi module's firmware is being actively exploited in your product, you are required to report it.

The CRA Commission guidance draws a clear boundary on this point. The obligation applies to actively exploited vulnerabilities *contained in your product*. If a third-party component has a known vulnerability, but that vulnerability either cannot be exploited in your product (because the vulnerable code is not reachable in your implementation) or has not been exploited in your product, it does not qualify as an actively exploited vulnerability in your product. In that case, mandatory reporting under Article 14 is not triggered. You can still report voluntarily under Article 15, and you are required under Article 13(6) to inform the component manufacturer about the vulnerability.

The practical challenge is obvious: to determine whether a vulnerability in a third-party component is reachable and exploitable in your product, you need visibility into what your product contains. You need to know which firmware version your wireless module runs, which libraries your RTOS includes, which open-source components are embedded in your bootloader. This is the direct link between the reporting obligation and the *SBOM* requirement that formally applies from December 2027. Manufacturers who build their software bill of materials now will be better positioned to triage third-party vulnerability disclosures against the 24-hour reporting clock when they need to.

There is also a separate obligation that operates in the other direction. Under Article 13(6), when a manufacturer identifies a vulnerability in a component integrated in its product, including open-source components, it must report that vulnerability to the person or entity manufacturing or maintaining the component. This upstream reporting obligation exists independently of the Article 14 notification to authorities.

A compliance gap assessment can map your product's regulatory exposure under the CRA.

Article 69(3) of the CRA makes the reporting obligations applicable from 11 September 2026 to all products with digital elements within scope that have been placed on the EU market before 11 December 2027, the date when the full CRA requirements become applicable. This means that the reporting obligation is not limited to new products designed and manufactured under the CRA framework. It extends to your existing product portfolio available in the EU market.

There is no retroactive reporting. If you were aware of both a vulnerability and its active exploitation before 11 September 2026, that specific event does not require notification. However, if you knew of a vulnerability before that date but active exploitation occurs after 11 September 2026, the reporting obligation applies.

One provision deserves particular attention: the reporting obligation continues even after the product's support period has ended. The vulnerability handling obligations under Annex I Part II of the CRA (which require ongoing vulnerability monitoring, remediation, and security updates) only apply for the duration of the product's support period. But the obligation to report an actively exploited vulnerability or severe incident persists beyond that. A manufacturer who has officially ended support for a product is still required to notify authorities if an actively exploited vulnerability in that product comes to its attention.

All notifications under Article 14 are submitted through the Single Reporting Platform (SRP), an electronic system established and operated by ENISA under Article 16 of the CRA. The platform consolidates what would otherwise require separate notifications to multiple national authorities into a single submission.

The process works as follows: the manufacturer logs in, selects the designated CSIRT (Computer Security Incident Response Team) to which the notification is directed, completes the required information, and submits. The platform then automatically routes the notification to the CSIRT designated as coordinator, to the CSIRTs in other EU Member States where the affected product has been made available, and to ENISA.

The coordinating CSIRT is determined primarily by the manufacturer's main place of establishment. For manufacturers established outside the EU, the CSIRT is determined by the establishment of their authorised representative.

National CSIRTs also share certain information with their respective market surveillance authorities to support enforcement. The manufacturer can indicate the sensitivity of the notified information, and under exceptional circumstances, dissemination can be delayed in accordance with Article 16(2) and Commission Delegated Regulation (EU) 2026/881.

The practical recommendation is to register in the platform before a reportable event occurs. Registration uses an EU Login account, which can be created in advance. Waiting until a vulnerability is actively exploited to discover how the platform works is not a position any manufacturer wants to be in.

The reporting obligation to authorities through the SRP is not the only notification requirement. Article 14(8) of the CRA requires manufacturers, after becoming aware of an actively exploited vulnerability or a severe incident, to inform impacted users and, where appropriate, all users of the product.

The CRA Commission guidance clarifies that this is a risk-based and proportionate obligation. It does not require public disclosure. For products used in sensitive or essential environments, disclosing technical details publicly could itself increase cybersecurity risks or facilitate further exploitation. Manufacturers may limit detailed information to the relevant users or customers concerned.

Once the vulnerability has been adequately addressed or mitigated, broader disclosure may be appropriate, particularly where it helps users verify that they have applied the necessary security update or corrective measure.

If a manufacturer fails to inform users in a timely manner, the CSIRTs that received the notification may provide the information to users directly, when this is considered proportionate and necessary.

Article 64(2) of the CRA classifies non-compliance with Article 14 at the highest penalty tier: administrative fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. This is the same tier that applies to non-compliance with the essential cybersecurity requirements.

There is one important exception for smaller companies. Micro and small enterprises are explicitly exempt from administrative fines for failing to meet the 24-hour early warning deadline. This exemption covers the first notification stage only, not the 72-hour notification, the final report, or any other reporting obligation. The rationale recognises that very small manufacturers may not have the internal capacity to submit within 24 hours, but the expectation is that they will still report within the subsequent deadlines.

It is also worth noting that the CRA does not penalise reasonable over-reporting. If a manufacturer is uncertain whether a vulnerability is being actively exploited, filing the early warning is the safer course. The notification can be downgraded or closed later as the investigation progresses.

Beyond the administrative fines, there is a secondary consideration. The Product Liability Directive (Directive (EU) 2024/2853) establishes that manufacturers can be held liable for damage caused by defective products, including products with digital elements. A vulnerability that the manufacturer was aware of but did not report or address could become relevant in a product liability context if a user suffers damage as a consequence. The two regulations operate independently, but the practical interaction reinforces the case for timely reporting and remediation.

The reporting obligation is the first concrete deadline in a wider CRA timeline. For manufacturers planning their compliance strategy, the full picture looks like this:

Already in force (since 11 September 2026): vulnerability and incident reporting through the Single Reporting Platform. Applies to all in-scope products already on the EU market.

From 11 December 2027: the full CRA becomes applicable. Cybersecurity by design, vulnerability handling processes throughout the support period, SBOM in a machine-readable format, cybersecurity risk assessment, technical documentation, conformity assessment, EU Declaration of Conformity, and CE marking for cybersecurity.

For manufacturers already working toward compliance with the RED cybersecurity requirements under Article 3.3, there is substantial overlap. The EN 18031 standard series, originally developed for the RED delegated acts on Articles 3.3(d), (e), and (f), forms the starting point for the CRA horizontal standards being developed by CEN-CENELEC and ETSI. Manufacturers who have already invested in RED 3.3 compliance will find that much of that work carries forward into CRA conformity assessment.

The reporting obligation should be seen as the entry point rather than a standalone task. Building the internal processes for detection, triage, and reporting now establishes the foundation for the broader vulnerability handling obligations that apply from December 2027.

A compliance gap assessment identifies where your product stands against all applicable EU Directives, not only CRA requirements.

For ongoing regulatory support across the CRA timeline, explore the External Compliance Manager