Key points of this blog
The EU Machinery Regulation brings cybersecurity closer to machinery safety. From January 20, 2027, manufacturers must account for how software, data, connected devices, and foreseeable malicious attempts can affect safe machine behavior.
For robots and software-defined machines, cyber risk can become safety risk. When software, configurations, remote access, or control systems influence how a machine moves or responds, they become part of the safety lifecycle.
Physical AI security needs a lifecycle approach. Manufacturers need early risk assessment before shipment and runtime visibility during operation to help preserve safe machine behavior.
In September 2025, researchers disclosed UniPwn, a critical vulnerability affecting several Unitree quadrupeds and humanoids. Their paper, “Cybersecurity AI: Humanoid Robots as Attack Vectors,” reported that the vulnerability targeted the robots’ Bluetooth Low Energy (BLE) and Wi-Fi configuration interface, potentially allowing root-level takeover. The researchers also described it as “wormable,” meaning one compromised robot could scan for and attempt to compromise nearby Unitree robots.
UniPwn illustrates how an ordinary setup pathway can become a security flaw with physical consequences. When the affected system is a machine capable of moving, sensing, collecting data, and interacting with its surroundings, the consequences can extend beyond system compromise.
This is precisely the risk that the new EU Machinery Regulation brings into focus. By January 20, 2027, manufacturers must demonstrate how the software, data, connected devices, and foreseeable malicious attempts are addressed in machinery safety, not as a separate IT concern.
What the EU Machinery Regulation covers
The EU Machinery Regulation, or Regulation (EU) 2023/1230, replaces the older Machinery Directive 2006/42/EC and applies from January 20, 2027. Its core requirementremains the same with its predecessor: machinery and related products must meet essential health and safety requirements before they are placed on the EU market or put into service.
What changes is scope. The regulation explicitly brings cybersecurity closer to the product safety workflow, meaning risks that were once treated as IT, product security, or aftermarket concerns can now affect how manufacturers assess, document, and demonstrate machinery safety.
The following highlights are not an exhaustive list of obligations, but they are among the most relevant to cybersecurity and physical AI, where AI-enabled systems can directly influence how machinery behaves in the real world.
Protection against corruption (Annex III, section 1.1.9). Connected or remote devices must not lead to hazardous situations. Safety-relevant hardware, software, and data must also be protected against accidental or intentional corruption.
Safety and reliability of control systems (Annex III, section 1.2.1). Control systems must prevent hazardous situations and, where appropriate, withstand unintended external influences, including reasonably foreseeable malicious attempts from third parties.
Software identification and intervention evidence (Annex III, sections 1.1.9 and 1.2.1). Machinery must identify software necessary for safe operation, provide that information in an accessible form, and collect evidence of legitimate or illegitimate intervention in software or configuration. For safety software and autonomous systems, the Regulation also introduces retention requirements, including five years for tracing logs and safety software version data, and one year for safety-related decision-making data where required.
Autonomy and self-evolving behavior (Annex III, General Principles and section 1.2.1). Risk assessment must consider foreseeable hazards throughout the machinery lifecycle, including the intended evolution of fully or partially self-evolving behavior or logic. Control systems with varying levels of autonomy must be designed so they do not perform actions beyond their defined task and movement space. Where required, safety-related functional data must be recorded, and it must always be possible to correct the machinery or related product to maintain its inherent safety.
Key point: Machinery that fails to meet the regulation’s requirements may face market surveillance action, corrective measures, restriction, withdrawal, or recall. EU Member States are also required to set penalties for infringements.
From compliance requirement to operational risk
The requirements above point to a practical challenge for robotics and software-defined machinery: a machine may be assessed before release, but its risk profile can still change after shipment.
The UniPwn vulnerability makes this concrete. The flaw was tied to a setup pathway, not the robot’s mechanical design. For OEMs, the question is not only whether a robot cleared pre-shipment checks. It is whether they can identify which machines are affected, apply mitigations, monitor for abnormal behavior, and document what changed after the vulnerability was disclosed.
This is where cybersecurity becomes a lifecycle concern, not a pre-shipment gate.
| Phase | Security Focus | Practical Question |
| Before shipment | Risk assessment, vulnerability discovery, system and AI model risk validation, AI BOM, compliance readiness | What could make this machine behave unsafely before it reaches the field? |
| During operation | Runtime protection, telemetry, anomaly detection, monitoring, incident response | Is the machine still operating within intended boundaries? |
Table 1. How safety risks shift across the robotics lifecycle
For robots and AI-enabled machines, safety is not a one-time milestone. It must be maintained as software, configuration, connectivity, and operating conditions evolve.
What OEMs should prepare before the 2027 deadline
For teams building, securing, or operating robots, autonomous machinery, and software-defined machines, EU Machinery Regulation readiness means having a clear model for how safety, security, and evidence are managed across the machinery lifecycle.
While the list below is not an official compliance checklist, it is a practical readiness lens for organizations building, securing, or operating software-defined machinery.
Map safety-relevant digital systems. Identify which software, firmware, AI models, sensors, remote connections, update mechanisms, and control systems can affect how a machine moves, stops, perceives its environment, or responds to people. This mapping is the foundation for security and safety risk assessment, vulnerability handling, and compliance documentation.
Handle vulnerabilities and validate robot behavior before deployment. Identify AI model risks and software vulnerabilities that could affect robot motion, perception, control, or safety functions. Use AI model scans and vulnerability scans to prioritize weaknesses that may have physical safety impact, and use simulation or scenario-based review to evaluate how selected findings could influence robot behavior before deployment.
Protect control paths and runtime behavior. After deployment, continuously monitor the command paths, communication channels, control logic, AI behavior, exposed interfaces, update channels, and abnormal system activity that determine how robots move, stop, perceive, and respond. This helps teams detect malicious attempts, unauthorized changes, anomalous behavior, or operational risks before they affect physical safety.
Build traceability and compliance evidence. Align cybersecurity evidence with safety claims by maintaining software identification, SBOM or AI BOM, version history, vulnerability handling records, intervention evidence, configuration change records, safety software tracing logs, and safety-related decision-making data for autonomous systems. Where required, safety software intervention and version tracing must be retained for five years, while safety-related decision-making data for self-evolving or autonomous systems must be retained for one year.
Physical AI needs security that protects behavior
The EU Machinery Regulation makes one point harder to ignore: as machines become more connected, autonomous, and software-defined, their safety increasingly depends on the integrity of digital systems.
For physical AI, that is the real security challenge. It requires assessment before machines are shipped, and visibility while they are in service. It also requires capabilities that can support both sides of that lifecycle, from early risk assessment and vulnerability discovery to telemetry-driven monitoring and response.
Figure 1. A lifecycle approach to physical AI security: assess risk before shipment, then maintain visibility and resilience during operation.
This is where VicOne Radeis and Rthena can help bridge cybersecurity and physical safety. Radeis helps identify AI model risks, compliance gaps, and software vulnerabilities that could affect safety before deployment, while Rthena provides telemetry-driven visibility via purpose-built robotic security operations center (SOC) and runtime monitoring once robots are in operation. Together, Radeis and Rthena help robotics stakeholders identify risks earlier, monitor deployed systems more continuously, and maintain evidence when safety-relevant software, configurations, or behaviors change.
As physical AI moves from controlled environments into real-world operation, security must move with it, not as a layer added after shipment, but as a condition for safe and trusted machine behavior.
To learn more about Radeis, Rthena, and VicOne’s approach to securing autonomous robots and AI-enabled machines, contact VicOne.
For a deeper look at the cybersecurity risks and defense strategies shaping autonomous robotics, download VicOne LAB R7’s whitepaper “Securing the Rise of AI Robots: Cyber Risks, Real-World Threats, and Defense Strategies.”