Humanoid robots are beginning to move from laboratory demonstrations to industrial use. The International Federation of Robotics’ 2025 position paper on humanoid robotics identifies manufacturing, automotive, logistics, and warehousing among the most credible application areas. It also warns that safety challenges and uncertain mass adoption still separate ambition from reality. Manufacturing and logistics are therefore suitable proving grounds. They offer real tasks, close interaction with people, and enough structure to expose weaknesses before robots enter less predictable settings such as healthcare.
A robot can carry cameras, proximity sensors, inertial measurement units (IMUs), actuators for joint positioning, and powerful AI models yet still react unsafely. Information can arrive late or lose priority to the task already in progress. More sensing increases awareness only when the robotic system can judge whether its perception remains trustworthy and convert that judgment into safe motion.
That judgment can be undermined by faults inside the machine or interference from outside it, making functional safety and cybersecurity inseparable design concerns.
Trusted autonomy demands safety and security together
Functional safety and cybersecurity developed as separate disciplines. One addresses faults and unintended behaviour inside a system, while the other addresses external attempts to exploit it. In a moving robot, however, the physical outcome can be identical.
A degraded sensor, a disrupted communication link, or a manipulated data stream can each cause the robot to act on information that isn’t trustworthy. The real risk lies in how that unreliable information moves between modules. Cameras, processors, networks, controllers, and actuators must exchange trusted data and respond predictably when confidence falls. Software can detect and manage some failures, but it depends on resilient hardware, secure communications, and clearly defined module behaviour to contain them. Functional safety and cybersecurity therefore must be engineered across the entire robotic architecture.
Humanoid robots are built from interdependent modules that span sensing, compute, connectivity, control, and software, often developed by different companies. Resilience therefore depends on trusted interoperability – each module must communicate its status clearly, recognise when its information has become unreliable, and respond predictably when another part of the system is compromised.
Regulators are already moving in this direction. The European Commission’s latest guidance on the Cyber Resilience Act (CRA) confirms that its main obligations apply from 11th December 2027, with reporting obligations beginning on 11th September 2026. The CRA imposes lifecycle cybersecurity requirements on connected hardware and software. Treating security as a late-stage product feature would therefore be reckless. Wireless links, digital interfaces, remote maintenance channels, and software updates all connect, directly or indirectly, to physical motion.
Trusted autonomy requires a common safety and security architecture from the first design decision. Separate compliance teams can’t rescue a system whose threat model ends at the network boundary.
Once safety and security are treated as a single design responsibility, attention must turn to whether the entire chain from sensing to physical action can respond correctly and in time.
Safety spans the full journey from perception to motion
A sensor that detects a person doesn’t prove that the robot is safe. The data must reach the correct processor, the decision logic must select the correct response, the command must reach the controller, and the actuator must execute it quickly enough.
Latency belongs in the safety case. Recent academic research on low-latency perception-compute-control architectures treats total signal delay as part of the minimum separation needed to stop safely. A late safety command has the same practical value as no command.
Context also matters. Imagine a humanoid robot carrying a hot or heavy component when a worker steps into its path. An abrupt stop or dropped load could create a second hazard for the human worker. The machine may need to reduce speed, alter its path, place the object down or execute a controlled stop. Recent work on humanoid ‘safe-stoppability’ shows that abruptly cutting power to a biped can trigger a fall and secondary collisions. The wider lesson is that an emergency response must reflect the robot’s physical architecture, current motion, and payload rather than rely on a universal stopping action.
To deliver that response consistently, the robot must recognise when its own inputs are deteriorating and act before uncertainty becomes danger.
Robots must detect uncertainty locally
The most dangerous failures are gradual, plausible, and difficult to detect. A robot can continue operating while its understanding of the surrounding environment becomes steadily less reliable.
Degrading perception: cameras can become partially obstructed, calibration can drift, and sensors can produce corrupted data that still appears credible. Continuous plausibility checks and comparisons between different sensor inputs are essential to identify when the system’s perception has deteriorated.
Conflicting information: when modules provide inconsistent readings, the robot needs explicit confidence thresholds, and a predefined degraded mode. Depending on the risk, that could mean reducing speed or force, restricting movement, or entering a controlled safe state.
Delayed response: safety decisions that depend entirely on a central processor leave too much room for latency and communication failure. A hand that regulates grip pressure, or a joint that detects unexpected resistance should be capable of performing time-critical protective actions locally.
The system should respond according to the risk created by unreliable information, whether caused by wear, data corruption, communications interference, or a cyberattack. Those local safeguards only become trustworthy when they are designed into every module and validated across the robot as a complete system.
Prove resilience across the system
Designing resilience into individual modules provides the foundation, but integration is where hidden assumptions collide. A camera may detect a hazard correctly and a joint controller may perform exactly as designed, but delays or conflicting priorities between them still produce an unsafe movement.
Evidence must therefore trace a hazard from detection through decision and execution to the robot’s final physical state. Testing should show that the complete machine reaches a safe outcome when inputs conflict, communications are delayed or information is compromised.
Humanoid robots will earn their place in shared workplaces through predictable behaviour under uncertainty. Confidence, timing, local control, and system-level evidence will determine whether people are genuinely safe. The safest robot isn’t the one with the most sensors; it is the one that knows when its perception can no longer be trusted and can still bring motion to a safe state.
