Published Date By Mouser Technical Content Staff, based on an interview with Konstantin Grushko and Dr. Víctor Mayoral-Vilches Published October 6, 2026 At BMW Group Plant Spartanburg, a Figure 02 humanoid robot placed sheet-metal parts on a welding fixture under an 84-second cycle-time requirement. During the deployment, the Figure 02 handled more than 90,000 parts and contributed to the production of more than 30,000 BMW X3 vehicles. [1] At a GXO Logistics fulfillment center, Agility Robotics’ Digit robots move totes from mobile robots to conveyors. [2] These deployments show that humanoid robots are beginning to find practical roles in manufacturing and logistics. Deployment at scale, however, requires evidence that the robots will remain safe in the face of network failures, software changes, attacks, and recovery events. Cybersecurity and regulation are central to that evidence because a new task, software update, or newly discovered threat can alter the risks identified in the robot’s original safety assessment. Konstantin Grushko, co-founder and chief executive officer (CEO) of Aleph Robotics, evaluates humanoid robot platforms for pilot projects. He looks beyond whether a robot can complete a task under normal conditions. “I want to see the robot repeat a useful task under realistic conditions, including when something goes wrong,” he says. “How often does someone intervene? How long does recovery take?” His questions focus on dependable operation throughout the robot’s working life. In this article, we explore the cybersecurity and regulatory challenges of industrial humanoid robots, including safe responses to faults, responsibility when a robot joins a workflow, and the evidence needed to maintain safety and compliance as software, tasks, and threats change. Why Cybersecurity Becomes a Safety Issue A humanoid robot combines sensors, artificial intelligence (AI) models, control software, fleet management tools, and remote connectivity. Connecting these components and resources are frameworks such as Robot Operating System version 2 (ROS 2). The open-source framework’s middleware is the communication layer that carries data and commands among sensors, planning software, and controllers. A weakness anywhere in this chain can expose data, disrupt operations, allow unauthorized access, or change how the robot moves. These consequences make cybersecurity a physical safety issue as well as an information security issue. Dr. Víctor Mayoral-Vilches, Chief Scientific Officer and founder of Alias Robotics, describes the central problem as implicit trust inside the robot. In physical AI, an AI system selects actions that a machine carries out in the physical world, and such an AI plan may pass directly to the control system as a command. “In physical AI,” he says, “generated intent becomes physical authority; encrypting that communication does not make the resulting action safe.” Encryption protects a command while it travels between systems. It can prevent outsiders from reading or altering the message in transit, but it does not assess what the command will make the robot do. Therefore, a faulty or manipulated AI planner can issue a properly encrypted and authenticated command that sends the robot toward the wrong object or into an occupied area. An independent safety system must check the requested action against limits on speed, force, workspace, payload, and proximity to people before allowing it to proceed. In 2025, researchers disclosed weaknesses in Bluetooth® Low Energy provisioning and wireless configuration that could be combined to run commands with root privileges on affected Unitree robots. [3] The researchers determined that a provisioning fault gave attackers root-level control over the robot’s operating system. With that access, an attacker could read data, change configurations, install software, disrupt operations, or try to reach control functions and other connected systems. Manufacturers can reduce this type of risk by separating software components, limiting which predefined capabilities each component may activate, and checking commands through an independent safety system. Mayoral-Vilches warns that fleet management software can extend a single compromise across many robots. Fleet software assigns work, coordinates routes, and may distribute updates across a deployment. A compromised fleet account or server could send a harmful task or faulty update to several machines. Due to this risk, each robot needs to verify fleet commands locally before executing them. Security testing must cover the full path from perception to action. Testers can feed the robot altered camera images, corrupted sensor readings, adversarial instructions, misleading context, or spoofed responses from connected tools. They can then observe how the planner interprets the input, which skill it selects, and whether the safety system catches the resulting action. “A manipulated observation can make a permitted skill act on the wrong object without violating a motion limit,” Mayoral-Vilches cautions. That is, the robot stays within its permitted range of motion and still performs the wrong action. To stay ahead of these security and safety issues, Grushko recommends asking suppliers practical questions before deployment: “Who can access or control the robot remotely? What data leaves the site, and who can use it? Can we approve updates before installation? What happens if connectivity fails? And when there’s an incident, who responds and how quickly?” Planning for a Safe Stop Any successful industrial installation of a humanoid robot requires that it stop safely when its control system or network fails. This must be done the right way, though. Cutting the power may cause a standing biped to fall when its motors stop supporting it. Agility Robotics reports that an earlier version of Digit could fall if communication with its external safety controller were lost. Later versions added an onboard controller and a controlled stop before power was removed. [4] Safe stopping also requires a human response. Drawing on his search-and-rescue and offshore experience, Grushko says “[the concept of] ‘someone will take over’ needs a named person, training, and a practiced procedure.” Workers also need to know when they can approach the robot and who can authorize a restart. Dividing Responsibility Integrating a humanoid robot into a factory or warehouse workflow means deciding how it receives assignments, where it moves, how it handles parts or totes, and when workers can intervene. Those choices affect the robot’s safety and involve its manufacturer, the integrator, and the site operator. “Gaps appear when everyone assumes someone else is responsible,” Grushko says. His expectation is that the manufacturer explains the robot’s limits, the integrator validates the application, and the operator maintains the agreed working conditions. Changes, incidents, and restarts also need named owners. The International Organization for Standardization (ISO) and the American National Standards Institute (ANSI) are developing documentation for dynamically stable industrial mobile robots, a category that includes many humanoid robot designs. Such standards include ISO/CD 25785-1 and ANSI/A3 Technical Report (TR) R15.108. For factory humanoid robots, ISO 10218 provides part of the safety framework. Part 1 covers the industrial robot, while Part 2 covers its integration into a specific application, including commissioning, operation, and maintenance. [5] These standards help divide responsibility between the manufacturer and the integrator. The manufacturer defines the platform’s limits and safety functions, while the integrator must validate the tool, task, work area, and interaction with people. Changing a gripper, payload, route, or speed can change the risk and require another assessment. Regulation Requires Life Cycle Evidence The European Union provides the clearest example of these issues becoming legal requirements. Regulation (EU) 2023/1230, which takes effect on January 20, 2027, requires safety-related software and data to be protected against accidental or intentional corruption. [6] Since September 11, 2026, the EU Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities and severe security incidents. An early warning is due within 24 hours, and full notification within 72 hours. [7] The law’s broader product-security and vulnerability-management requirements apply starting December 11, 2027. [8] The EU AI Act may also apply to humanoid robots. AI used as a machinery safety component can be classified as high risk when the product requires review by an independent conformity assessment body. Requirements under this act include risk management, logging, human oversight, cybersecurity, and post-market monitoring, and this takes effect in August 2028. [9] These rules extend safety and security responsibilities beyond the initial sale. Manufacturers and operators must still determine which software, tasks, and threats require reassessment. For Grushko, a software change is a clear trigger. “A software change can change the robot’s movements and risks, even though the hardware looks identical,” he clarifies. In these instances, the deployer must identify the change, repeat relevant safety checks, and determine whether the existing assessment still applies. Mayoral-Vilches asserts that threats can change while the robot remains the same. “A robot can become exploitable without changing a single line of code, because the adversary’s capabilities have changed,” he says. Therefore, security reviews must respond to both software updates and new threats. Requirements for Scalable Deployment The first industrial deployments show that humanoid robots can complete useful tasks. Still, available deployment records have not yet established how consistently these machines will recover from failures, withstand new attacks, or remain compliant after repeated changes to software and tasks. About the Interviewees Dr. Víctor Mayoral-Vilches is Chief Scientific Officer and Founder of Alias Robotics. He has spent more than a decade researching and testing robot cybersecurity, with a focus on physical AI, connected robotic systems, and preventing cyber compromises from becoming physical safety incidents. About the Author Mouser, founded in 1964, is a globally authorized distributor of semiconductors and electronic components for over 1,200 industry-leading manufacturer brands. We specialize in the rapid introduction of the newest products and technologies targeting the design engineer and buyer communities. Mouser has 28 offices located around the globe. We conduct business in 23 different languages and 34 currencies. Our global distribution center is equipped with state-of-the-art wireless warehouse management systems that enable us to process orders 24/7, and deliver nearly perfect pick-and-ship operations. Show previous Show next