NIS-2 and robotics: Obligations for operators of networked robots
Under the German NIS-2 regime, connected robots can impose new requirements on companies regarding IT security, risk management and reporting processes. If a company is designated as a "particularly important entity" ("besonders wichtige Einrichtung") under the German IT Security Act (BSIG), robot systems, fleet servers and remote maintenance access must also be included in its cyber risk management framework. In the event of a significant security incident, reporting obligations may also take effect – in addition to the manufacturer's obligations under the Cyber Resilience Act (CRA). Companies therefore need to consider NIS-2 and CRA together both organisationally and contractually and align incident response processes with both reporting chains.
This is the second instalment on the topic of IT security and physical AI in our "Robotics and Physical AI" series. While Part 1 dealt with the manufacturers' perspective under the Cyber Resilience Act, we are now shifting our focus to the NIS-2 regime and the operators' perspective as well as specific recommended actions for manufacturers and operators to take.
CRA and NIS-2: One cyber incident, two reporting chains
In our first article on IT security and physical AI, we examined the obligations under the Cyber Resilience Act that apply to the manufacturer when a vulnerability in their product is actively exploited. In this article, we switch to the operator's perspective and examine the obligations under the German NIS-2 regime. In the following the term "operator" refers to a particularly important entity ("besonders wichtige Einrichtung") in accordance with section 28 German IT Security Act (BSIG) that uses robotic systems in the course of its activities. To conclude we will devise specific recommendations for manufacturers and operators based on the two legal frameworks.
Returning to the Friday evening scenario described in the first article, while 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. This means the incident also triggers the second reporting chain: The operator examines whether a significant security incident within the meaning of the NIS-2 regime has occurred and, if so, reports it to the joint reporting office for the German Federal Office for Information Security (BSI) and the German Federal Office of Civil Protection and Disaster Assistance (BBK). A security incident is considered significant if it causes or can cause serious operational disruption or financial losses for the entity or significant damage to other persons (section 2 no. 11 German IT Security Act (BSIG). In the example scenario therefore, the stoppage in the overall intralogistics is a strong indicator but not an automatic one. The decisive factors are the duration, scope and economic impact of the disruption in particular. If the outage stops production or threatens to cause significant losses, there is a strong case to be made that this is a significant security incident that must be reported.
If such an incident has occurred, the first report is to be made without undue delay, within 24 hours after discovery at the latest, another report is to be made within 72 hours and the final report is generally to be made within a month. This means that in this scenario, two regimes apply with different parties reporting on different occurrences: The manufacturer reports the actively exploited vulnerability in its product in accordance with the CRA while the operator reports the significant security incident and its impact on operations in accordance with the German IT Security Act (BSIG). The deadlines are similar, but the recipients and content are not – by depicting both chains in the same incident response plan and ensuring by means of contracts that all sides are informed, companies can submit their reports faster and consistently. Depending on the circumstances, further reporting obligations may apply. If the cyber incident results in a personal data breach for example, it must also be checked whether to issue a notification under Article 33 General Data Protection Regulation (GDPR).
NIS-2: Security as an organisational obligation of the operator
The NIS-2 Directive has been transposed into German law since 6 December 2025 (German IT Security Act (BSIG), as amended). In addition to sectors such as energy, transport and health, the directive also explicitly covers large parts of the manufacturing sector: Companies operating in sectors such as mechanical engineering and manufacturing of electronic products, motor vehicles, motor vehicle parts and medical devices are generally considered important entities ("wichtige Einrichtungen") if the statutory thresholds are met. This affects robotics in two ways: Depending on its activities, the robot manufacturer may itself be classified as an entity within the meaning of the act – and so may its customer, the automotive supplier from our scenario. All those affected must register, implement appropriate, proportionate and effective risk management measures that are in line with the state of the art and report incidents.
When it comes to the use of robots, risk management means above all that the fleet must be included in the risk assessment. Robots, fleet servers, charging infrastructure and remote maintenance access points are operational technology ("OT") and must be taken into account in risk management; in practice this includes in the asset register, in network segmentation, in the authorisation scheme and in the incident response plan. A rollout based on the assumption that "the manufacturer will ensure the robots are secure" fails to take account of the legal situation, as the NIS-2 obligations fall on the operator, regardless of how well the manufacturer fulfils its CRA obligations. Remote maintenance access as described in our scenario is the classic attack vector: It requires a dedicated access and record-keeping framework and is a supply chain issue.
This is because the second key focus of the NIS-2 framework is the supply chain: Entities must take the security of their supplier relationships into account. In practical terms this translates into procurement requirements for the robot supplier – CRA readiness or conformity (where already applicable), commitments to provide updates and support throughout the robot's actual useful life, defined reporting channels within hours and access rules for remote maintenance. The same logic with which the manufacturer is expected to obtain NIS-2 evidence from the cloud provider in accordance with the guidelines continues throughout the supply chain: The operator must obtain from the manufacturer evidence of its CRA compliance status and – once applicable – CRA conformity. Security is becoming part of the contract chain.
Finally on an individual level, senior management must implement the risk management measures, monitor their implementation and undergo regular training (section 38 German IT Security Act (BSIG), as amended); if they culpably breach these duties, they are liable to their entity in accordance with the rules of corporate law applicable to the respective legal form. Management and supervisory responsibility cannot be fully delegated in this context. This is accompanied by fines of up to EUR 10 million for particularly important entities and up to EUR 7 million for important entities; where aggregate worldwide turnover exceeds EUR 500 million, fines of up to 2 % or 1.4 % respectively of total turnover may apply instead. If a director of a supplier covered by the NIS-2 Directive operates forty networked robots and the fleet is not included in the risk management process, they have a significant individual issue to address.
CRA and NIS-2 in robotics: Recommended courses of action for companies
Below the obligations identified for CRA and NIS-2 are translated into specific recommendations for action. This list is intended to provide illustrative examples and is not exhaustive.
For manufacturers:
- Make sure by 11 September that it is possible to report incidents. In practical terms it is best to start now establishing channels for reporting vulnerabilities ("Coordinated Vulnerability Disclosure" policy, point of contact), performing triage with an initial assessment within hours, clarifying competences between product security, IT and legal departments, preparing for registration on the Single Reporting Platform and testing the internal reporting process in line with ENISA guidelines. This requirement also applies to the existing fleet in the field.
- Define and document the product scope right up to the cloud. Use the guidelines' three-question test to identify which backend services constitute remote processing (including SBOM and risk assessment) and which third-party services are treated as components or dependencies – including the necessary evidence for components and cloud dependencies.
- Set up change governance. Check every update and every model retraining against the assessed risk profile and document the classification; from 2027 take the second inspection required under the Machinery Regulation into account and organise any necessary type examination in such a way that the cyber evidence for the respective risks covered can also be used under the CRA (Article 69 (1) CRA).
- Calculate the support period honestly. Use the expected useful life rather than a flat rate of five years; make the end date transparent; address any difference between the regulatory support period and the robot's actual service life in the contract.
For operators:
- Clarify the scope of application and include the fleet in it. NIS-2 scope check; take robots, fleet servers and remote maintenance access points into account in risk management – in practice for example in the asset register, network segmentation and incident response; complete the required registration on the portal of the German Federal Office for Information Security (BSI) and keep it up to date; and test the reporting process to the joint reporting office for the German Federal Office for Information Security (BSI) and the German Federal Office of Civil Protection and Disaster Assistance (BBK) from both technical and organisational perspectives.
- Depict both reporting chains in a single plan. Who reports what to whom and by when – and how do the manufacturer and operator hear from each other? Include notification requirements in service and maintenance contracts.
- Use procurement as a security tool. CRA compliance status and (where already applicable) CRA conformity, commitments to provide updates throughout the useful life, reporting deadlines and remote maintenance rules as contractual requirements; in the case of retrofits, check in advance whether manufacturers' obligations under the CRA or the Machinery Regulation are triggered.
- Involve senior management. Document the implementation and monitoring of measures and provide evidence of training – operational tasks may be delegated, but responsibility for management and oversight remains with the senior management.
Outlook: Security is becoming a lifecycle, not a feature
11 September 2026 is just the beginning. The Machinery Regulation, setting out the cyber requirements for machinery, will come into effect on 20 January 2027, followed by the full range of CRA obligations on 11 December 2027. With regard to high-risk AI in machines, the Digital Omnibus has now adopted a sector-dependent approach: The relevant AI requirements are to be incorporated into the Machinery Regulation; the delegated legal acts envisaged for this purpose are to apply from 2 August 2028. Until then the CRA will serve as a central, horizontal cybersecurity foundation for the robotics stack; the Commission has announced further guidance on the interaction between the CRA and the AI Act as well as other relevant product legislation. The direction of travel is clear: In the case of physical AI, security is not a product characteristic established by the CE marking, but rather a lifecycle comprising risk assessment, updates, reporting and support – for both the manufacturer and the operator. CMS assists manufacturers, integrators and operators at precisely this interface: from product architecture through procurement and service contracts to incident response and reporting processes.
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.
Related Experts
