Humanoid Robot Security: Attested Identity and Action Control for Humanoid Fleets

Why are humanoid robots a target in 2026?

Humanoid robots are a 2026 target because a large, safety-critical fleet is arriving faster than its security is maturing. The category moved from demos to volume production this year: industry trackers put humanoid shipments in the tens of thousands of units across more than 140 manufacturers, with programs from Figure, Tesla (Optimus), Unitree, 1X, and others pushing units into warehouses, factories, and pilot deployments. When a new class of connected machine scales this quickly, the attack surface scales with it.

Three properties make humanoids especially attractive to an attacker:

• They act in the physical world. Unlike a compromised server, a compromised humanoid can move, lift, push, and operate near people. The consequence of an unauthorized action is physical, not just informational.
• They are richly connected. Humanoids ship with Wi-Fi, Bluetooth, cellular, and cloud links for teleoperation, updates, and fleet coordination, which is many independent ways in.
• They run manipulable AI. Vision-language-action (VLA) models turn what a robot sees into what it does, which means the perception channel itself can be weaponized against the robot.

Information gain: the humanoid threat is not primarily about any single clever exploit. It is a timing problem. A decade of connected-device security lessons is being compressed into a fleet that is being manufactured right now, often by companies whose core competency is locomotion and manipulation rather than adversarial security. That gap between deployment speed and security maturity is the real vulnerability, and it is why the first public humanoid exploit spread as easily as it did. The rest of this page walks through what that exploit revealed and the architecture that closes the gap.

What did the UniPwn exploit reveal about humanoid security?

UniPwn (2025) was the first publicly documented humanoid robot exploit, and it revealed that a single shared secret can turn a fleet of humanoids into a self-spreading worm. Security researchers demonstrated that affected Unitree robots, reported across the Go2, G1, and H1 lines, could be compromised over Bluetooth Low Energy, and that a compromised robot could then attack other robots within range, spreading robot-to-robot without an operator ever clicking anything.

The mechanism is the lesson. The affected robots relied on hard-coded cryptographic material shared across the product line, meaning the same key was baked into many robots. Once researchers recovered that shared key from one device, every device that trusted it was reachable. There was no per-robot secret standing in the way, so authentication collapsed into a single point of failure for the entire fleet. A worm is only possible when compromising one node hands the attacker the credentials of the next, and a shared key does exactly that.

UniPwn is worth naming precisely because it is not exotic. Shared factory keys, weak local radios, and implicit trust are exactly the mistakes the wider embedded-device industry already learned to avoid, resurfacing in a fast-moving new category. We cover the disclosure in depth on our UniPwn exploit page. The takeaway for anyone deploying humanoids: the failure was architectural, so the fix has to be architectural too.

How do you stop a humanoid robot from being remotely hijacked?

You stop a remote hijack by making identity per-robot and hardware-rooted, and by authorizing every high-consequence action before the actuator moves. These two controls attack the problem from both ends: identity removes the shared-secret weakness UniPwn exploited, and the authorization gate ensures that even a successful intrusion cannot turn into unauthorized motion.

Per-robot cryptographic identity. Each humanoid generates or receives a private key it never exports, bound to a hardware root of trust. RankShield registers only the corresponding public key. Because no two robots share a key, recovering one robot's secret tells an attacker nothing about any other robot, and a cloned or counterfeit humanoid is detectable the instant it tries to act, because its signature will not verify against any enrolled identity. Identity is post-quantum (composite ML-DSA) and survives firmware updates because it is anchored below the application layer, so an attacker cannot simply flash new firmware to shed the robot's true name.

Pre-actuation authorization gate. The gate sits at the perception-to-action boundary and is deny-by-default. A command is authorized only when four conditions hold at once:

• the robot's signature is valid and the command was not replayed;
• the robot is enrolled and active, not revoked;
• the robot's dead-man liveness is fresh; and
• the specific action is permitted by policy for that robot's role and context.

This ordering is why the gate matters. Detection tools warn you after a robot misbehaves; the gate prevents the unauthorized physical action in the first place. It is also why attestation neutralizes prompt injection against vision-language-action models: even if an attacker fools the model with a doctored sign or object, the resulting actuation command still has to pass the gate, and an out-of-policy force, speed, or region is denied. High-risk actions can require human-in-the-loop or M-of-N confirmation. RankShield does not claim to make a humanoid unhackable; it constrains what a compromised humanoid is allowed to physically do.

How do you secure a fleet of humanoid robots?

You secure a humanoid fleet by giving every robot its own identity, enforcing one policy plane across all of them, and containing a compromised robot without halting the whole fleet. The UniPwn lesson is fundamentally a fleet lesson: the danger was not one hacked robot but a breach that spread. Fleet security therefore has to make one robot's compromise a dead end rather than a launch point.

A RankShield fleet deployment provides three fleet-level capabilities:

• Uniform identity across vendors. Every humanoid, regardless of manufacturer, joins the fleet with the same per-robot, hardware-rooted, post-quantum identity model. There is no shared key to recover and no lowest-common-denominator vendor to weaken the whole fleet.
• One policy plane. Authorization policy is defined once and enforced at every robot's actuation boundary, so a rule such as "this robot may not exceed this force in this zone" is consistent across a mixed fleet rather than reimplemented per vendor.
• Targeted containment. If a robot is lost, stolen, or shows signs of compromise, its identity can be revoked instantly and it can be quarantined from privileged actions, and optionally from the network, via a dead-man or kill credential. Because containment is per-robot, the rest of the fleet keeps operating.

Every allow and deny decision across the fleet is sealed to an append-only transparency log and returned as a verifiable action receipt, so a fleet operator can prove, per robot and per action, what happened and that the record was not altered. For the operator's full cross-vendor view, see robot fleet security for operators. The design goal is simple: make lateral movement across a humanoid fleet cryptographically impossible, not merely detectable after the fact.

What do humanoid OEMs need before shipping?

Before shipping, a humanoid OEM needs per-robot identity provisioned at manufacture, firmware attestation, an actuation authorization path, and verifiable provenance, all built in rather than bolted on. UniPwn is a cautionary tale precisely at the OEM layer: the shared hard-coded key was a design decision made before any robot left the factory, and no amount of downstream detection could undo it. Secure-by-design means the identity and authorization architecture is present in the first unit sold.

Concretely, an OEM preparing to ship humanoids at scale should build in:

• Unique identity per unit. Each robot gets its own key bound to a hardware root of trust (secure element, TPM, or DICE) during manufacturing, never a shared line-wide secret.
• Firmware attestation. The robot can prove its running build and policy match a signed reference before it is trusted, using the IETF RATS model, so tampered or downgraded firmware is caught and quarantined.
• An authorization path to the actuators. High-consequence commands pass a deny-by-default gate, giving operators a place to enforce policy the OEM cannot anticipate.
• Provenance out of the box. Actions and verdicts are recorded as tamper-evident receipts, which shortens incident investigation and supports recall and liability defense.

This also aligns with where regulation is heading. The EU Machinery Regulation 2023/1230 becomes binding in January 2027 and carries explicit protection-against-corruption obligations, and ISO 10218:2025 now mandates a cybersecurity risk assessment for industrial robots. RankShield offers these capabilities to robot makers as an embeddable SDK so security ships secure-by-design rather than as a customer's problem. Building the architecture in is cheaper than a field recall after a fleet-wide worm.

Can RankShield secure any humanoid robot platform?

Yes, RankShield is vendor-neutral and secures any humanoid platform, because it operates on the command and telemetry path rather than inside a specific robot's proprietary stack. It does not require a particular manufacturer, locomotion system, or middleware. Whether a fleet runs Figure, Optimus, Unitree, 1X, or a mix, each robot can be issued a per-robot identity, placed behind the authorization gate, and made to emit verifiable provenance.

RankShield deploys as an overlay: it consumes command and telemetry streams, issues identities, enforces authorization at the actuation boundary, and streams receipts to the transparency log. That overlay model is exactly what makes it deployable across a mixed-vendor humanoid fleet instead of a single robot model. For robot makers the same capabilities are available as an embeddable SDK; for operators they deploy as a fleet-wide identity and policy plane. A pilot typically covers identity, the gate, and provenance on a bounded set of robots within weeks.

Honest scope. RankShield complements the security you already run, it does not replace it:

• It complements SROS2 and DDS-Security, which authenticate participants and encrypt topics but do not authorize individual physical actions or emit verifiable receipts. RankShield adds that missing layer; it does not replace ROS 2 or your controller.
• It complements detection tools. Endpoint detection watches for bad behavior after it happens; RankShield authorizes actions before motion. The two are stronger together.
• It does not replace a functional-safety e-stop, cannot certify that a spoofed sensor reading is fake (it can sign a reading's provenance, not verify physical ground truth), and constrains the action a manipulated model produces rather than the model's internal reasoning. It works only when it sits in front of the actuator.

No humanoid is unhackable, and RankShield never claims otherwise. What it guarantees is narrower and more defensible: a compromised humanoid cannot impersonate another robot, cannot take an unauthorized physical action, and cannot hide what it did. To see it on your robots, request early access.

Frequently asked questions