Cybersecurity RoboticsLeading robot cybersecurity lab

Phoning home: the robot cloud as a fleet-wide risk

Research Note · 2026

AuthorsVíctor Mayoral-Vilches
AffiliationCybersecurity Robotics
Published2026
1A robot is never alone2The always-on tunnel3Why the cloud is the worst place to be breached4Teleoperation raises the stakes5You inherit the vendor's security6What holds it7References

Abstract. Every modern robot keeps an always-on connection to its maker — for telemetry, remote management, over-the-air updates and cloud teleoperation. That convenience turns the manufacturer backend into a single, remote, always-connected attack surface for the entire fleet. Where a worm spreads sideways from robot to robot, a cloud breach — or a built-in tunnel like Unitree CloudSail — reaches every unit at once, remotely and persistently. This briefing maps the phone-home attack surface, shows why credential architecture decides the blast radius, and sets out what actually contains it.

A Cybersecurity Robotics field briefing — a cited synthesis of the external research listed below, not an original paper.

1A robot is never alone

Almost every robot shipped today keeps a live connection to its maker. It streams telemetry, accepts over-the-air updates, exposes a remote-management channel, and increasingly is driven through cloud teleoperation. Each link is a convenience — and, together, they turn the manufacturer's backend into a single, remote, always-connected attack surface for the entire fleet. The lab's robot worm spreads sideways, robot to robot, within radio range. This is the other direction: top-down, from the cloud, all at once.

The manufacturer cloud is the fleet's single point of compromise: breach the hub — or abuse a tunnel that is already there — and you reach every robot at once, remotely and persistently.
THE FLEETalways-on tunnelsManufacturer cloudtelemetry · teleop · updatesshared fleet credentials → one key unlocks allAttackerremote control · exfiltrationBreach one robot and you own one robot. Breach the cloud and you own the fleet — at once, remotely, and it persists.

2The always-on tunnel

The connection is not occasional; it is continuous. The February 2026 survey of teleoperated robots documents backends that keep persistent tunnels to vendor servers, carrying video, commands and status. Unitree's CloudSail service was found to hold exactly such a continuous connection to the manufacturer — a channel that doubles as backdoor access without the operator's knowledge; the related Go1 backdoor is catalogued as CVE-2025-2894. And what a robot phones home is often undocumented: a commercial humanoid was observed emitting 40+ covert data streams. You cannot defend a data flow you cannot see.

3Why the cloud is the worst place to be breached

A flaw in one robot compromises one robot. A flaw in the backend compromises every robot bound to it — simultaneously. From the hub an attacker inherits remote control, fleet-wide surveillance, a covert exfiltration path, and a foothold that survives local hardening: patching the endpoint does not close a trusted tunnel. And the blast radius is decided by one design choice — credential architecture. Per-device keying (as on Boston Dynamics' Spot) contains a compromise to a single unit; fleet-wide shared credentials — the pattern found across Unitree platforms — mean one recovered key unlocks the whole fleet.

4Teleoperation raises the stakes

As fleets scale, humans drive robots through this same cloud path in real time — a live route from a remote console to a moving machine. Operators report that at fleet scale the hard questions are suddenly operational: who is allowed in the teleoperation facility, what is logged when someone takes control, how is access revoked when a contractor leaves, and what the robot does when the link drops. A hijacked teleoperation session is not data theft; it is hands on the controls.

5You inherit the vendor's security

Phoning home means a robot's security is now the vendor's cloud security, update pipeline and third-party dependencies — a classic supply-chain exposure, and one the buyer rarely audits. That makes a software bill of materials (SBOM), a documented data-flow of what the robot sends and where, and explicit vendor security requirements part of procurement, not an afterthought. Under ISO 10218:2025, the EU Machinery Regulation and the CRA, an unassessed cloud dependency is now a conformity problem, not just a risk.

6What holds it

Treat the backend as in-scope. Segment and inspect egress — the same host-firewall discipline from hardening a robot, now pointed at what the robot phones home: default-deny outbound, allow only known endpoints, and monitor the rest. Demand per-device keying so one key never unlocks the fleet, an SBOM and a data-flow statement from the vendor, and the ability to disable or self-host the phone-home channel. And put the manufacturer's cloud where it belongs: inside the robot's threat model.

7References

  1. Cybersecurity of Teleoperated Quadruped Robots: a Systematic Survey of Vulnerabilities, Threats, and Open Defense Gaps, 2026.
  2. The Cybersecurity of a Humanoid Robot (Unitree G1: static keys & covert telemetry), 2025.
  3. Cybersecurity AI: Humanoid Robots as Attack Vectors — compromise of manufacturer cloud infrastructure, 2025.
  4. CVE-2025-2894 — Unitree Go1 CloudSail undocumented backdoor (NVD, CWE-912).
  5. Cyber security of robots: a comprehensive survey, 2023.

Citation

@misc{mayoralvilches2026phoninghome,
  title        = {Phoning home: the robot cloud as a fleet-wide risk},
  author       = {Víctor Mayoral-Vilches},
  howpublished = {Cybersecurity Robotics — Field briefing},
  year         = {2026},
  url          = {https://cybersecurityrobotics.com/research/phoning-home/},
}