CRA reporting obligation from 11 September 2026: who reports, what and when

Do you place a product with digital elements on the market? WZ-IT tracks vulnerabilities in your components continuously through CVE monitoring and works out with you which compliance requirements apply to your operations. Discuss your exposure

On 11 September 2026 the first operational obligation of the Cyber Resilience Act takes effect. It is narrowly scoped: it concerns reporting only, not conformity assessment or CE marking. Anyone covered by it must be able to react within 24 hours from that day.

Most write-ups list the deadlines. The harder question comes before that and is rarely answered: am I a manufacturer at all? For companies that configure third-party hardware, bundle open-source software and ship the result under their own name, the answer is less obvious than it first appears.

This article sets out what starts on 11 September, who it affects, what triggers a report and what has to be in place by then.

Last reviewed: 22 August 2026.

Table of contents

• What starts on 11 September 2026
• Who counts as a manufacturer under the CRA
• What triggers a report
• The three reports and their deadlines
• What falls outside the CRA
• Open source: operator, steward, manufacturer
• What has to be in place by 11 September
• How we approach this at WZ-IT
• Further guides

What starts on 11 September 2026

Regulation (EU) 2024/2847 was published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024. Its obligations apply in stages:

This staging matters. From September there is a reporting duty without the rest of the obligations. Secure development, vulnerability handling across the support period, technical documentation and CE marking follow 15 months later.

In practice: there is no approval procedure anyone has to pass in September. There is a duty to report quickly and to the right place when something happens.

Who counts as a manufacturer under the CRA

Article 3 defines a manufacturer as an entity that develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark.

The second half is the decisive part. Own production is not required; the own name is enough. That brings in constellations which do not feel like manufacturing from the inside:

• An appliance built from purchased hardware, preinstalled with a self-assembled software selection and shipped under an own product name
• A device that a partner resells under its own brand while the configuration comes from you
• A software product whose components come mostly from open-source projects and which ships as a whole under an own name

The commercial form changes little. Making available on the market is defined in Article 3 as the supply of a product for distribution or use in the course of a commercial activity, whether in return for payment or free of charge. Leasing rather than selling does not exit that definition.

A common confusion concerns CE marking. A hardware manufacturer declares CE and RoHS for electrical safety and substance restrictions. Those are different legal bases. CRA cybersecurity conformity is not covered by them.

An organisation that merely operates third-party software, for example as part of managed hosting, does not place anything on the market and is not a manufacturer. The line runs where operating turns into supplying under an own name, or where a product is passed on substantially modified.

What triggers a report

Article 14(1) requires reporting any actively exploited vulnerability contained in the product once the manufacturer becomes aware of it. Paragraph 3 requires the same for any severe incident having an impact on the security of the product.

Two conditions have to come together.

First: the vulnerability is actively exploited. Article 3(42) defines this as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. The wording says a system, not yours. Reliable evidence includes established external sources such as the CISA KEV catalog or the European vulnerability database, threat intelligence with technical indicators, or your own forensics.

Not sufficient: a high CVSS score, a published proof of concept, or a single alert from your own monitoring. Theoretical exploitability does not trigger the duty.

Second: the vulnerability is contained in your product. That requires a product-specific assessment. Is the affected component shipped at all? In the affected version? Is the vulnerable code path present and enabled in your build? If any of these is negative, the vulnerability is not contained and there is nothing to report. You have to be able to make and document that determination.

The deployment environment is not among the conditions. Whether an individual device at a customer site is reachable from the internet or sits in an isolated network does not appear in Article 14. That is consistent: a manufacturer usually does not know the deployment environment of shipped devices. Isolated operation therefore belongs in the 72-hour report as a mitigating measure, not before it as a reason not to report.

The three reports and their deadlines

Reports go simultaneously to the CSIRT designated as coordinator in the relevant member state and to ENISA, via the single reporting platform under Article 16.

The two final reports run differently: for a vulnerability the clock starts only once a measure is available. For an incident it starts from the submitted notification.

Article 14(8) adds a further duty: impacted users must be informed about the vulnerability or incident, including available mitigation and corrective measures.

The critical number is 24. An early warning within one day presupposes that the reporting path is not organised on the day of the incident.

What falls outside the CRA

Article 2 excludes several product groups because they are already regulated sector by sector: medical devices and in-vitro diagnostics, motor vehicles, certified aviation equipment and marine equipment. Also excluded are spare parts that replace identical parts according to the original specifications, and products developed exclusively for national security or defence purposes.

Two further distinctions matter more for IT service providers.

Pure SaaS is not the target of the CRA under recital 9 and falls rather within the scope of the NIS2 Directive and national implementing law. The exception is remote data processing solutions that are essential to a product with digital elements and are developed by the manufacturer or under its responsibility. A cloud component without which a shipped appliance does not work is part of the product.

Merely operating third-party software does not create a manufacturer role. An organisation managing systems for customers is a service provider. Obligations there arise from NIS2 rather than the CRA. We covered those requirements in the article on NIS2 and remote maintenance.

For bespoke software built for one customer the legal position is unsettled. Part of the commentary places locally installed contract software within the scope, another part places development for exactly one customer outside it. Anyone regularly delivering custom software should have this clarified legally for their own contract models rather than relying on either reading.

Open source: operator, steward, manufacturer

The CRA distinguishes three roles that are often conflated in practice.

Non-commercial free and open-source software is outside the scope. A project without commercial exploitation does not become a manufacturer.

Open-source software steward is defined in Article 24 as a legal person that is not a manufacturer and that systematically and sustainably supports the development of specific open-source products intended for commercial activities. The obligations are deliberately lighter: a documented cybersecurity policy, cooperation with market surveillance authorities, and participation in reporting actively exploited vulnerabilities as far as the role extends into development. No CE marking, no formal conformity assessment. The reporting duty applies to stewards from 11 September 2026 as well.

Manufacturer is whoever markets an open-source product under their own name or passes it on substantially modified. The role follows the actual market position, not the internal description. For companies shipping a local AI appliance or an App Node with a preinstalled open-source stack, this is the decisive question: they ship third-party code, but their own product.

What has to be in place by 11 September

The effort is not in reporting. It is in what makes a report within 24 hours possible at all.

1. Know what you ship. A reliable component list per product and version, including dependencies. Without it the question "does this affect us?" cannot be answered, and without an answer you either over-report or report late. A software bill of materials becomes part of the technical documentation from December 2027 anyway.

2. Notice when something is exploited. The trigger is not every CVE, but the subset with evidenced exploitation. In practice: matching your own component list against KEV, the European vulnerability database and vendor advisories. That is exactly what continuous CVE monitoring does, applied to your product rather than only to your servers.

3. Define the reporting path in advance. Which CSIRT is responsible, who has access to the ENISA platform, who decides on a report, who writes it, who informs users. Clarifying these on the day of the incident consumes the larger part of the 24 hours.

4. Involve suppliers and resellers. If a partner resells your product under their own brand, the reporting duty stays with you as the manufacturer. That requires information from your suppliers about their components and agreements with resellers about passing on incident information.

How we approach this at WZ-IT

We operate systems for customers and at the same time ship devices with a preinstalled open-source stack. Both questions therefore apply to us, and we treat them separately.

For operating third-party software we are a service provider, not a manufacturer. The relevant requirements there come from NIS2 and from contractual commitments, not from the CRA.

For shipped devices we assess the manufacturer role per product and work on the foundation that makes a 24-hour report possible in the first place: a maintained component list per shipping state and a comparison against sources that track evidenced exploitation. The reporting path itself is organisation, not technology, and belongs in place before the first real incident.

We do not provide legal advice. Where the classification of a role determines obligations, it belongs with a lawyer. What we contribute is the technical side: transparency about what is actually shipped, and monitoring that does not raise an alarm on every CVE but on the subset with evidenced exploitation.

Further guides

• NIS2 and remote maintenance: requirements and the BSI deadline covers the operator side that applies alongside the CRA
• Metabase vulnerability with CVSS 10.0 shows on a real case how quickly an advisory becomes an exploited vulnerability
• CVE monitoring and compliance in operations describe the ongoing services behind this

Unsure whether your product creates manufacturer obligations? We review with you what you actually ship, which components it contains, and what a reporting path looks like that holds a 24-hour deadline. Book a call

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), full text
• Article 14: reporting obligations of manufacturers
• Article 3: definitions
• Article 24: obligations of open-source software stewards
• BSI: Cyber Resilience Act
• European Commission: Cyber Resilience Act
• ENISA: Single Reporting Platform, FAQ
• CISA: Known Exploited Vulnerabilities Catalog