EU Machinery Regulation makes cybersecurity part of machine safety

At a glance

What this is: This is VicOne’s analysis of how the EU Machinery Regulation turns cybersecurity into a machinery safety requirement for robots and other software-defined machines.

Why it matters: It matters because IAM, device trust, remote access, and runtime monitoring now influence whether a machine remains safe after shipment, not just whether it passed pre-release checks.

Context

The core governance gap is that machine safety has often been treated as a pre-shipment engineering question, while cybersecurity has been handled as an adjacent IT concern. For robots and software-defined machines, that separation no longer holds because software, connectivity, and configuration can change how physical systems behave in the field.

The EU Machinery Regulation closes that gap by requiring manufacturers to account for software, data, connected devices, and foreseeable malicious attempts as part of the safety lifecycle. For teams building connected machinery, the practical question is whether they can prove safe behaviour before release and sustain it during operation.

Key questions

Q: What is the main failure mode when robotics security is treated separately from safety?

A: The main failure mode is assuming that safe hardware and validated software remain safe after shipment even when access paths, configuration, or models change. In connected machines, the control gap is lifecycle drift. Once the system is in the field, unsafe behaviour can emerge from changed software or remote influence, so safety assurance must include post-deployment evidence and monitoring.

Q: Why does the EU Machinery Regulation change how teams think about cybersecurity risk?

A: It changes the risk model because cybersecurity can now affect whether a machine meets its safety obligations. That means teams must assess software, data, connectivity, and foreseeable malicious attempts as part of the safety lifecycle, not as separate IT issues. The practical effect is stronger evidence requirements before shipment and stronger visibility after deployment.

Q: What are the signs that a robot is no longer operating within its intended safety boundary?

A: Warning signs include unexpected changes in command paths, unusual update activity, altered configuration, anomalies in perception or movement, and behaviour that no longer matches the validated operating envelope. In physical AI, those symptoms can appear even when the hardware still works. Teams should treat behavioural drift as a security signal, not just a functional fault.

Q: Who is accountable when a connected machine becomes unsafe after deployment?

A: Accountability should sit with the organisation that defines, ships, and operates the machine lifecycle, with security, engineering, and safety functions sharing evidence and control ownership. The regulation makes this a governance issue, not just a technical one. Teams need clear responsibility for change tracking, remote access, runtime monitoring, and incident response across the full lifecycle.

Technical breakdown

How software and connectivity become safety-relevant controls

Once a machine can be updated, remotely accessed, or influenced by external software, cybersecurity affects its motion, stopping behaviour, perception, and response. That means the attack surface is not just the operating system or network channel, but any control path that can alter safe behaviour, including configuration interfaces, update mechanisms, telemetry, and connected devices. In robotics, a compromise can change what the machine sees and how it reacts without breaking the hardware itself. The regulation effectively treats those digital dependencies as part of the safety case, not as separate infrastructure concerns. See the Device and IoT Identity Guide.

Practical implication: Map every software and access path that can influence safe behaviour and include it in the safety case.

Why pre-shipment checks are no longer enough

A machine can pass factory checks and still become unsafe later because its software, credentials, models, or connectivity change after deployment. That is why lifecycle risk assessment matters: the relevant question is not only whether the product was safe at shipment, but whether it remains safe as updates, remote access, and operating conditions evolve. In the article’s example, a setup-path vulnerability could lead to root-level takeover and then physical risk. Lifecycle assurance therefore has to combine vulnerability discovery, configuration governance, and post-deployment monitoring. See the Remote Access Identity Guide.

Practical implication: Reassess robot risk after every material software, access, or configuration change.

What runtime visibility has to detect in physical AI

Runtime monitoring for physical AI must watch for abnormal command paths, unexpected configuration changes, suspicious update activity, and behaviour that diverges from intended movement or decision boundaries. This is different from ordinary endpoint monitoring because the outcome of concern is not just compromise, but manipulated perception or control that affects the physical world. For self-evolving or autonomous systems, evidence retention also matters because investigators need version history, intervention records, and decision logs to explain what changed and when. Without that traceability, safety claims become hard to defend after an incident.

Practical implication: Instrument the operational layer for behaviour anomalies, not just technical compromise signals.

Threat narrative

Attacker objective: The attacker aims to gain root control of a robot and then spread compromise to nearby machines in a way that can affect physical behaviour.

1. Entry occurred through a Bluetooth Low Energy and Wi-Fi configuration interface exposed during device setup, not through the robot’s mechanical systems.
2. The reported UniPwn flaw could enable root-level takeover, giving an attacker control of software behaviour and an opportunity to move from access to device compromise.
3. Because the issue was described as wormable, a compromised robot could scan for nearby Unitree robots and attempt to spread the attack across adjacent devices.
4. The end state is unsafe machine behaviour at physical scale, where cyber compromise becomes a safety problem rather than a purely digital one.

Breaches seen in the wild

• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cybersecurity has become part of the machinery safety case, not a separate control domain. The regulation changes the governance question from whether a robot is secure in isolation to whether digital systems can alter its safe behaviour in service. That matters because software, configuration, and remote access now sit inside the safety lifecycle, which means safety teams and security teams must share evidence and decision rights. Practitioners should treat this as a boundary shift, not a wording change in compliance.

Physical AI creates a new assurance problem: the machine can look healthy while behaving unsafely. A robot may report that cameras, controllers, and models are functioning while its perception or decisions are being manipulated. That means traditional fault detection is not enough, because the control failure is behavioural, not mechanical. AI security maturity needs to extend from model assessment to runtime behaviour validation, or assurance will stop at the wrong layer.

Safety lifecycle drift: the failure mode is assuming that pre-shipment validation covers the machine’s full risk window. Once a robot is connected, updated, or remotely managed, the operative security question becomes whether changes are still consistent with the original safety claim. That is why evidence collection, version traceability, and intervention records are not paperwork extras. Practitioners should govern safety as an evolving state, not a one-time certification.

Remote access and device trust are now safety controls as much as access controls. If a connected robot can be reached through weak remote pathways or unmanaged devices, the access problem becomes a physical safety problem. This is where identity governance intersects with robotics: service access, machine trust, and update authority all need tighter scope and better traceability. Teams should align connected-machine access with the same discipline they use for privileged access and device identity.

The market signal is moving toward operational security for physical systems, not just static product compliance. Manufacturers will need to show that they can detect unsafe behaviour after release, preserve evidence, and respond to changes over time. That pushes robotics security toward continuous monitoring, safety-linked telemetry, and stronger lifecycle governance. Practitioners should expect procurement and assurance to demand runtime proof, not just pre-market documentation.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Safety evidence is becoming a living control, not a filing exercise. For robotics programmes, version history, intervention records, and runtime logs now support both compliance and incident reconstruction. That shifts assurance from annual review to continuous state management, which is a material change for teams that previously treated product certification as the finish line.

Identity governance now reaches into physical systems. Remote access, update authority, and device trust can all alter machine behaviour, so machine identity and privileged access controls become part of operational safety. Teams that already govern high-risk access should extend those patterns to connected robots, especially where third-party maintenance or fleet administration is involved.

For practitioners

• Map every safety-relevant digital dependency Identify the software, firmware, AI models, sensors, remote connections, update paths, and control interfaces that can change how the machine moves, stops, perceives, or responds.
• Assess robot risk before deployment Combine vulnerability scans, AI model review, and scenario-based validation to test whether selected weaknesses could change physical behaviour before shipment.
• Monitor runtime behaviour continuously Track command paths, communication channels, exposed interfaces, update channels, and anomalous activity after deployment so unsafe changes are visible before they affect physical safety.
• Build traceability into the safety evidence set Retain software identification, version history, vulnerability handling records, configuration changes, safety software logs, and decision data so changes can be traced back after deployment.

Key takeaways

• The article’s central point is that machine safety now depends on controlling digital paths that can alter behaviour after shipment.
• The example of a setup-path vulnerability shows why post-deployment monitoring matters as much as pre-release validation.
• Teams that cannot trace software, access, and configuration changes across the lifecycle will struggle to defend safety claims under the new regulation.

Related NHI Mgmt Group resources: Remote Access Identity Guide · Device and IoT Identity Guide · AI Risk Assessment Guide

Key terms

• True AI: AI that materially changes an operational security outcome, not just the language used to describe a product. In practice, the term applies when a model improves detection, prioritisation, or response in ways that can be measured and defended.
• Safety Lifecycle: The safety lifecycle is the full sequence from design and validation to deployment, operation, monitoring, and change management. In connected machinery, it must include cybersecurity evidence because software, access, updates, and configuration changes can change the system’s real-world behaviour after shipment.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.
• Runtime telemetry: Observation of what a system actually does while it is executing. In agentic CI/CD, this means seeing which commands, files, tools, and credentials an agent touched so security teams can detect misuse that static workflow review will miss.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions that support trustworthy operations.