A manufacturer placing a connected robot on the EU market should have an incident-reporting workflow ready before 11 September 2026. The European Commission's CRA reporting page says manufacturers must notify actively exploited vulnerabilities and severe incidents affecting the security of a product with digital elements. That reporting date is not the same as 11 December 2027, when the Cyber Resilience Act applies in full. Treating the two dates as one deadline leaves the most urgent operational gap hidden.
A network connection does not, by itself, make every robot an Annex III important product. The first job is to identify which robot, controller, gateway, cloud service, application or separately marketed component is a product with digital elements, then check exclusions and the relevant classification. This article is an implementation-oriented guide, not legal advice or a conformity determination for a particular model.
The September deadline is an operational reporting deadline
The Commission's current CRA implementation timeline separates the reporting provisions, which apply from 11 September 2026, from full application on 11 December 2027. As of 7 August 2026, a robot maker therefore needs a working intake, triage, approval and submission process before every part of its 2027 conformity programme is complete. The distinction matters because an incident can arrive during the transition period.
A reporting playbook cannot operate without a product map. A field robot may depend on an onboard computer, motor controllers, wireless modules, a fleet cloud, a technician app and an update-signing service. The response team needs to know which versions and customers are exposed before it can make a credible assessment inside 24 hours. A practical starting point for the communications boundary is the ROS 2 and DDS robot cybersecurity guide.
| Date or period | CRA milestone | What the robot team should prove |
|---|---|---|
| 11 September 2026 | Reporting duties begin | Intake, triage, approval and Single Reporting Platform submission can run around the clock |
| 11 December 2027 | CRA applies in full | Product-security, documentation and conformity work is complete for the applicable product |
| Support period | Vulnerability handling continues | Affected versions, fixes, deployment evidence and end-of-support decisions remain traceable |
Start with the product boundary, not the word robot
The Commission's CRA implementation FAQ describes the CRA as a horizontal framework for hardware and software products made available on the Union market. It covers final products and components placed on the market separately. A bill of products may therefore need separate rows for the complete robot, an independently supplied controller, a paid fleet-management package, a remote-maintenance gateway and an SDK offered as its own product.
The legal review must then test how each item is made available, whether an exclusion or sector-specific EU regime applies, and whether its functionality matches an important or critical product category. Do not label every connected machine as Annex III merely because it has Wi-Fi, Ethernet or remote access. Record the reasoning against the official text of Regulation (EU) 2024/2847, including the product description and the version of the technical interpretation used.
The 24-hour clock changes how incidents must enter the company
For an actively exploited vulnerability or a severe incident affecting product security, the Commission describes an early warning within 24 hours of awareness and a full notification within 72 hours. For an actively exploited vulnerability, a final report follows no later than 14 days after a corrective measure is available; for a severe incident, the final report is due within a month. Manufacturers submit once through the CRA Single Reporting Platform, which is intended to be operational when the reporting rules start.
Those windows make ownership more important than the ticketing tool. The playbook should state who records the awareness time, who decides whether exploitation is active, who can approve an early warning at night or over a weekend, and who keeps safety and cybersecurity investigations aligned. A robot that stops, takes an unexpected route or accepts an unauthorised command may involve operational safety, cybersecurity, or both; the evidence must allow the two tracks to meet without treating every mechanical failure as a CRA report.
| Reporting stage | Commission timeline | Minimum internal evidence |
|---|---|---|
| Early warning | Within 24 hours of awareness | Affected product and version, initial impact, exploitation or incident assessment |
| Full notification | Within 72 hours of awareness | Technical analysis, exposure, immediate containment and known customer impact |
| Vulnerability final report | No later than 14 days after a corrective measure is available | Root cause, fixed release, distribution and customer communication records |
| Severe-incident final report | Within one month | Incident chronology, recovery, corrective actions and residual risk |
Build one evidence chain across the robot, cloud and suppliers
A serial number alone is not enough for connected-product response. Keep a reproducible relationship between the hardware revision, firmware, operating-system image, robot application, cloud tenant, mobile or technician application, cryptographic credentials and third-party components. Add supplier security contacts and the method used to decide whether a newly disclosed vulnerability reaches a shipped configuration. That relationship lets responders narrow the affected population rather than notify from guesswork.
This does not mean claiming that one particular inventory format is universally mandated. The outcome that matters is the manufacturer's ability to perform the cybersecurity risk assessment, handle vulnerabilities, maintain the technical evidence and support statements made in a notification. Where a cyber event could produce hazardous movement, connect that evidence to the scenarios documented in the robot risk-assessment guide so the security fix does not create an unexamined safety change.
An OTA pipeline must fail safely as well as deploy securely
For a robot, a security update is a controlled physical intervention. Signing and verification, version eligibility, staged rollout, interruption recovery, maintenance-mode constraints and a safe state after failure belong in the same design. A partially installed controller image can stop production, but a mismatched motion component can be more serious: the robot may boot with assumptions that no longer match its safety configuration.
The response team also needs deployment evidence after a fix is released. Record which units received the update, which failed, which rolled back, which are offline and which have reached end of support. The robot OTA update and rollback guide explains why atomic switching, health checks and a tested recovery path are more useful than a nominally successful upload percentage.
Use the same product record for reporting and conformity work
The longer 2027 programme should connect design-stage cybersecurity risk assessment, secure defaults, access control, protection of relevant data, attack-surface reduction, vulnerability handling, user information and technical documentation. If the incident team calls a release by its cloud deployment name while engineering and conformity files use a sales model name, the company can lose much of the 24-hour window merely reconciling identities.
Give a product owner responsibility for the canonical link between commercial model, hardware revision, software release, dependent online service and support period. The applicable conformity-assessment route can depend on the final classification, so a connected robot should not be assigned an external-assessment route by analogy alone. Keep the decision record dated and revisit it as Commission guidance, implementing acts and harmonised standards mature.
A focused readiness drill can expose gaps before September
Run the drill with a plausible case: a supplier reports that a library used in the fleet gateway is being exploited, while the exact robot versions are initially unclear. Start the awareness clock, identify the accountable manufacturer, determine affected products, create the early-warning draft, obtain approval and prepare the fields needed by the Single Reporting Platform. Continue to the 72-hour notification instead of ending the exercise once the security team has produced a patch.
Score the drill on evidence retrieval and decisions, not on presentation. Could the team identify EU customers and product versions? Could it separate an actively exploited vulnerability from a vulnerability with no evidence of exploitation? Could it issue a safe mitigation while an OTA fix was still being tested? Turn each delay into an owner and due date. This creates an immediate reporting track for 2026 and a separate product-improvement track leading to full application in 2027.
What a manufacturer should have on one page
The one-page control sheet should name the legal manufacturer for each product, the incident lead and deputy, the 24-hour contact route, the canonical product and version register, the supplier escalation path, the Single Reporting Platform owner, and the authority that can approve customer mitigations. It should also point to the current classification memo rather than merely stating that the product is compliant.
Keep the caveat visible: readiness for September reporting does not prove full CRA conformity, and a completed CRA workstream does not replace machinery, radio, data-protection, workplace-safety or sector-specific analysis that may also apply. A qualified EU legal and conformity professional should confirm the boundary for each marketed configuration and distribution model.
Frequently asked questions
Is every internet-connected robot an Annex III important product under the CRA?
No. Connectivity alone does not determine Annex III status. The manufacturer must assess how the item is made available, its functions and technical description, separately marketed components, exclusions and any sector-specific EU regime.
Must a robot manufacturer finish full CRA conformity assessment by 11 September 2026?
That date starts the reporting duties for actively exploited vulnerabilities and severe product-security incidents. The CRA applies in full from 11 December 2027, so the reporting workflow and the broader conformity programme should be managed as separate but connected tracks.
Does a robot operator submit the CRA report directly within 24 hours?
The Commission's reporting guidance identifies manufacturers as the reporting party. Operators, integrators and distributors still need a rapid contractual route to send evidence to the manufacturer, and they should separately check any other duties that apply to their role.
Official sources checked
- Official text of Regulation (EU) 2024/2847
- European Commission CRA implementation timeline
- European Commission CRA implementation FAQ
- European Commission CRA reporting obligations
2026-08-07