CRA reporting obligation since September 2026: What must be reported for machines and plants?

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. Art. 3(42) CRA defines it as a vulnerability for which there is reliable evidence that an actor executed malicious code in a system without the system owner's permission.
• 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. For a system not yet placed on the market, however, the same CVE decides whether shipping it as is is permissible (article on known vulnerabilities).

A case like Log4Shell is not automatically reportable

The definition in Art. 3(42) says "a system", not the manufacturer's product. One could read that as: if a component is attacked anywhere, everyone who has installed it must report. The Commission FAQ (section 5.4) only says that for an actively exploited vulnerability originating from an integrated component, the manufacturer of the overall product reports as well, in addition to the component manufacturer.

The Commission's guidelines of July 2026 are more precise (para. 218). They name two cases in which the vulnerability does not count as actively exploited for your own product and the mandatory report falls away: the vulnerability cannot be exploited in your product, for instance because the vulnerable code path is not reachable. Or it has not been exploited in your product. For a plant builder that means: if a library inside an installed controller lands on the KEV list because it is being attacked elsewhere, that alone does not trigger a report. Your own 24-hour deadline starts only once it is reliably established that one of your own machines has been attacked. Recital 68 describes the same case: the manufacturer establishes that a security breach affecting its users traces back to its product.

The guidelines are not binding, and the wording of Art. 3(42) is broader. Anyone who wants to be safe can report voluntarily under Art. 15; that costs effort but carries no risk. Anyone relying on para. 218 should document the check: which machines contain the component, is it reachable there, is there any indication of an attack. From December 2027, for products newly placed on the market, informing the component manufacturer under Art. 13(6) is added to that.

This shifts the deadline, not the work. Whether one of your own machines is affected can only be checked if you know which machines contain the component in which version. And in practice, awareness arrives from the customer whose production has stopped. Then the clock is running, and the check has to be complete within 24 hours.

Reporting runs in three stages: 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. That means settling beforehand who receives the information and who reports, including when the person responsible is on holiday. And someone has to be watching the installed components in the first place, otherwise you learn of the exploitation when the deadline is already running.

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.

The EUVD is one of the sources from which you learn that a vulnerability is being exploited, and so one of the triggers for the 24-hour deadline. Reports go only 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).

Only one of these entries takes real work: 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.

Breaches cost 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 vulnerability originating from an integrated component is actively exploited in your product, 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?

According to the Commission's reading, yes. The guidelines exempt component vulnerabilities from mandatory reporting if they cannot be exploited in your product or have not been exploited there (para. 218). An attack on someone else's machine with the same controller therefore does not start your clock. You still have to check whether one of your machines is affected, and for that you need to know where the component sits. Details 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. If you do not track which components run in which firmware versions in the field, you frequently hear about it from the customer. By then the deadline is already running.

What Article 14 does not require

In a note dated 21 September 2026, the VDMA (German Mechanical Engineering Industry Association) warns against over-interpreting the reporting obligation, not least because member companies have been approached with offers for automated vulnerability searches. We are one of those providers. So here is what Article 14 does not require, according to the text of the regulation and the Commission's reading:

• No duty to search actively. The CRA does not prescribe how a manufacturer becomes aware, only what it must do once it is. The Commission FAQ (section 5.1) lists advisories, threat intelligence reports, authorities, customers and the manufacturer's own telemetry as examples, and states that this does not imply an obligation to monitor those channels.
• No vulnerability handling under Annex I Part II. For systems placed on the market before 11 December 2027, only the reporting obligation applies. The vulnerability handling requirements of Annex I Part II do not (guidelines para. 210, FAQ 5.3). The same applies once the support period has ended.
• No SBOM. The SBOM is a requirement of Annex I Part II and therefore mandatory only from December 2027, and only for products placed on the market from then on. The report itself does not need one.
• No duty to fix legacy systems. The Commission acknowledges that older products often can no longer be investigated. They still have to be reported, but the CRA imposes no obligation to remediate them (FAQ 5.3). Supply contracts and product liability are unaffected.
• No single point of contact and no 24/7 on-call service. The contact point for vulnerability reports is a requirement of Annex I Part II, not of Article 14. The CRA does not prescribe an on-call service. The 24 hours do run from awareness, though, including at the weekend. A deputising rule replaces the on-call service.
• No relief for SMEs. Article 14 contains no exception by company size. The deadlines apply to a ten-person business as they do to a group.

What remains is the deadline: 24 hours from the moment the manufacturer knows with a reasonable degree of certainty that a vulnerability in its product is being exploited (guidelines para. 213). That awareness arrives without any monitoring of your own, for example from the customer whose line has stopped. Whether you then know which systems in which version are affected decides whether the deadline can be met. That is an argument for the field base, not an obligation under Article 14.

The reporting case can be rehearsed in advance

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

• Which of your products with digital elements are on the market, and in which Member States?
• Who assesses, who reports, and who stands in for them outside office hours?
• Set up the platform's mandatory fields as an internal template.
• Match advisories and exploitation status for installed components against your own field base. Without that, the trigger every deadline hangs on is missing.
• Text modules and distribution lists for customer information, separate from the report to the authorities.
• Schedule ENISA's testing period as soon as dates are published.

One way to test this: tomorrow, one of your installed components appears on the KEV list. How long until you know which machines are affected, and in which version?

After an attack, the customer asks why the advisory never arrived

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. After an attack, production is down at the customer's site. The controller manufacturer's advisory had been public for weeks. The customer asks why they were not informed and points at the supply contract. "We did not know about it" is an uncomfortable answer to give in that conversation.

The offer: capture one product line's field base in two sessions, first affected-systems list after two weeks

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.

Request an intro call →

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 September 2026, before publication of the ENISA manuals) and does not constitute legal advice.