CRA reporting obligation from September 2026: What must be reported for machines and plants?
In brief · As of: July 2026
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents – the first report within 24 hours, via ENISA's new central reporting platform. The reporting obligation thus applies more than a year before the rest of the Cyber Resilience Act – and it covers plant builders and integrators who qualify as manufacturers. Only two cases are reportable; the hard part is the deadlines.
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 date applies with no grandfathering. The Commission's guidelines on the application of the CRA, adopted in July 2026 (C(2026) 5252), make this explicit: from 11 September 2026 Article 14 covers all products with digital elements within scope – including those placed on the market before 11 December 2027. And unlike the vulnerability handling obligations, the reporting obligation does not end with the support period; it continues beyond it (para. 210).
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.
Only two cases are reportable
Article 14 distinguishes:
- 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.
A case like Log4Shell is still reportable
"Actively exploited" does not require an attack on your own machine. Reliable evidence that an attacker has exploited the vulnerability in some system is enough. If a library vulnerability like Log4Shell is being exploited worldwide and the library sits in a component built into your own product, the reporting obligation is triggered as soon as you become aware of it.
The one exception: the vulnerability demonstrably cannot be exploited in your product, for instance because the vulnerable code path is not reachable in your configuration. Then there is no mandatory report; you inform the component manufacturer instead, and the "not exploitable" must be substantiated and documented. The Commission's guidelines confirm this (para. 218) and allow a voluntary notification under Article 15 in that case.
Three deadlines: 24 hours, 72 hours, final report
| Stage | Deadline | Content |
|---|---|---|
| Early warning | 24 hours from awareness | Basics: who, which product, what happened (short form) |
| Notification | 72 hours from awareness | Assessment, measures taken, measures for users |
| Final report | Vulnerability: no later than 14 days after a corrective measure is available · Incident: 1 month after the 72-hour notification | Full description, severity, root cause, update details |
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 requires that someone is watching the installed components continuously.
The Commission's guidelines pin down when "awareness" begins: a suspicious event must be assessed immediately, and the clock starts once there is a reasonable degree of certainty that active exploitation is actually occurring (para. 213). Exploitation already known before 11 September 2026 does not have to be reported retroactively (para. 217).
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. Manufacturers report into the SRP and look up in the EUVD.
| SRP (reporting platform) | EUVD (database) | |
|---|---|---|
| Purpose | Submitting mandatory reports under Article 14 | Looking up vulnerabilities, incl. exploitation status |
| Direction | The manufacturer reports to CSIRT and ENISA | ENISA publishes, everyone reads |
| Available | from 11 September 2026 | online since May 2025 |
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 demanding entry in this list is a single one: 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.
Four questions from practice
Who reports for purchased components – me or my supplier?
Both. The Commission's FAQ on CRA implementation is explicit in section 5.4: 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 only bundles the authorities. Relying on the supplier to report will not hold up.
Does the exploitation have to happen in my machine?
No. Reliable evidence that an attacker has exploited the vulnerability in some system without permission is enough; if the affected component sits in your machine, your reporting obligation is triggered as soon as you become aware of it. The exception for vulnerabilities that demonstrably cannot be exploited is covered above in the Log4Shell section.
Do I also have to inform my customers?
Yes, under Article 14(8) CRA. Alongside the report to the authorities, the CRA requires informing the impacted users – about the incident or vulnerability and, where necessary, about the risk mitigation and corrective measures users can apply, where appropriate in a structured, machine-readable format. The platform report does not replace customer communication; both tracks should be prepared separately in the internal process. Where the manufacturer fails to inform users in time, the same provision allows the CSIRTs designated as coordinators to inform them instead.
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?
The awkward question comes from the customer
Monitoring only becomes mandatory in December 2027, reporting already in September 2026 – and with the report, informing the affected customers (Art. 14(8)). Both require that you hear about what the controller manufacturer published in the first place.
The more expensive case sits outside the regulation anyway: production is down at the customer's site after an attack, the controller manufacturer's advisory had been public on their website for weeks, and the customer asks, "why did you not inform us?" "We did not know about it" is the answer nobody wants to give. The customer will not absorb the downtime but point at the supply contract, the story does the rounds in the industry, and at home the management asks why nobody was monitoring this.
The offer: a monitored field base per product line
Werkspilot captures the field base of one product line in two sessions and matches your suppliers' advisories against it automatically from then on – after two weeks the first impact list is there, dated in the log: which machine, which version, which customer.
The internal report template with the SRP mandatory fields and the escalation path for the first 24 hours is available on request, against your name, company and system type. We check back after two weeks to see whether the escalation path is staffed: request the template.
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.