Cybersecurity of humanoid robots

0
638

A humanoid robot today is no longer just a smart machine on two legs. It is a mobile cyber-physical node that combines sensors, middleware, network services, remote management, and increasingly also AI models. This combination makes humanoids a significantly more sensitive category than conventional industrial robots or surveillance cameras. A failure no longer means only data loss, but also risks to operational safety, privacy, and the physical environment. A 2025 systematization of knowledge therefore proposes evaluating humanoids as a distinct security class with seven layers of risk and notes that cloud elements such as telemetry and OTA updates are now a standard part of their ecosystem. [1]

Why the Unitree G1 Is a Cybersecurity Concern

According to official materials from Unitree Robotics [2], the G1 includes a depth camera and 3D LiDAR, a four-microphone array, Wi-Fi 6, Bluetooth 5.2, and support for OTA updates. Developer documentation further states that the G1 head uses the Intel RealSense D435i camera, sensor equipment suitable not only for navigation but also for detailed visual data collection. From a security perspective, this means one simple thing: the G1 is not just a robotic platform, but also a highly mobile collection device for audio, video, spatial data, and operational telemetry. [3]

The official Explore APP additionally allows users to view the machine’s real-time status, temperatures, and alarms, perform joint and IMU calibration, and includes guides such as “Adding G1 & Network Setting” and “Remote Control Connection.” SLAM documentation explicitly assumes that the operator is connected to the same LAN as the robot and that the required services are running. The publicly available documentation itself confirms that real-world deployment of the G1 relies on network communication, remote management, and multiple services operating over sensor data. [4]

What We Actually Know About Data Exfiltration Risks

The most important public evidence emerged in September 2025 in two papers by researchers from Alias Robotics [5]. The shorter paper, Cybersecurity AI: Humanoid Robots as Attack Vectors, summarizes that the analyzed G1 regularly transmitted multimodal telemetry to remote servers every 300 seconds. The more extensive study, The Cybersecurity of a Humanoid Robot, adds network captures and examples of telemetry payloads allegedly containing battery status, IMU data, motor positions, running services, and system resource usage. [6]

The larger study further claims that more than 40 DDS data streams suitable for aggregation and transmission were active on the robot. It describes continuous audio capture via the DDS topic rt/audio_msg, visual and depth streams through the RealSense camera and video-streaming topics, as well as LiDAR point clouds, voxel maps, GNSS, and odometry data that can reveal not only “what the robot sees,” but also the structure of the environment in which it operates. This point should not be oversimplified. Even IMU data, motor states, or odometry may be sensitive because long-term collection reveals movement patterns, usage behavior, and indirectly also the layout of spaces and operational routines. [7]

At the same time, it is important to remain cautious in the conclusions. Public direct evidence for the G1 remains limited and is based primarily on two cybersecurity studies from 2025 later cited by surveys and advisories. That does not mean the issue can be ignored. The survey SoK: Cybersecurity Assessment of Humanoid Ecosystem uses the G1 EDU as a case study and emphasizes that humanoids require consideration of audio/video interception, replay attacks against IMU and odometry, and middleware abuse. Furthermore, National Institute of Standards and Technology (NIST) [8] lists a BLE command injection vulnerability affecting the shared firmware base of the Go2/G1/H1/B2 family in the CVE database, while the older Go1 model reportedly included a backdoor for remote control. The practical conclusion is therefore straightforward: the risk is publicly documented, even if it has not yet been independently replicated at scale across all firmware versions. [9]

Sources With the Highest Decision-Making Value

The Cybersecurity of a Humanoid Robot: An Early Study via the Unitree G1

The most important public resource for technical teams, containing reverse engineering, service mapping, network behavior analysis, telemetry payloads, and practical implications for audio, video, LiDAR, and IMU data. [10]

Cybersecurity AI: Humanoid Robots as Attack Vectors

A useful executive-level summary highlighting the key finding that the G1 can function both as a surveillance node and as a platform for broader cyber operations. [11]

SoK: Cybersecurity Assessment of Humanoid Ecosystem

This document is not focused on exfiltration from a specific G1 unit, but it is highly valuable for threat modeling. It places the G1 EDU into a broader context and demonstrates that humanoid security must simultaneously address sensing, middleware, decision-making layers, and cloud services. [12]

Vision-Language Models on the Edge for Real-Time Robotic Perception

This paper is relevant because it directly demonstrates on the G1 the practical difference between cloud offloading of multimodal data and edge deployment. The authors explicitly describe privacy risks associated with sending raw video/audio streams to the cloud and advocate for edge-based processing. [13]

Cybersecurity of Teleoperated Quadruped Robots

A secondary but useful survey because it incorporates findings about G1 telemetry and audio capture and explains why, due to shared architecture, the same concerns are relevant for other robots from the same manufacturer. [14]

Three Realistic Defense Models

When designing cybersecurity measures, it makes sense to treat a humanoid robot as an OT-like asset. According to NIST definitions, OT includes programmable systems that directly monitor or interact with the physical environment, which precisely applies to humanoids. The ISA [15] / IEC [16] 62443 standards are based on dividing systems into zones and conduits, defining target security levels, and implementing corresponding technical controls. [17]

Option One: Isolated Network Perimeter According to IEC 62443

For most organizations, this is the most reasonable solution. In practice, it means a dedicated OT zone for the robot, ideally using a separate switch or at least an isolated VLAN segment, no direct exposure to the public internet, strict egress rules, a “deny all, permit by exception” policy, and routing approved traffic through an authenticated proxy or broker located in a DMZ.

NIST additionally recommends segmentation, explicitly authorized communication between segments, equally strict outbound and inbound traffic policies, centralized logging, and network monitoring. Other public OT guidance further states that external access should be brokered through a secure DMZ gateway and continuously monitored.

For LLM/VLM workflows, it is advisable to isolate the robot from the cloud and operate AI models locally on an edge node within the same security zone. The G1 edge-VLM paper directly demonstrates that moving inference closer to the data reduces privacy risks and dependence on WAN connectivity. [18]

Option Two: Offline Deployment

This option provides the highest assurance against exfiltration, but at the cost of functionality. The G1 cybersecurity study explicitly states that for highly sensitive environments, an air-gapped deployment is the only method capable of preventing data leakage, while simultaneously limiting functionality and undermining some intended use cases.

This aligns with official documentation. The G1 is designed around OTA updates, network configuration, remote control, LAN-based SLAM services, and applications for diagnostics and calibration. Offline mode therefore makes sense primarily in scenarios where the robot performs narrowly defined tasks and the organization is willing to sacrifice convenience, remote management, and parts of the AI workflow. [19]

Option Three: Firmware Modification

Rewriting internal firmware or deeply modifying binary components represents the most technically demanding and operationally complex approach. Public studies on the G1 describe how attempts to disable telemetry encountered automatic process restarts through master_service, encrypted configuration files, anti-debugging protections, and binary obfuscation.

The manufacturer’s official warranty terms additionally state that unauthorized modification, disassembly, or opening of the device voids the warranty and explicitly warn about damages caused in developer mode with custom software.

In practice, this approach only makes sense where sovereign operation is the priority and the organization is willing to accept long-term in-house development, internal service capability requirements, and the loss of part of the original functionality, including the official app, OTA updates, and some maintenance workflows. [20]

Recommended Baseline Architecture

For most enterprise, research, and public-sector deployments, we recommend operating the G1 as an untrusted OT node within an isolated zone, without direct internet access, protected by a dedicated firewall, with an authenticated proxy in the DMZ, a local edge node for ASR/VLM/LLM processing, and a centralized observability server collecting logs from firewalls, proxies, applications, network flows, and robotic services.

This directly reflects the expectations of IEC 62443 and OT security guidance: secure conduits, restricted data flows, monitorable interfaces, and an auditable trail showing who interacted with the robot, which commands it received, and where it attempted to communicate. [21]

If the robot is intended to operate in environments containing sensitive know-how, personal information, medical records, or non-public research infrastructure, practical validation testing should always be part of acceptance procedures. This includes packet capture during initial startup, inventory of all active services, baseline traffic analysis, allowlisting of approved communications, and continuous anomaly monitoring.

The current public state of knowledge does not say that “every humanoid robot is automatically a spy.” What it does say, however, is that without network segmentation, controlled egress, and rigorous logging, a humanoid robot can very quickly become a mobile sensing platform with unclear data sovereignty. [22]

Author: Tomáš Jochman, ICHR

Sources

Předchozí článekPřemysl Šůcha in Česká televize - Studio 6
Další článekThe D.A.R. Continuum Conference at CIIRC CTU Opened Discussions on Responsible AI and Autonomous Technologies