CRA Reporting Obligations: Product Scope and Roles

By DataTip · Published November 2, 2026

TL;DR: The CRA reporting duty generally falls on the manufacturer of a covered product with digital elements placed on the EU market. Covered products can include software, hardware, separately marketed components, and qualifying remote data processing solutions, subject to listed exclusions. Reporting triggers are actively exploited vulnerabilities and severe incidents that affect or could affect product security.

Assess products placed on the EU market, including separately marketed software or hardware components; EU manufacture is not required.
Do not assume standalone SaaS is covered: the remote-processing test depends on who designed and developed it and whether the product can function without it.
Check who markets a product under its own name or trademark; an importer or distributor can become the manufacturer under that condition or after substantial modification.
Treat potential product-security impact as relevant even when there is no confirmed customer harm.

If your company sells software or connected hardware in the EU, the first CRA question is not whether the broader product-compliance regime is ready. It is whether a product and your role put you within the Cyber Resilience Act’s reporting scope. CRA reporting obligations for actively exploited vulnerabilities and severe incidents took effect on September 11, 2026, ahead of the broader regime, which does not apply until December 11, 2027. The source analysis describes the reporting duties and their scope in Fisher Phillips’ CRA overview.

The CRA reporting duty generally falls on the manufacturer of a covered product with digital elements placed on the EU market. Covered products can include software, hardware, separately marketed components, and qualifying remote data processing solutions, subject to listed exclusions. Reporting triggers are actively exploited vulnerabilities and severe incidents that affect or could affect product security.

That timing makes portfolio boundaries important now. The rules do not automatically cover every company that sells software or hardware in Europe; product type, the business role attached to it, and the nature of an event all matter. A product’s age alone does not settle the question either: the source says reporting requirements may apply to products sold years ago.

Which products may fall within CRA reporting obligations?

The CRA covers products with digital elements placed on the EU market. That category includes software and hardware, qualifying remote data processing solutions, and software or hardware components placed on the market separately. The relevant connection is the product’s availability on the EU market, not where it was developed or manufactured.

The range is broad. Examples include industrial controllers, connected consumer devices, operating systems, mobile applications, network equipment, and firmware. A separately marketed component may therefore warrant attention even if it is not sold as a finished consumer product.

The source lists several exclusions, including categories governed by other EU regimes or specific-purpose exceptions:

Medical devices and in vitro diagnostics
Type-approved motor vehicles, certified civil aviation equipment, and marine equipment
Products developed or modified exclusively for national security or defence purposes
Products designed to process classified information
Spare parts manufactured to the same specifications as the parts they replace
These exclusions should be applied to the relevant product category and conditions, not treated as a general exemption for a company or portfolio. If a business also sells products outside an excluded category, those products still need their own scope assessment.

When does cloud software count as part of a product?

Standalone software-as-a-service is generally outside the CRA. The boundary changes when a service functions as a remote data processing solution: the manufacturer must design and develop the remote processing, and the product must be unable to perform its functions without it.

That distinction separates a cloud service that is part of a covered product from a cloud service that is itself the offering. The source says the latter likely falls outside the CRA, though NIS2 or DORA might be relevant. It does not suggest that every cloud service is covered – or that all SaaS is excluded.

Which business roles carry the reporting obligation?

Manufacturers carry the CRA reporting duty. A manufacturer is a person or entity that develops or manufactures a product with digital elements – or has it designed, developed, or manufactured – and markets it under its own name or trademark. The definition includes products offered for payment, monetisation, or free of charge.

Gloved hands assemble a smooth, unmarked wearable band at a clean production bench.

The product need not be made in the EU. A company established elsewhere can be a manufacturer when it places its product on the EU market; the source gives the example of a US company selling through a distributor. Manufacturers established outside the EU must also designate an authorised representative in the EU.

Importers and distributors generally do not submit the reports themselves, but they have separate duties. They must 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 inform the market surveillance authorities in the Member States where they made it available.

The role can change. An importer or distributor becomes the manufacturer for CRA purposes if it markets the product under its own name or trademark, or substantially modifies a product already on the market. Private-label and white-label arrangements deserve particular scrutiny because branding can affect who carries the reporting duty.

Open-source software stewards have a separate, lighter regime. The source attributes to the European Commission the position that steward reporting obligations begin on December 11, 2027, rather than September 2026. That timing is distinct from the reporting duties that already apply to manufacturers.

What events trigger CRA reporting?

The source identifies two triggers: an actively exploited vulnerability and a severe incident affecting – or capable of affecting – the product’s security. These are event-based thresholds. A product’s presence in the EU market does not, by itself, mean a report is due.

A damaged fiber-optic connection hangs loose beside a server cabinet’s breached seal.

An actively exploited vulnerability requires reliable evidence that a malicious actor exploited the vulnerability in a system without the system owner’s permission. Good-faith security testing and coordinated disclosure without malicious intent do not trigger the duty described in the source.

A severe incident is broader than a confirmed customer breach. It includes an event that negatively affects, or could negatively affect, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of data or functions. It also covers an incident that has led, or could lead, to malicious code being introduced or executed in the product or in a user’s network and information systems.

That capability threshold matters. A compromise of a company’s own development, production, or maintenance environment may qualify if it could increase cybersecurity risk for users. The source’s examples include malicious code injected into a build pipeline or a security-update channel. Actual customer harm is not required under the threshold described; the possibility of a negative effect on product security can be enough.

This is why a team that screens incidents only against a US breach-notification standard – often focused on unauthorised acquisition of data – could miss a CRA reporting trigger. The question is not only whether customer data was taken. It is whether one of the defined events has occurred and could affect product security.

What does the earlier reporting deadline mean for product scope?

The reporting duties took effect on September 11, 2026, while the broader CRA product-compliance regime does not apply until December 11, 2027. The earlier reporting obligation is a separate timing issue: businesses should not assume that preparation for the later regime answers whether a current vulnerability or severe incident must be reported now.

Nor does the product’s age settle the issue. The source warns that products sold years ago may still be within the reporting scope, while also noting an exception for older products without providing its full terms in the supplied material. It would be unsafe to treat every legacy product as covered – or to assume older products are automatically exempt.

For each relevant product, the practical scope decision turns on three questions: does it meet the CRA’s product definition and lack an applicable exclusion; which business entity markets it under its name or trademark; and could an event meet either reporting trigger? That is a narrower question than general CRA readiness, but it determines where immediate reporting responsibility may sit.

Key takeaways

Assess products placed on the EU market, including separately marketed software or hardware components; EU manufacture is not required.
Do not assume standalone SaaS is covered: the remote-processing test depends on who designed and developed it and whether the product can function without it.
Check who markets a product under its own name or trademark; an importer or distributor can become the manufacturer under that condition or after substantial modification.
Treat potential product-security impact as relevant even when there is no confirmed customer harm.

Practical tips

When reviewing a product catalogue, distinguish finished products from components placed on the market separately.
For cloud-linked products, document whether the manufacturer designs and develops the remote processing and whether the product depends on it to function.
Review private-label and white-label product arrangements for who uses the name or trademark and whether products have been substantially modified.
Keep legacy products in the scope discussion until the applicable older-product exception has been established.