Your Robot Phones Home Every Five Minutes. Do You Know What It Says?

What did researchers actually observe?

Alias Robotics documented the Unitree G1 humanoid transmitting "multimodal telemetry data (including sensor readings and service status)" every 300 seconds to servers hosted in China, and assessed that it did so "without clear user notification, violating GDPR requirements (Articles 6 and 13)" ¹. The work was presented at IEEE Humanoids 2025 ¹.

Be precise about the scope of that finding, because it gets inflated in retelling. What is documented at this source is sensor readings and service status on a five-minute cadence. This article does not claim audio or video capture on that platform, because this source does not report it. The cadence and the destination are the load-bearing facts, and they are enough.

The follow-up matters as much as the finding. After responsible disclosure, the researchers report that the vendor introduced "minor fixes" but that "critical vulnerabilities remain unaddressed and periodic telemetry continues to flow" ¹. The telemetry was not treated as a bug to be closed, which is consistent with it being a feature.

Is that a breach, or the product working as designed?

The second, and the distinction decides which of your controls is relevant. A breach is an attacker taking data you did not intend to send. Designed egress is your product sending data exactly as specified by the people who built it. The first is detected by intrusion monitoring and closed by patching. The second is invisible to both, because nothing is malfunctioning.

This is why the finding survived disclosure. There is no fix to ship for behaviour that is not a defect ¹. An operator waiting for a patch is waiting for a change of product strategy, and the reasonable question shifts from "when will this be fixed" to "do I accept this, and did I know about it when I bought."

It also explains a gap in how robot fleets are usually secured. Considerable effort goes into whether someone could compromise the robot, which is right and we have written about it repeatedly, including what to do when a published root chain has no patch. Comparatively little goes into what the robot sends when nothing is wrong at all.

What changes on 12 September 2026?

Access stops being a favour the vendor grants and becomes a design requirement. Article 3(1) of the Data Act provides that manufacturers "shall design connected products so that product data ... are always easily and securely accessible to a user, free of charge" ². That obligation attaches to connected products placed on the EU market from 12 September 2026 ³.

The regulation itself has been applicable since 12 September 2025, and the obligation that took effect then is worth noting because it is already live: data holders may no longer use or share data generated by the product without a contractual agreement with the user ³. What arrives in September 2026 is the design half, which is the part a robot manufacturer cannot satisfy by amending a contract.

Note also what the user must be told before buying. Articles 3(2) and 3(3) require information on "the type, format and the estimated volume of such data" and "clear and sufficient information ... on how the data may be stored, retrieved or accessed" ². A fleet operator who cannot state the volume and cadence of what their robots emit has not received that information, or did not ask for it.

Does this reach manufacturers outside the EU?

Yes, and that is the provision that makes this relevant rather than academic. The Data Act "has an extra-territorial reach, applying to manufacturers and providers that place connected products and related services on the EU market, irrespective of their place of establishment" ³. The trigger is the market you sell into, not where your company sits.

For robotics that matters because the manufacturers most associated with telemetry findings are frequently not EU-based, and the instinct is to assume EU rules are somebody else's problem. They are not, if the product is placed on the EU market. Enforcement has weight behind it: breaches of Chapter II can attract administrative fines of up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher ³.

There is a second-order effect worth planning for. A manufacturer who builds access-by-design for the EU will generally not build a separate blind version for everywhere else, so the practical availability of robot data is likely to improve outside the EU as a side effect. That is a reason for non-EU operators to start asking now rather than later, from a stronger position than they had a year ago.

Why can you not simply ask the vendor?

You can and you should, and you should also treat the answer as a claim rather than a measurement. The G1 behaviour was not discovered by reading a datasheet. It was found because researchers watched what the robot actually did on the wire and compared that against what anyone had been told ¹.

This is the same epistemic gap we keep running into on this site in different clothes. A vendor statement that a fix is deployed, a manifest that says what a skill does, a spec sheet that lists what a robot transmits: each is a description of intended behaviour, and each is useful. None of them is evidence of actual behaviour, and the difference only becomes visible when someone measures.

The pattern is not unique to robotics, but robotics has an aggravating factor. These products change under you. A firmware update can add a destination, raise a cadence, or extend a data category without any visible change in how the machine behaves in the room. If your knowledge of egress came from a document you read at procurement, it describes a product that may no longer exist.

How do you find out what a robot actually sends?

By watching the network, which is unglamorous and entirely within your control. Put the robot on its own segment and capture what leaves it: every destination by hostname and address, the cadence, the payload sizes, and how all three change across a firmware update. You do not need to decrypt anything to learn a great deal. Destination, frequency and volume alone would have surfaced a five-minute heartbeat to an unfamiliar host ¹.

Then invert the default. Most robot deployments allow egress and watch for bad destinations, which means a new destination succeeds and you find out later, if at all. Deny-by-default egress with an explicit allowlist means a new destination fails and generates an event. The operational cost is real, the diagnostic value is that every change in the product's phone-home behaviour becomes something you see on the day it happens.

Three practical notes. Capture at the network boundary rather than on the robot, because a device is a poor witness to its own behaviour. Re-run the measurement after every firmware update rather than once at onboarding. And record the result, because "we checked and it talks to these four hosts every five minutes" is exactly the sort of statement that is worthless from memory and valuable with a date attached to it.

What does attestation add here, and what does it not?

It does not tell you what the robot sends, and we should not pretend otherwise. Knowing what leaves a machine is a network measurement problem, answered by egress capture, DNS logging and an allowlist. That is not what an attestation and authorization layer does, and a vendor who tells you their attestation product reveals your egress is describing something else.

What attestation answers is the adjacent question that egress monitoring cannot: which firmware, policy and model version was running on that specific unit when the traffic changed. That matters because the useful finding is rarely "the robot talks to a server." It is "the robot started talking to a new server on the 14th, and here is the software change that landed on the 13th." Egress capture gives you the first half. Firmware attestation gives you the second, and neither is much use alone.

The same division applies to the record. Tamper-evident provenance establishes what the robot was authorized to do and did, which is the evidence question we covered in the piece on liability and disclosure. It does not establish what the robot transmitted. Two different logs, two different questions, and an operator needs both to answer a regulator who asks what the machine was doing and what it was sending while it did it.

What should an operator do before 12 September?

Pick one robot model and try to answer four questions from evidence rather than documentation: where does it connect, how often, what categories of data leave it, and can you retrieve that data yourself in a usable format. Then check whether you were told the type, format and estimated volume before you bought it, because that is what Articles 3(2) and 3(3) contemplate ².

Where the answer is no, that is a procurement conversation with your vendor and, if you sell into the EU, a compliance conversation with counsel. The worksheet below structures the exercise and produces a dated summary. It is a readiness prompt rather than legal advice, and everything runs in your browser.

Frequently asked questions about robot telemetry, egress visibility and the EU Data Act

References

1. Alias Robotics. Insecure Humanoids: When AI Exposes the Dark Side of Modern Robotics (research presented at IEEE Humanoids 2025). 2025. aliasrobotics.com/news/insecure-humanoids-ai-dark-side-robot
2. European Union. Regulation (EU) 2023/2854 (Data Act), Article 3(1), 3(2) and 3(3). 2023. eur-lex.europa.eu/eli/reg/2023/2854/oj/eng
3. Greenberg Traurig. Action Required for Providers of Connected Devices: Challenges Under the EU Data Act. 2025. www.gtlaw.com/en/insights/2025/9/action-required-for-manufac