Cyber Resilience Act: The Reporting Duty Starts on 11 September, and the Reporting Platform Is Not Ready (Yet)

From 11 September 2026, manufacturers of connected products must report actively exploited vulnerabilities within 24 hours. The platform for doing so was not in service at the end of July, and its address remains unpublished. At the same time, the European Commission has issued 84 pages of guidance. It answers four questions on which every compliance project has so far stalled.

The Cyber Resilience Act entered into force in December 2024, and its main obligations only bite from 11 December 2027. In between lies a date that is not yet on many companies’ radar: 11 September 2026. From that day the reporting duty under Article 14 applies, regardless of whether a product is new or has been in the field for years. On 27 July the European Commission published practical guidance on this, aimed at microenterprises and mid-sized firms without a legal department of their own. It contains 67 worked examples, use cases and decision charts. Legally the document binds no one. Only the Court of Justice of the European Union can interpret the regulation authoritatively. Market surveillance authorities and notified bodies will nevertheless take their cue from it. Why the read pays off for connected products becomes clear in four chapters that decide everything in practice.

What did the European Commission publish on 27 July?

The package comes in two parts: a short communication and the guidance itself as an annex. The Commission has approved the content; it will formally adopt the document only once all language versions are available. That changes nothing about the substance. It does mean, though, that the guidance exists in English only for now. Anyone affected as a German mid-sized manufacturer has to work through 84 pages of English regulatory vocabulary. The guidance covers, among other things:

• When does a product fall under the regulation at all?
• When does a cloud component form part of it?
• How should free and open-source software and its stewards be classified?
• What counts as a substantial modification?
• How long must a product be supported?
• How does a manufacturer meet its reporting and risk assessment obligations?

Not covered: the technical standards against which manufacturers will later be measured. Those are being drawn up in parallel by the European standardisation organisations. The Commission expects the first deliverables in the third quarter of 2026, according to its implementation timeline.

When does the cloud form part of the product?

For IoT this is the most important section. The regulation counts a product with digital elements as including its remote data processing solutions, meaning software parts that run outside the device. Exactly where that line falls has been unclear until now. The guidance turns it into a test with two questions. Both must be answered yes.

• First: would the product lose one of its functions without that data processing? The Commission lists what qualifies: sending commands to a device, synchronising files, onboarding users, configuration, distributing updates and security patches automatically, managing identities and access. What does not qualify is the remote analysis of telemetry data collected purely for statistics or future product development. Important for smart home products: the fact that a function can also be triggered manually, switching a light by hand rather than through the app, does not strip the app-based control of its status as remote data processing.
• Second: was the software developed by the manufacturer or on its behalf? “On its behalf” means bespoke solutions built to the manufacturer’s own specifications, not the mere licensing of a finished service. Who subsequently operates the solution is irrelevant. From this follows a rule of thumb worth remembering: with rented infrastructure or a rented development platform, known in the industry as IaaS and PaaS, the manufacturer’s own application running on top meets this second criterion. With bought-in ready-made software, that is SaaS, it does not.

The Commission works this through with examples: A smart thermostat whose app control runs on software the manufacturer is responsible for, hosted on rented infrastructure: remote data processing, part of the product. The manufacturer must describe both that solution and the third-party infrastructure in the technical documentation, including details of the contracted service. It must also satisfy itself that the provider’s protective measures are adequate, for instance by asking for evidence that NIS 2 obligations have been met. NIS 2 is the EU directive that imposes its own security requirements on operators of essential and important services.

An industrial robot that sends camera images to a cloud service developed in house and receives picking commands back: the same result. An e-reader that stores purchased books with a third-party storage service: without the service the product does not work, but the service does not come from the manufacturer. It does not form part of the product, yet it is treated like a supplied component. The manufacturer must assess the risks and counter them on the product side: secure authentication, encryption and integrity protection for the connection to the storage service. In selecting and integrating the provider, it owes due diligence.

And the reassurance for everyone working in connectivity: the mobile network does not count. A smartphone must be able to connect to a network correctly. Whether the network happens to be up says nothing about whether the device works. The network merely transmits, like an Ethernet cable or a Wi-Fi signal. No manufacturer has to demonstrate due diligence towards the network operator. Two further boundaries help in practice. A solution running on the manufacturer’s own servers on site can also be remote data processing; this is not about public cloud. And only those software modules that carry a product function are caught, together with their interfaces to the outside. Systems further back, with which the product does not communicate directly, stay outside, as do HR administration, CRM, build pipelines and penetration testing.

Who is liable for open-source components in the device?

The relief is broader than expected: anyone embedding free software in their product is not liable for its own conformity, even if they contribute code to its maintenance. Whether a component falls under the regulation depends solely on whether the person publishing it places it on the market. The clearest example: an individual developer publishes a project freely and adds a donation link. Three companies embed it and donate voluntarily so that maintenance continues.

The result: the project is not considered placed on the market, and the developer carries no obligations. The three companies keep theirs, and they are concrete. They must exercise due diligence in selection and integration, as Article 13(5) requires, and under Article 13(6) report vulnerabilities to the project concerned and share their security fixes back with it. The good news for the open-source community is thus the bad news for device makers: the burden shifts entirely to whoever sells the device. How that reshapes the economics of cheap hardware has already been discussed at length by WeSpeakIoT author Dirk Roebers in this commentary.

When does a firmware update turn the device into a new product?

A substantial modification sets the conformity obligations running again. What matters is not the scale of the change but whether it shifts the risk profile and whether the original assessment already covered that risk. A machine dashboard that previously only displayed data and, after the update, controls machines and restarts them after faults: substantially modified. Its purpose has shifted from a monitoring tool to a control system.

A production monitoring system, by contrast, whose control functions were present from the outset, assessed and merely switched off, and are enabled later: not substantially modified. Conversely, a small thing can be enough. A “keep me signed in” function that stores authentication tokens locally counts as a substantial modification, because it introduces new risks: token theft and session hijacking, which nobody had assessed before. From this follows one of the few genuine instructions in the document. Anyone who writes the risk assessment with foresight and covers planned functions there in advance saves conformity work later.

How do you report from 11 September?

The cascade of deadlines is familiar: an early warning without undue delay and within 24 hours at the latest. A fuller notification within 72 hours. A complete report within 14 days of a corrective measure becoming available, and for severe incidents within one month of the 72-hour notification. Reports go to two places at once: the competent national CSIRT, the state response unit for IT security incidents, and the EU agency ENISA. Four clarifications in the guidance narrow down what the duty actually demands.

The clock does not start with the first tip-off. A manufacturer is treated as aware only once, after an initial assessment, it holds a reasonable degree of certainty that someone is actively exploiting a vulnerability. The Commission draws on the same interpretation that applies to personal data breaches under the GDPR. Anyone who drags out that initial assessment cannot rely on this.

Old incidents stay outside. Vulnerabilities whose active exploitation was already known before 11 September 2026 need not be reported retroactively. If, by contrast, a manufacturer knew only of the vulnerability and not of any exploitation, and exploitation occurs later, the duty applies.

For supplied components: if the product contains an actively exploited vulnerability originating in a third-party component, the manufacturer must report it. If the vulnerability cannot be exploited in its own product, for instance because the affected code is not reachable, the report is not required.

Old devices stay inside. The absence of retroactivity applies to incidents, not to products: the duty also covers devices placed on the market before 11 December 2027, and it continues after the support period ends. The formula is therefore “old device, new event”. Anyone running a sensor fleet in the field is affected from September without a single device changing.

And the tool?

This is where the gap opens. Reports go through a central platform operated by ENISA, which forwards a single submission to all the competent bodies. According to ENISA’s information as of 31 July 2026, that platform is not yet running. The agency will announce its public address only shortly before launch, and it is not providing interfaces for connecting a company’s own systems at this stage. Reporting will therefore be done by hand.

Two further points are worth knowing. Registration runs through an EU Login account, which can be set up already. ENISA advises against triggering validation in advance, however: it should be started only when a report is actually due, otherwise the requests overload the bodies carrying out the checks. And the list of which national CSIRT is competent for which head office is something the agency intends to publish later. Anyone who has to report in an emergency cannot look up today where to send it.

That leaves only what sits in one’s own house to be prepared: deciding who clears a report, running through the process once on an invented case, and establishing which details even have to be available in the first 24 hours. ENISA has announced a webinar two weeks before launch.

Conclusion

The guidance answers the questions on which internal CRA projects have foundered until now, and it does so refreshingly concretely: with worked cases rather than principles. Anyone who could previously point to an unclear scope has lost that excuse. At the same time the timing shows how unevenly the building blocks of this regulation have matured. The interpretation is available, in English only for now. The technical standards are still being written.

And the one tool that is indispensable from 11 September cannot be reached six weeks beforehand. The deadline stands regardless. In practice this means the process at home has to be in place before the platform is. Who decides whether a report goes out? Who is allowed to submit it? How do you reach that person at the weekend? These questions need no EU infrastructure. They should not be answered for the first time while the 24 hours are already running.

Sources: C(2026) 5252, Annex – Commission guidance on the application of the Cyber Resilience Act (available in English only) · Regulation (EU) 2024/2847 · Reporting obligations, European Commission

- Advertisement -