Per-Robot Cryptographic Identity: Machine Identity Built for Fleets of Robots

Why does every robot need its own identity?

Every robot needs its own identity because a fleet that shares one credential can be impersonated, cloned, or worm-infected the moment that single secret leaks. Identity is the anchor that authorization and provenance are built on: if you cannot prove which specific robot sent a command, you cannot safely decide whether the command is allowed, and you cannot prove afterward who acted.

The 2025 UniPwn disclosure made this concrete. Unitree humanoids shipped with a hard-coded, shared cryptographic key baked into the firmware image. Because every unit carried the same secret, an attacker who extracted it from one robot could authenticate to all of them over Bluetooth Low Energy, which is what made the takeover wormable across a fleet. That is not a bug in one robot; it is a structural property of shared-key designs. Per-robot identity removes the property entirely.

Unique identity also unlocks the operational controls a fleet actually needs:

• Attributable action. Each command carries a signature only one robot could produce, so allow and deny decisions are made against a real principal, not an anonymous message on a bus.
• Granular revocation. A single compromised robot can be cut off without re-keying the rest of the fleet.
• Role and policy binding. Identity ties a robot to its role and its permitted actions, so policy can differ per unit and per context.
• Verifiable provenance. Because the actor is unambiguous, the action receipt is admissible as forensic and compliance evidence.

This is the first component of the RankShield Robotics platform, and everything else depends on it. Without per-robot identity, a pre-actuation gate cannot know whom it is authorizing, and a transparency log cannot prove who did what. With it, the fleet becomes a set of individually verifiable principals rather than an interchangeable population of clones. As shipments scale toward tens of thousands of humanoids and mixed-vendor fleets in 2026, that shift from "a population of identical units" to "a roster of named, revocable machines" is the difference between a single leaked secret compromising everything and a single robot being quarantined in seconds.

How is that identity rooted in hardware?

The identity is rooted in a hardware element on the robot that generates and stores the private key so it can never be exported. During enrollment, the robot creates (or is provisioned with) a key pair inside a hardware root of trust: a TPM, a DICE-capable microcontroller, or a secure element. The private key stays sealed in that hardware and is only ever used to sign; RankShield registers the corresponding public key as the robot's verifiable identity.

Rooting the key in hardware is what makes the identity tamper-resistant rather than merely secret. A password or a key stored in a firmware image can be dumped by anyone who reads the flash, which is precisely how shared-key designs fail. A key that never leaves a secure element cannot be copied off the robot even by an attacker with physical access to the firmware, because the signing operation happens inside the hardware boundary and the raw key is never present in exportable memory.

Anchoring below the application layer has a second benefit: it decouples the identity from the software that runs on top of it. The robot's operating system, middleware, and application code can all be replaced without disturbing the key, because the key belongs to the hardware, not to a particular build. This is why the identity survives firmware updates and why RankShield can interoperate with existing hardware roots of trust rather than reinventing them. The same hardware evidence also feeds RATS firmware attestation, so identity and firmware trust share one root.

How does per-robot identity detect a cloned or spoofed robot?

A cloned or spoofed robot is detected because it cannot produce a signature that verifies against any enrolled identity, so its first command is denied at the gate. Detection is not a heuristic or an anomaly score here; it is a cryptographic fact. To impersonate a genuine robot, an attacker would need that robot's private key, and the key never leaves its hardware root of trust.

Consider the three ways an attacker tries to introduce a fraudulent robot, and how per-robot identity defeats each:

• Physical clone. An attacker builds or reflashes a robot that looks identical. It has no enrolled key pair, so every command it sends fails verification. It is denied before any actuator moves.
• Spoofed messages. An attacker injects commands onto the bus or network claiming to come from a real robot. Without that robot's private key, the injected commands are unsigned or wrongly signed and are rejected.
• Extracted-key replay. Even if an attacker recorded valid signed traffic, freshness and liveness checks (a fresh dead-man signal and anti-replay nonces) mean a captured signature cannot be reused to authorize a new action.

This is the direct structural fix for the shared-key class of attack. Under UniPwn, extracting the one key from one robot was enough to authenticate as any robot. Under per-robot identity, extracting a key (which the hardware root is designed to prevent) compromises only that single unit, and that unit can be revoked in seconds. The blast radius collapses from the whole fleet to one robot.

Because verification happens at the pre-actuation authorization gate, detection and prevention are the same event. There is no window in which a counterfeit robot acts and is caught later; it is denied at the moment it attempts to act, and the denial is written to the transparency log as evidence.

Does the identity survive firmware updates?

Yes. Because the identity is anchored in the hardware root of trust rather than in the application software, a firmware update or full reflash does not destroy it. The private key lives inside the secure element or TPM, below the layer that firmware updates replace, so patching the robot's software, upgrading its OS, or reinstalling its application stack leaves the key untouched and the robot's registered identity intact.

This matters more for robots than for most IT devices. Robots receive frequent over-the-air updates across a service life measured in years, and an identity scheme that broke on every patch would be operationally unusable. It would also create a security gap: if updating a robot forced re-enrollment, attackers would target the update window, and operators would be tempted to skip patches to avoid the churn.

Separating identity from firmware also keeps the two trust decisions clean and independent:

• Identity answers "which robot is this?" and is stable across the robot's lifetime.
• Attestation answers "is this robot running a known-good, current build?" and is re-evaluated on every update via RATS firmware attestation.

The combination is what you want. After an update, the robot proves it is still the same enrolled unit (identity) and separately proves that its new firmware matches a signed reference and has not been downgraded to a vulnerable version (attestation). A robot whose firmware fails appraisal keeps its identity but is quarantined from privileged actions until it is remediated, so the update process itself becomes a checkpoint rather than a blind spot. Identity persists; trust in the current build is earned freshly each time.

There is a practical fleet benefit too. Because identity is stable across reflashes, an operator can push firmware to hundreds of robots without triggering hundreds of re-enrollments, and each robot re-proves its build state on the way back into service. The action receipts in the provenance log therefore carry a continuous identity across the robot's whole lifetime, which is what makes long-horizon incident reconstruction and warranty or recall analysis possible. A robot you enrolled on day one is the same verifiable principal years and many updates later.

How is this different from IT machine identity (X.509, SPIFFE)?

IT machine identity secures which service or workload is talking on a network; per-robot identity secures which physical machine is about to move in the real world, and binds that identity to actuation, not just to a connection. The cryptographic primitives overlap, but the threat model and the enforcement point are different, which is why robot identity needs its own design.

Standards like X.509 certificates and SPIFFE/SPIRE do machine identity well for data-center and cloud workloads. They authenticate participants, establish mutual TLS, and rotate short-lived credentials. RankShield does not discard that lineage; it extends it to the constraints of embodied systems.

Two differences drive the design. First, the enforcement point: IT identity is checked once when a connection opens, whereas a robot's danger lives in each individual actuation command, so identity has to be verified per action at the gate, not just at login. Second, the time horizon: a robot deployed in 2026 may still be operating in 2040, so its credentials must be post-quantum today to resist harvest-now-decrypt-later capture, a concern most short-lived IT credentials sidestep. Where SROS2 and DDS-Security authenticate participants on the ROS 2 graph, they too stop at the connection; per-robot identity adds the physical-action layer above them. RankShield complements these standards rather than replacing them.

The information-gain point most machine-identity discussions miss is the coupling between identity and physical consequence. In IT, a stolen or misissued credential leaks data; on a robot, the same failure can drive a manipulator into a person. That raises the bar for both the root of trust (hardware, not a filesystem secret) and the credential lifetime (post-quantum for a decade-plus lifespan). RankShield deliberately reuses the well-understood parts of the machine-identity world, hardware roots and standard signing, and adds only what embodiment demands: per-command verification and quantum-resistant keys bound to the actuator path.

How do you revoke a robot’s identity instantly?

You revoke a robot by marking its enrolled identity as suspended or revoked, after which every command it sends fails verification at the gate immediately and fleet-wide. Because authorization is checked against the current enrollment record on every high-consequence action, changing a robot's status takes effect on its very next command rather than waiting for a certificate to expire.

Revocation is the control you reach for when a robot is lost, stolen, physically captured, showing signs of compromise, or being decommissioned. The moment its identity is revoked, the robot is cut off from privileged actuation: any command it sends is denied and logged, even though its key material is still technically valid. You are not trusting the robot to disable itself; you are removing it from the set of principals the gate will honor.

Per-robot identity is what makes instant, surgical revocation possible:

• Blast radius of one. Revoking a single robot does not disturb any other unit, because no key is shared. There is no fleet-wide re-key, no downtime for the robots that remain trusted.
• No propagation delay. Enforcement reads the live status at the gate, so there is no window like a cached certificate revocation list that an attacker can exploit.
• Reversible containment. A robot can be suspended (quarantined) rather than permanently revoked, then reinstated after it passes attestation, so containment does not force replacement.

Revocation pairs naturally with the pre-actuation gate and with dead-man and kill credentials for emergencies: identity decides whether a robot is trusted at all, the gate decides whether a given action is allowed, and the kill path forces an immediate stop. Together they let an operator contain a compromised robot in seconds without halting the rest of the fleet. To see this on your own robots, request early access.

Frequently asked questions