Cyber Resilience Act: new obligations for robot manufacturers

For manufacturers of connected robots, the Cyber Resilience Act (CRA) is now becoming relevant in practice: As of 11 September 2026, the reporting obligations for actively exploited vulnerabilities and severe security incidents will apply for the first time. The CRA thus makes cybersecurity a product property and, in the case of Physical AI, covers not only the robot itself but, under certain conditions, also cloud backends and other forms of remote processing. At the same time, a security incident may trigger obligations under the NIS-2 regime as well as under the CRA. It is therefore imperative for robot manufacturers to adapt their reporting processes, vulnerability management, updates and cyber risk assessments to the new requirements in good time.

This is the first of two articles on the topic of IT Security and Physical AI in our "Robotics and Physical AI" series. The focus is on the Cyber Resilience Act; the second part will address the operator's perspective under the German NIS-2 regime, as well as providing specific recommendations for action. 

How the FCC import ban, the CRA and NIS-2 regulate the same risk in different ways

At the end of July, the US telecoms regulator, the FCC, imposed far-reaching restrictions on market access for new humanoid and quadrupedal robots manufactured abroad – primarily on the grounds of cybersecurity and data leakage risks posed by internet-connected machines (FCC, 28 July 2026). The measure is clearly aimed at China; however, a comparison of the regulatory instruments is revealing. In response to the same risk – connected, sensor-equipped, remotely accessible robots – the US is imposing far-reaching restrictions on market access. The EU, by contrast, is responding with a product security and compliance programme: The CRA requires manufacturers to ensure that cybersecurity is an inherent property of their products. The NIS-2 Directive, on the other hand, requires security as an organisational obligation of the entity concerned – in our scenario, the operator. Both regimes are already relevant: The CRA's reporting obligations will apply from 11 September 2026 (Article 71 (2) CRA); the German NIS-2 Implementing Act  has been in force since 6 December 2025.

The first article in our series showed that even a single connected robot brings several legal regimes into play simultaneously. In the context of IT security, this has a particular implication: Here, two regimes address the same system from different angles, with the same incident potentially triggering two separate reporting chains.

Why connected robots pose specific cyber risks

A fictitious but typical scenario guides us through this article: A mechanical engineering company launches an autonomous mobile robot (AMR) for intralogistics. The product includes a fleet management system as a cloud service, which the manufacturer has developed itself and operates on infrastructure leased from a cloud provider: It assigns motion tasks, distributes software updates "over the air" and calculates navigation and grasp corrections based on the fleet's camera images. An automotive supplier specialising in the manufacture of vehicle parts, with 800 staff, operates forty of these robots; in the event of malfunctions, the manufacturer has remote maintenance access right down to the control level.

Part 2 of our blog series described the data stream as the actual asset of Physical AI ("Data is the asset"). The downside in terms of security is that this same data stream is the attack path. Every channel that enhances the robot's performance – telemetry to the cloud, the update mechanism that downloads new capabilities, remote maintenance access, the interface to the warehouse management system – simultaneously increases its attack surface. And unlike with an office computer, at the end of this path there is no file, but rather a moving object with mass, velocity and tools. A cyberattack can have a direct impact on machine safety in this context.

Traditional industrial robotics had contained this problem in two ways: The robot cell was physically enclosed and functionally isolated from the network. With connected robots, both of these limits have been removed. In Part 3 of our blog series, we described how the robot has left its confines and begun working right alongside humans – the same applies with regard to the network: The isolated "island" has become a permanently connected system comprising the device, the fleet backend and the update channel. This is precisely where the CRA and NIS-2 come into play.

Cyber Resilience Act: The CRA covers robots, including their cloud backend

The CRA applies to "products with digital elements": hardware and software intended to be used in a way that involves a direct or indirect data connection (Article 2 (1), Article 3 (1) CRA). The connected robot is a textbook example. From the control system and the communication modules to the supplied software, a data connection is required for its use. The obligations are staggered: The provisions on the notification of conformity assessment bodies have been in force since 11 June 2026; the reporting obligations under Article 14 will be in force as of 11 September 2026; and the full set of obligations – requirements under Annex I, conformity assessment, CE marking and technical documentation – will be in force as of 11 December 2027.

Since the end of July, an official interpretative aid has been available for the first time: On 27 July 2026, the Commission published its guidance on implementing the CRA (C(2026) 5252 – Guidance pursuant to Article 26 CRA; not legally binding). In the robotics sector, one clarification is particularly significant: The product also includes "remote data processing" (Article 3 (2) CRA). The guidance turns this into a three-question test: Does data processing take place remotely? Would its failure prevent the product from performing one of its functions? And was the software developed by the manufacturer or under its responsibility? If the answer to all three questions is "yes", the backend is considered to be part of the product. As a result, it must be included, among other things, in the cyber risk assessment, the requirements of Annex I – including the software bill of materials (SBOM) – and the CRA reporting obligations.

The guidance takes an industrial robot to illustrate its use case: A robot picks up parts that are positioned based on calculations made by the manufacturer's own cloud service using camera images – the service is part of the product, even though it runs on third-party leased infrastructure. The same applies to our fleet management system: motion task assignment, OTA update distribution and image analysis are all functions of the product that are performed remotely via the manufacturer's own software. 

The leased infrastructure underlying this, however, is not part of the product, but rather a dependency which the manufacturer must take into account in the risk assessment and technical documentation – the guidance expressly recommends obtaining evidence from the infrastructure provider that it has fulfilled its NIS-2 obligations. The Commission also sets clear boundaries: Telemetry used solely for statistical purposes or product development does not constitute remote processing; purchased standard services ("SaaS") are to be treated as components; the mobile or campus network is merely a transmission channel. 

Anyone using an ROS 2 software stack remains responsible for the overall product. When integrating open-source components, the due diligence obligations set out in Article 13 (5) CRA apply. If the manufacturer identifies a vulnerability in an integrated component, they must report it to the component's manufacturer or maintainer and take steps to address it within their product; if they have developed a fix, they must, in principle, also share the relevant code or documentation (Article 13 (6) CRA). For certain open-source stakeholders ("stewards"), however, Article 24 CRA provides for a separate set of obligations which are less stringent than those applicable to manufacturers.

CRA reporting obligations as of 11 September 2026: what manufacturers need to bear in mind

As of 11 September 2026, manufacturers must report two categories of incidents: actively exploited vulnerabilities in their products and severe incidents affecting their security (Article 14 (1) and (3) CRA). Reports are submitted via the single reporting platform to the CSIRT acting as coordinator and, at the same time, to ENISA. ENISA has now published registration and reporting guidelines for the platform; the operational launch is scheduled for 11 September. The reporting process is subject to a tight timeline: An early warning must be issued without undue delay, at the latest within 24 hours of the incident coming to light; a more detailed report within 72 hours; and a final report within 14 days of a remedial measure being provided (in the case of incidents: within one month of the 72-hour report). The decisive factor in determining when the reporting period begins is the manufacturer's "knowledge". According to the guidance, this is deemed the case when, following a prompt initial assessment, the manufacturer can conclude with reasonable certainty that the vulnerability is being actively exploited or that an incident has occurred – in other words, the clock does not start ticking at the first vague indication, but the initial assessment must not be delayed. At the same time, impacted users must be informed (Article 14 (8) CRA); however, the guidance expressly permits risk-based information limited to the impacted group, thereby leaving an important margin of discretion for the use of robotics in sensitive production environments.

Two points are often overlooked. Firstly, the scope: The reporting obligation applies as of the effective date to all products falling within the scope of the Act – including those placed on the market before 11 December 2027 and beyond the end of the support period (Article 69 (3) and Article 71 (2) CRA). The existing fleet is therefore not exempt: What matters is knowledge of active exploitation after 11 September 2026. Retroactive reporting is not required, however, if knowledge of active exploitation was already obtained before this effective date. By contrast, the obligation to handle vulnerabilities in accordance with Annex I Part II applies, in principle, to products placed on the market on or after 11 December 2027, as well as to existing products that undergo substantial modification from that date onwards. This results in two different timelines for reporting and rectification. Secondly, the preparation: Anyone wishing to be able to report a vulnerability on 11 September will, in practical terms, need functioning reporting channels in place beforehand (a "Coordinated Vulnerability Disclosure" policy, a point of contact), a triage process that turns a report into a robust initial assessment within hours, and clearly defined responsibilities between product security, IT and legal departments.

Scenario walkthrough: On Friday evening, a security researcher informs the AMR manufacturer that a vulnerability in the fleet management system's update service is being actively exploited. Friday evening is no time for complacency: The initial assessment must begin without undue delay. As soon as it confirms with sufficient certainty that the vulnerability is being actively exploited, the 24-hour period begins – even over the weekend. Within 72 hours, the detailed report follows, and once the patch or other remedial measure is made available, the 14-day period for the final report begins. However, this report only covers the manufacturer's perspective – the operator's perspective will be covered in the second post.

Updates, retrofits and the support period under the Cyber Resilience Act

Robots have a long lifespan, whilst software is constantly changing – the CRA resolves this imbalance using two concepts: the "substantial modification" and the support period.

According to Article 3 (30) CRA, a "substantial modification" occurs where a subsequent modification affects compliance with Annex I Part I or alters the intended purpose. If the substantially modified product is subsequently placed on the market, this may be regarded as a new placing on the market and may require a new conformity assessment. The criteria set out in the guidance is remarkably clear on this point: It is not the scope of the modification that matters, but the cyber risk profile – does the update introduce new attack vectors or attack scenarios, or does it increase the likelihood of occurrence or the potential damage of scenarios already known? The question then is whether all of this has already been taken into account in the risk assessment. Security updates are therefore not generally considered to be a substantial modification, provided they do not alter the intended purpose or introduce new cyber risks. Nor are new functions that the manufacturer has already anticipated in its risk assessment. The guidance provides the example of a production monitoring system whose control functions, activated at a later stage, were assessed from the outset. Applied to robotics: The retrofitted grasping "skill", which was provided for in the safety concept, is more likely to be seen as not constituting a substantial modification; the retrofitted teleoperation feature, which for the first time enables remote access to the motion control system, is, according to the above definition, a candidate for a substantial modification. 

Applied to control models that are continuously retrained, this means that it is not the retraining process itself that is the key factor, but rather the question of whether the updated model deviates from the assessed risk profile – a documentation task that must form part of the "MLOps" process.

There are two caveats to bear in mind here. Firstly, the dual definition: From 20 January 2027, the Machinery Regulation (Regulation (EU) 2023/1230) will introduce, in Article 3 (16), a separate, differently worded definition of "substantial modification" – the same modification to the same machine will then have to be assessed twice, according to two different criteria. Secondly, the operator's pitfall: Anyone who substantially modifies a product that has already been placed on the market and subsequently makes it available on the market may, under Article 22 CRA, become the manufacturer themselves; for existing products, the relevant CRA requirements will apply to substantial modifications as of 11 December 2027 (Article 69 (2) CRA). However, for an operator who is neither a manufacturer, importer or distributor, converting their own fleet exclusively for their own use is not sufficient for this purpose under Article 22 CRA. The situation is different under the Machinery Regulation: There, even a professional operator who substantially modifies a machine for their own use may assume the role of manufacturer. If, in our scenario, the supplier retrofits its existing fleet procured in 2024 with a third-party AI vision kit, both regulatory regimes must therefore be assessed separately. If the supplier subsequently makes substantially modified products available on the market in accordance with the CRA, it is subject to the manufacturer's obligations for the modified part or – if the product's overall cybersecurity is affected – for the product as a whole.

With regard to the support period, the guidance dispels a common misconception: The five-year period referred to in Article 13 (8) CRA is, in principle, a lower limit, not the standard. Only if the expected service life of a product is less than five years may the support period be correspondingly shorter – in the case of durable industrial robotics, this exception is unlikely to apply on a regular basis. A robot manufacturer that sets a standard five-year period will have to justify this to market surveillance authorities and customers; the end date must be specified at the time of purchase (at least the month and year, Article 13 (19) CRA). Although a substantial modification results in the support period being recalculated, it does not automatically restart the period. If the modification does not alter the factors determining the expected useful life – for example, if only the cloud backend is converted – the support period for the modified product may correspond to the remaining useful life originally specified. The gap between the regulatory minimum and the actual duration is therefore a matter for the contract: Commitments regarding updates beyond the CRA period, as well as escalation and end-of-life provisions, should be included in procurement and service contracts – a preview of one of the forthcoming instalments in this series on IT contract law.

CRA and the Machinery Regulation: conformity assessment without harmonised standards

How does the manufacturer demonstrate conformity? The robot as a whole is classified according to its core functionality; the categories of "important" and "critical" products (Annexes III and IV CRA) primarily cover certain cybersecurity, network and system components, as well as individual, particularly sensitive connected products. As a complete product, an AMR or cobot typically does not possess the core functionality of such a category and can therefore, in principle, be assessed under the internal control procedure – but care must be taken with regard to the product architecture: Anyone who also markets modules separately (such as the fleet manager as a standalone product) must classify each module according to its own core functionality. Robot control systems and communication modules warrant a case-by-case examination here; the blanket statement that machines are never covered by the annexes does not hold water.

Of greater practical significance is the situation regarding standards: As of August 2026, no harmonised standard for the CRA has yet been listed in the Official Journal of the EU. Manufacturers cannot therefore currently rely on the presumption of conformity under Article 27 CRA. According to standardisation mandate M/606, the first standardisation deliverables relating to the horizontal framework and the handling of vulnerabilities are expected by the end of August 2026; the product-specific standards for the categories set out in Annexes III and IV are due to follow by the end of October 2026. A presumption of conformity only arises once the relevant references have subsequently been published in the Official Journal. The robotics sector is already familiar with this situation from the Machinery Regulation, for which ISO 10218:2025 has not yet been harmonised – two parallel gaps in the presumption of conformity, in which the state of the art must be documented rather than presumed on the basis of a listed standard.

This makes it all the more valuable that the guidance explicitly confirms that EU type examination certificates issued under the Machinery Regulation in respect of its cyber requirements – protection against corruption and the safety of control systems (Annex III, sections 1.1.9 and 1.2.1 Machinery Regulation) – remain valid for the cyber risks covered therein, including for the purposes of the CRA, until 11 June 2028 at the latest (Article 69 (1) CRA). Anyone who structures their Machinery Regulation conformity assessment carefully from 2027 onwards will therefore not need to reassess and demonstrate the cyber risks it covers for the purposes of the CRA: Safety and security verification can be combined. The manufacturer remains responsible for the remaining CRA risks – such as vulnerability handling, minimising the attack surface and update mechanisms.

CRA and NIS-2: one cyber incident, two reporting chains

Back to the Friday evening scenario: Whilst the manufacturer reports the exploited vulnerability, the operator's intralogistics come to a standstill – the compromised update service has put the fleet into safe stop. The article on the German NIS-2 regime, due to be published in 14 days' time, will address the operator's reporting obligations; in it, we will also provide practical recommendations for implementing the CRA and NIS-2.

Cyber Resilience Act for robot manufacturers: what to do now

• CRA reporting obligations will be applicable as of 11 September 2026. Robot manufacturers must report actively exploited vulnerabilities and severe security incidents within strict time limits.
• For connected robots, the cloud backend may also form part of the product: It is particularly important to determine whether remote processing is necessary for product functions and whether the software was developed by the manufacturer or under its responsibility.
• The existing fleet is not automatically exempt from the reporting obligations: Different time limits apply to reporting and rectification.
• Vulnerability management must be operational before the effective date: In particular, manufacturers need channels for receiving reports, a rapid triage process and clear lines of responsibility between product security, IT and legal departments.
• Updates and retrofits may trigger a new CRA assessment: What matters is not merely the scope of a modification, but in particular whether it alters the assessed cyber risk profile or the intended purpose.
• The support period should correspond to the robot's actual service life: The five-year period specified in the CRA is, in principle, a lower limit and not a blanket standard.
• The CRA and the Machinery Regulation should be considered together: Safety and security verifications can, in some cases, be combined; at the same time, substantial modifications must be assessed separately under both sets of regulations.

Building the legal stack for Physical AI.

Editor's note: The information reflects the situation at the time of going to press (31 July 2026); Commission Guidelines C(2026) 5252 were available at that time in the English version approved on 27 July 2026 and will only be formally adopted once all language versions are available. Before any specific implementation takes place, the primary sources (EUR-Lex, ENISA, BSI) should be consulted.