A security executive says authentication, secure boot and recovery should protect safety systems alongside robot software.
Humanoid robots make a cyberattack more than an IT outage. If compromised data changes how a robot interprets force or decides when to stop, a safety control could produce unsafe behavior. That is the risk Eric Sivertson, Lattice Semiconductor’s vice president of security business, described on The Robot Report Podcast, Episode 260.
Sivertson’s proposal is an architecture, not a deployed humanoid product. He argues that robots need safety and cybersecurity designed together: “You can’t trust a humanoid if it’s not both safe and secure.”
The first layer is authentication. A robot should be able to verify that a sensor, controller or cloud service is the genuine device or endpoint it claims to be. Digital signatures can then verify that both sides are running authorized code. In practical terms, the robot is checking not only who is communicating, but whether the instructions are legitimate.
Lattice positions certain FPGAs—programmable chips—as root-of-trust components. Sivertson says they include non-volatile memory inside the chip and can boot from two locked flash images. One known-good image could supervise updates to the other, helping preserve a valid configuration if an update is attacked.
He also described a recovery path for a GPU. An FPGA could monitor whether the processor is receiving authenticated instructions; if the image becomes unavailable or invalid, it could help restore that image and bring the GPU back online. That is resilience against denial of service, not merely prevention of unauthorized code.
The discussion identifies no specific humanoid, customer deployment, attack, or independent test of the architecture. For operators, the next meaningful question is whether this recovery process can be demonstrated while a robot is moving or performing a person-facing task—when restoring computation must not create a new safety problem.