How to Secure a Humanoid Robot Fleet: A 7-Step Checklist for 2026

Why do humanoid robot fleets need a security checklist?

Humanoid fleets need a checklist because their risk is now concrete and fleet-wide, not hypothetical. In September 2025, researchers disclosed UniPwn, a chain of flaws that gave attackers root on Unitree humanoids over Bluetooth and could spread automatically from one robot to the next, forming a botnet ¹. When one robot's compromise becomes every robot's compromise, ad hoc security is not enough.

A fleet also multiplies the consequences of a single weak design choice. UniPwn worked in part because affected units shared the same hardcoded cryptographic key ¹², so a secret extracted from one robot unlocked the rest. A checklist forces the structural questions early: does each robot have its own identity, is there a control in front of actuation, can you prove and contain what happens. We cover the humanoid threat picture in depth on our humanoid robot security page.

How do you give every humanoid robot a unique identity?

You give each humanoid a unique identity by rooting a cryptographic key in hardware on the robot and enrolling its public key as that robot's verifiable identity. The private key never leaves the device, and no two robots share one. From then on, any command claiming to come from a robot must carry a signature only that robot could produce.

This is step two of the checklist for a reason: it removes the shared-secret failure mode directly. A cloned or counterfeit robot is detected the moment it acts, because its signature verifies against no enrolled identity. Use a post-quantum scheme so a robot with a decade-long service life is not exposed to harvest-now-decrypt-later risk ⁷. The full mechanism is on our robot identity and attestation page.

How do you stop an unauthorized command from reaching the actuator?

You place a pre-actuation authorization gate between the decision and the actuator, and you make it deny-by-default. Every high-consequence command must pass four checks before motion: a valid per-robot signature, an enrolled and active robot, fresh dead-man liveness, and an action permitted by policy. Anything else is denied, and the denial is recorded.

This is the control that holds when other layers fail. If environmental prompt injection fools the robot's vision-language-action model into attempting an unsafe action ³, the gate still evaluates the resulting command and refuses it. The fix lives below the model, at the action boundary. This is the single highest-leverage item on the checklist; see the pre-actuation authorization gate for how it fails safe without adding latency to safety-rated control loops.

How do you verify a humanoid robot’s firmware before you trust it?

You verify firmware with remote attestation: the robot presents signed evidence about its running build and policy, and you appraise it against known-good reference values before granting privileged actions. If the build is tampered, downgraded to a vulnerable version, or its policy has drifted, the robot is quarantined. This follows the IETF RATS model and satisfies the integrity expectations of standards like IEC 62443.

Firmware attestation matters on a checklist because a robot you trusted yesterday can be a different robot today after an update or an intrusion. Continuous attestation makes trust a live measurement, not a one-time assumption, and it is exactly the kind of evidence ISO 10218-1:2025 now expects as it folds cybersecurity into robot safety ⁵⁶. See RATS firmware attestation.

How do you contain a compromised humanoid without halting the fleet?

You contain a compromised humanoid by revoking its cryptographic authority, so the gate denies its commands fleet-wide, rather than shutting down operations. A signed dead-man or kill credential bounds a captured robot in seconds, and because containment is per-robot, the rest of the fleet keeps running. This turns an incident from an outage into an isolation event.

This is the last two steps of the checklist, and they are what make the plan operable. An M-of-N authorization on the kill path prevents a single attacker or insider from abusing it, and the tamper-evident provenance log gives you a verifiable record for the post-incident review and for any auditor or insurer. Detection and network security remain the base; this adds the containment and evidence they cannot.

What does a humanoid fleet security checklist look like?

Here is the full seven-step checklist as an interactive tracker. Work down it in order, because each step reduces the risk that the next attack class succeeds, and the earlier steps remove the failure modes that made 2026's headline exploits possible. Check off what you have, see your progress, and download the list to share with your team. It complements ROS 2, SROS2, and DDS rather than replacing them.

Frequently asked questions about securing a humanoid robot fleet

References

1. IEEE Spectrum. Unitree Robot Hack: What You Need to Know. Oct 2025. spectrum.ieee.org/unitree-robot-exploit
2. Help Net Security. Humanoid robot found vulnerable to Bluetooth hack. Oct 2025. www.helpnetsecurity.com/2025/10/16/unitree-g1-humanoid-robot
3. UC Santa Cruz Newscenter. Misleading text in the physical world can hijack AI-enabled robots. Jan 2026. news.ucsc.edu/2026/01/misleading-text-can-hijack-ai-enabled-
4. International Organization for Standardization. ISO 10218-1:2025 Robotics, Safety requirements, Part 1: Industrial robots. 2025. www.iso.org/standard/73933.html
5. The Robot Report. ISO 10218 industrial robot safety standard receives major overhaul. 2025. www.therobotreport.com/iso-10218-industrial-robot-safety-sta
6. National Institute of Standards and Technology. NIST Releases First 3 Finalized Post-Quantum Encryption Standards. Aug 2024. www.nist.gov/news-events/news/2024/08/nist-releases-first-3-