CRA Reporting Obligations: Can Product Teams Meet 24 Hours?

By DataTip · Published October 27, 2026

A company selling connected products in the EU can face a reporting obligation before the Cyber Resilience Act’s wider product-compliance regime applies. The practical test is not just whether security can identify an issue: product, legal and customer teams also need to understand who holds the reporting duty and what the incident may require them to communicate.

The CRA reporting obligations for actively exploited vulnerabilities and severe incidents have applied since September 11, 2026. Manufacturers must submit an initial warning within 24 hours of becoming aware of a qualifying event. Meeting that deadline depends on identifying whether the product and event are in scope, determining which company is the manufacturer, and coordinating regulatory reporting with required customer notices.

The CRA reporting obligations for actively exploited vulnerabilities and severe incidents took effect on September 11, 2026. The broader product-compliance regime is scheduled for December 11, 2027. That gap matters: a product may not yet be subject to the wider regime and still fall within the reporting rules.

Which products fall within CRA reporting obligations?

The CRA covers a broad range of software and hardware products with digital elements placed on the EU market, including separately marketed components and qualifying remote data processing solutions. Reporting began September 11, 2026; the wider product-compliance regime follows on December 11, 2027. The product’s age or where it was made does not, on its own, settle whether reporting duties apply.

Covered examples include industrial controllers, connected consumer devices, operating systems, mobile applications, network equipment and firmware. The definition also includes remote data processing solutions associated with a product. Standalone software-as-a-service is generally outside the CRA, unless the service is designed and developed by the manufacturer as remote processing the product needs in order to perform its functions.

Some categories are excluded because other EU rules govern their cybersecurity. The source identifies medical devices and in vitro diagnostics, type-approved motor vehicles, certified civil aviation equipment, marine equipment, products developed or modified exclusively for national security or defence, products designed to process classified information, and replacement spare parts made to the same specifications as the parts they replace.

If a cloud service is the product itself rather than a component of a product, the CRA may not apply; NIS2 and DORA might be relevant instead. The supplied material also flags an exception for older products but cuts off before giving its full terms. That leaves a genuine scope question to verify rather than a basis for assuming that a product’s age resolves it.

Who carries the reporting duty – and who has separate duties?

Manufacturers carry the CRA reporting duty. A manufacturer is a person or entity that develops or manufactures a product with digital elements, has it designed, developed or manufactured, and markets it under its own name or trademark. The product may be sold for payment, monetized in another way, or provided free of charge.

The product need not be created in the EU. A company outside the EU can be the manufacturer when it places a product on the EU market, including through a distributor. Manufacturers established outside the EU must designate an authorized representative in the EU.

Importers and distributors generally do not file the manufacturer’s reports. They must, however, inform the manufacturer without undue delay when they become aware of a product vulnerability. If a product presents a significant cybersecurity risk, they must immediately notify the market surveillance authorities in the Member States where they made it available.

The distinction can change. An importer or distributor that markets a product under its own name or trademark, or substantially modifies a product already on the market, becomes the manufacturer for CRA purposes and takes on the reporting duty. Private-label and white-label arrangements therefore merit close review: who appears to own the product’s market identity can determine who must report.

Open-source software stewards have a lighter, separate regime. The European Commission’s stated position is that their reporting obligations begin on December 11, 2027, not September 2026.

Which events trigger CRA reporting?

The source identifies two reporting triggers: an actively exploited vulnerability and a severe incident affecting product security. Not every discovered flaw qualifies. For the vulnerability trigger, there must be reliable evidence that a malicious actor exploited the vulnerability in a system without its owner’s permission; good-faith security testing and coordinated disclosure without malicious intent do not trigger that duty.

AI GENERATED

The supplied material describes a severe incident as one that negatively affects, or could negatively affect, a product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. It also identifies incidents that have led, or could lead, to malicious code being introduced or executed in the product or a user’s network and information systems. The source excerpt does not provide a complete treatment of the definition, so do not infer additional criteria from it.

A qualifying incident need not have harmed a customer directly. The source says a compromise of a manufacturer’s development, production or maintenance environment can count if it could raise cybersecurity risk for users – for example, malicious code injected into a build pipeline or security-update channel. Potential impact can be enough. A team that screens only for the unauthorized acquisition of data associated with many US breach-notification standards could miss this broader CRA trigger.

Can teams coordinate the 24-hour reporting clock?

The early warning is due within 24 hours of becoming aware of a qualifying vulnerability or severe incident. That deadline makes role clarity a business capability: product and security teams need to distinguish a reportable event from routine testing or disclosure, while legal and customer teams must understand that a regulatory report and user notice may both be required.

AI GENERATED

The 24-hour warning is not the only filing. The source describes a follow-up within 72 hours for both categories, even if the initial warning was detailed. For actively exploited vulnerabilities, the final report is due within 14 days after a corrective or mitigating measure becomes available. For severe incidents, it is due within one month of the 72-hour notification. Reports go through ENISA’s CRA Single Reporting Platform to ENISA and the CSIRT coordinating for the Member State of the manufacturer’s main EU establishment. The source’s account of the CRA reporting requirements provides the stated deadlines and recipients.

Customer communication is another handoff, not an afterthought. After becoming aware of a qualifying event, the manufacturer must inform impacted users and, where appropriate, all users about the issue and any necessary risk mitigation or corrective measures users can take. Where appropriate, this information must be machine-readable and easily processable automatically.

That obligation may not align neatly with existing customer agreements, confidentiality provisions or other disclosure requirements. Public companies should also consider how CRA customer notices may interact with SEC Item 1.05. The practical question for leaders is whether the teams responsible for product facts, legal assessment and customer communication can reach compatible decisions under the same short deadline – without treating every vulnerability report as a CRA trigger or waiting for customer harm before assessing one.

Key takeaways

• Separate the September 2026 reporting duties from the broader product-compliance regime scheduled for December 2027.
• Confirm which entity markets each product under its own name or trademark; rebranding or substantial modification can make an importer or distributor the manufacturer.
• Do not treat every vulnerability disclosure as reportable: the vulnerability trigger requires reliable evidence of malicious exploitation without the system owner’s permission.
• Assess possible product-security impact, including compromise of development or update environments; customer harm is not required by the supplied source.
• Account for the 72-hour filing and later final report as well as the 24-hour warning, and consider customer notices in parallel.

Practical tips

• Review private-label and white-label product arrangements to confirm which entity has the manufacturer role.
• Check whether existing customer and confidentiality terms accommodate CRA user notices, including machine-readable notices where appropriate.
• Make sure teams distinguish good-faith security testing and coordinated disclosure from evidence of malicious exploitation.