What data does a robot vacuum collect when it maps your home?

Most Level III robot vacuums in the current market follow the same pattern. LiDAR or camera-based navigation requires a floor map. That map is stored in the cloud so it persists across app reinstalls, device reboots, and multiple users. Cleaning histories, zone usage, and scheduling patterns are logged for personalization features.

Obstacle photos, in camera-equipped systems, may be transmitted for AI model improvement. The user-facing benefit is a robot that remembers your home. The consequence is that your home’s geometry, room labels, and cleaning behavior exist on a vendor server.

The iRobot Roomba j7+’s privacy policy documents that camera, motion, and location data transmit to iRobot servers for mapping, obstacle detection training, and service diagnostics. Users can opt out of camera processing for training purposes, per iRobot’s documentation, but cannot disable the map transmission required for app features. The iRobot Roomba j7+ carries a privacy score of 48 in the Robovations classification. Local processing is not available.

The Ecovacs Deebot X2 Omni operates on cloud-dependent infrastructure for map storage, scheduling, and voice commands. Ecovacs collects usage telemetry and map geometry on their servers. The X2 Omni carries a privacy score of 56 in the classification.

The October 2024 incident was not a flaw in the map-transmission pipeline itself but in a Bluetooth authentication gap that gave attackers control of the camera and speaker. Both failure surfaces, the cloud transmission and the local wireless interface, exist because the robot is a networked sensor device.

Four robots classified at Level III illustrate how data practices vary within the same autonomy tier. All four require cloud connectivity for full feature access. None offers a documented fully-local mode. The differences are in what each manufacturer discloses, what data leaves the home, and whether any processing stays on-device.

The 2022 iRobot incident and the 2024 Ecovacs incident are different failure types. The iRobot case was a consent and data-handling failure at the beta program level: images moved to a third-party labeling contractor in a way that participants did not expect.

iRobot’s privacy policy permitted the data use; the distribution path was not what users understood. The Ecovacs case was a security vulnerability: a Bluetooth authentication gap allowed unauthenticated remote access to the camera feed and speaker on affected units.

What the two cases share is the precondition. A robot that cannot store its floor map and operate its camera without cloud or wireless infrastructure is a robot that cannot fail securely. The iRobot development units sent images off-device because that was the architecture.

The Ecovacs units had a remotely exploitable live camera because that was the architecture. Owners who purchase Level III capability acquire the data footprint that makes Level III possible.

A security researcher found the Deebot X2 Omni had a Bluetooth vulnerability that allowed someone to send commands from nearby without authentication, and that the vulnerability persisted even after Ecovacs said they would fix it.

Reported by TechCrunch, August 2024; ABC News Australia, October 2024

The Ecovacs patch timeline is relevant context. The Verge’s reporting noted that the vulnerability had been disclosed to Ecovacs months before the October 2024 incidents, and that a fix had been promised but not yet deployed at the time owners were affected. The gap between disclosure and patch is not unique to Ecovacs.

Security researchers have documented similar lag patterns across the consumer IoT category. A camera-equipped robot vacuum is an IoT device with a camera, a microphone in some models, a persistent network connection, and a detailed map of its owner’s home. The attack surface is proportional to the capability.

Floor maps stored on vendor servers do not automatically delete when an owner sells their home, replaces their robot, or cancels their account. Each manufacturer documents a different retention policy.

iRobot’s privacy documentation states that account data is retained until the account is deleted, and that users can request deletion. Ecovacs’s privacy policy permits retention of anonymized data after account closure. Samsung’s SmartThings terms describe retention periods tied to service operation requirements.

The ownership-transfer scenario deserves specific attention. A robot vacuum sold on a secondary market retains, until explicitly factory-reset and deregistered, the previous owner’s floor map and account association. A robot delivered to a new address may still have the prior home’s layout in the vendor’s system under the original account.

This is not a theoretical edge case: owner forums document instances where resale units arrived pre-mapped and pre-associated with a prior account. The remedy is straightforward, a factory reset and proper deregistration, but the default state creates a handoff window.

Corporate acquisition adds another dimension. Amazon’s acquisition of iRobot, which received regulatory scrutiny before being abandoned in January 2024, raised questions about what floor-plan data at scale would mean in the hands of a retail and logistics conglomerate. The deal did not close, so no data transfer occurred. The episode surfaced a concern the industry has not fully resolved: floor maps are valuable training data, and manufacturers can be acquired.

Owners have limited structural options. Disabling WiFi on a Level III robot that requires cloud map storage for full functionality degrades the core feature set. Opting out of camera data submission for AI training, where that option exists, affects one transmission path but does not affect map storage or firmware update delivery.

Firmware updates themselves often require cloud connectivity, creating a dependency loop: staying current on security patches requires maintaining the connectivity that creates the data footprint.

Some specific levers do exist. iRobot’s privacy settings allow opting out of camera frame submission for AI training, documented in the iRobot privacy portal. Samsung’s SmartThings infrastructure provides account-level privacy controls.

None of these resolves the structural dependency on cloud map storage. The practical question for owners is not whether to accept any data transmission, which Level III navigation makes unavoidable, but which specific practices each manufacturer applies to what they collect.

Consumer IoT privacy in the United States is covered by a patchwork of state and federal rules rather than a single framework. The FTC’s data security authority under Section 5 applies to deceptive or unfair data practices.

Several states, including California under the CCPA and its amendments, give residents rights to access and request deletion of personal data held by covered businesses. These frameworks reach robot vacuum manufacturers operating at commercial scale. They do not require local processing, restrict the scope of data collection, or mandate specific retention limits for floor-map geometry.

The UK’s Product Security and Telecommunications Infrastructure Act, which came into force in April 2024, sets minimum security requirements for consumer IoT products sold in that market, including mandatory vulnerability disclosure policies and prohibitions on default universal passwords. This is a security framework rather than a data-minimization one.

It addresses the Ecovacs-type attack surface more directly than the iRobot-type consent surface. Neither type of framework fully maps to the structural condition these incidents expose: that Level III navigation capability is architecturally coupled to off-device data storage in the current product generation.

Owners who want local-first operation have a narrow set of options in the current market. Valetudo, an open-source firmware replacement for certain robot vacuums, enables local map storage and control without cloud dependency. Valetudo is community-maintained, voids manufacturer warranties, and supports a limited set of models. It is the only documented path to genuinely local Level III operation on current consumer hardware for the robots it supports.

Level III conditional autonomy requires persistent environmental awareness. A robot that forgets your floor plan between sessions, or that cannot transmit obstacle data for model training, is a robot operating at a lower effective capability. This is not a trade-off that manufacturers invented arbitrarily. The navigation architecture that produces Level III behavior is, in current consumer hardware, inseparable from the data collection architecture that concerns owners.

Level IV environmental autonomy, which would require robust real-time generalization rather than map-dependent operation, does not currently appear in any classified consumer robot in this analysis. If and when it does, it will not reduce the data footprint.

More capable navigation requires richer sensor data. The question of what data leaves the home when a robot operates is not a transitional concern of early-generation hardware. It is a property of the category.

The pattern across both incidents is the same: the data practices were lawful, disclosed somewhere in a policy document, and still surprising to the people whose homes appeared in them.