CRA reporting obligation from September 2026: Which machines are affected?

The reporting obligation arrives before every other CRA obligation

Most obligations of the Cyber Resilience Act apply from December 2027. Article 14, the reporting obligation, starts earlier: on 11 September 2026. The same day, the central platform that all reports go through goes live – the Single Reporting Platform (SRP) run by ENISA, the EU cybersecurity agency – often referred to simply as the ENISA reporting platform. A testing period before launch is foreseen; ENISA has announced manuals, onboarding and dry-run material, but concrete dates are still outstanding.

The obligation applies to anyone who is the manufacturer of a product with digital elements – and that usually includes plant builders and integrators themselves, not just their component suppliers. A separate article explains why.

Less has to be reported than many fear

Exactly two cases trigger a report:

• An actively exploited vulnerability in your own product – a vulnerability for which there are reliable indications that someone is actually using it against systems.
• A severe incident affecting the security of the product – for instance attackers compromising update delivery, or breaking into customer systems through the product.

The vast majority of vulnerabilities are therefore not reportable: a CVE in an installed component with no indication of exploitation does not trigger a report. It belongs in regular vulnerability management, not on the reporting platform.

Three deadlines: 24 hours, 72 hours, final report

The 24 hours run from awareness – not from the next working day. If active exploitation becomes known on Friday evening, the early warning is due Saturday evening. Meeting the deadline is a matter of organisation: who receives the information, who decides, who reports – including on weekends and during holidays? Becoming aware in time in the first place is not. For that, someone has to be watching the installed components.

Reports go through ENISA's Single Reporting Platform (SRP)

At least there is only one reporting channel. A report to the SRP automatically reaches the competent national CSIRT (determined by the manufacturer's main establishment) and ENISA at the same time. If products are in use in several Member States, the receiving CSIRT passes the report on – the manufacturer still reports only once.

Easy to confuse with the SRP is the European Vulnerability Database (EUVD) – both come from ENISA, both deal with vulnerabilities. But the direction is exactly opposite: manufacturers report into the SRP and read out of the EUVD.

Both matter for the reporting obligation, but in different roles: the EUVD is one of the sources showing that a vulnerability is being actively exploited – the signal that starts the 24-hour clock. The report itself then goes exclusively through the SRP.

What has to be in the first 24-hour report

ENISA has published the SRP's reporting fields. For the early warning, the mandatory part is deliberately short:

• Type of report: actively exploited vulnerability or severe incident
• Name of the manufacturer
• The affected product
• Title or short description
• For incidents: whether an unlawful or malicious act is suspected
• Where known: the Member States in which the product is made available

The substance follows in the 72-hour notification (nature of the vulnerability, countermeasures taken, recommendations for users) and in the final report (full description with severity and impact, details of the security update).

The list looks harmless. The hard part sits in a single question: which of your products and delivered machines are affected? If you only start researching that for a purchased component on the day of the report, the 24 hours are spent before the form is even open.

Fines: up to 15 million euros or 2.5 percent of turnover

Violations of the vulnerability-handling and reporting obligations of Articles 13 and 14 can be fined up to 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher. That is the highest fine tier the CRA has – the legislator takes the reporting obligation more seriously than most other obligations in the regulation.

Four questions from practice

Who reports for purchased components – me or my supplier?

Both. The Commission's FAQ on CRA implementation is explicit: where a product contains an actively exploited vulnerability originating from an integrated component, the manufacturer of the product must report it – in addition to the manufacturer of the component. Everyone reports for their own product. The platform's "report only once" means "once instead of to many authorities", not "one report covers the whole supply chain". Relying on the supplier to report will not hold up.

Does the exploitation have to happen in my machine?

No. "Actively exploited" under the CRA's definition means: there is reliable evidence that an attacker has exploited the vulnerability in some system without permission – not necessarily in your machine. Log4Shell makes it concrete: if a library vulnerability is being exploited worldwide and the affected library sits in a component built into your machine, your reporting obligation is triggered as soon as you become aware of it. An attack on your own machine is not required.

The one exception: if the vulnerability demonstrably cannot be exploited in your product – for instance because the vulnerable code path is not reachable in your configuration – there is no mandatory report. You then have to inform the component manufacturer – and be able to substantiate and document the "not exploitable".

Do I also have to inform my customers?

Yes. Alongside the report to the authorities, the CRA requires informing the impacted users – about the incident or vulnerability and, where necessary, about mitigations they can apply to reduce the risk. The platform report does not replace customer communication; both tracks should be prepared separately in the internal process.

How would I even know a vulnerability is being actively exploited?

By monitoring your own installed base: supplier advisories, catalogues of known exploited vulnerabilities such as CISA KEV and the exploited status in the EUVD. Without systematically tracking which components run in which firmware versions in the field, you often learn about exploitation only when the 24-hour clock has long been running – or from your own customer.

What can be prepared now

Until 11 September 2026 there is enough time to rehearse the case before it occurs:

• Product inventory: Which of your products with digital elements are on the market, and in which Member States?
• Responsibility and availability: Who assesses, who decides, who reports – with deputies, including outside office hours?
• Internal report template: Prepare the platform's mandatory fields as a template so nobody has to research entries under time pressure.
• Component monitoring: Systematically track advisories and exploitation status for installed components and match them against your field base – otherwise the trigger that starts every deadline is missing.
• Customer communication: Prepare text modules and distribution lists for user information, separate from the report to the authorities.
• Use the testing period: ENISA has announced dry-run opportunities before launch – schedule them as soon as dates are published.

How well you are prepared for 11 September can be measured with a single question: a component in your machines shows up on an exploited list tomorrow – how long until you know which machines, in which versions, are affected? We will walk through this scenario with you, using your own components.

Werkspilot monitors supplier advisories automatically and matches them against the field base of plant builders and integrators. This article reflects Werkspilot's assessment (as of July 2026, before publication of the ENISA manuals) and does not constitute legal advice.