Smart home robots are increasingly being treated as convenience devices rather than as networked computers with cameras, microphones, mobility and cloud access. That distinction is becoming harder to defend: security research and recent real-world incidents indicate that a compromised household robot can expose live video, audio, floor plans, location clues and remote-control functions.
The issue is not that every robot is insecure. It is that the category combines several high-value capabilities—physical movement, environmental sensing, voice capture and persistent cloud connectivity—in a device that often sits in bedrooms, kitchens and living rooms. When authentication, cloud permissions or update processes fail, the consequences can extend well beyond a malfunctioning appliance.
What attackers can reach
Modern consumer robots commonly use cameras, lidar or structured-light sensors, microphones, Wi-Fi or Bluetooth radios, onboard Linux-based computing, mobile apps and cloud services. These components support navigation, obstacle avoidance, remote monitoring and voice interaction, but they also create a broad attack surface.
Security firm IOActive’s research into home, business and industrial robots identified nearly 50 vulnerabilities in its initial work, including insecure communications, authentication weaknesses, weak cryptography, memory-corruption issues and privacy problems. The firm warned that exploitation could enable spying through a robot’s microphone and camera, data leakage, unwanted actions and, in extreme cases, physical harm or property damage.
“Given the huge attack surface, we found nearly 50 cybersecurity vulnerabilities in our initial research alone, ranging from insecure communications and authentication issues, to weak cryptography, memory corruption, and privacy problems, just to name a few.”
That warning came from IOActive researchers César Cerrudo and Lucas Apa, whose testing covered software and hardware from vendors including SoftBank Robotics, UBTECH Robotics, ROBOTIS, Universal Robots, Rethink Robotics and Asratec Corp. The company said it notified affected vendors through responsible disclosure before publishing its findings. See the research announcement at IOActive: Hacking Robots Before Skynet and the full technical paper at IOActive (PDF).
A concrete cloud failure
The risk became more tangible in a reported incident involving DJI’s Romo robot vacuum. According to reporting on the case, Barcelona-based AI strategist Sammy Azdoufal extracted his own device’s private API token while attempting to control the vacuum with a PS5 controller through Claude Code. He then found that DJI’s MQTT broker allowed access to thousands of other Romo units across 24 countries.
In roughly nine minutes, the reporting said, he cataloged 6,700 devices and collected more than 100,000 messages. The data reportedly included live camera feeds, microphone audio, 2D and 3D floor maps and real-time sensor information.
The technical issue centered on access controls at the application layer. Although DJI used TLS to encrypt traffic in transit, the MQTT implementation reportedly lacked sufficiently granular topic-level permissions. Once authenticated, a client could subscribe to wildcard topics and intercept plaintext data from other devices, according to the account of the incident. Details are available in Yahoo Tech’s report on the DJI Romo breach.
The case illustrates why encryption alone does not make a connected robot secure. TLS protects data while it moves across a network, but authorization determines who may read a particular camera stream, subscribe to a device’s telemetry or issue commands. A broker that authenticates users but fails to isolate device topics can turn one valid credential into access to an entire fleet.
Why household robots differ
A hacked smart speaker may expose audio; a hacked camera may expose video. A mobile home robot can combine both with a map of the interior, knowledge of when rooms are occupied and the ability to move through the home.
- Cameras and microphones can support surveillance if remote access is gained.
- Navigation maps can reveal room layouts, furniture placement and entry points.
- Network metadata, including IP addresses, can provide approximate location information.
- Remote-control interfaces can allow an attacker to alter cleaning routes or trigger movement.
- Cloud accounts and companion apps can become a single point of failure for many devices.
Earlier research has documented similar concerns. A University of Washington study of home robots found vulnerabilities in connected devices that could allow an attacker to use built-in cameras for surveillance. The paper is available at University of Washington (PDF). IOActive’s later work likewise emphasized that compromised robots could be used for cyber espionage or to expose private information.
The industry pattern
The DJI Romo case is not the only example of consumer robot security failures. In 2024, security researchers demonstrated at DEF CON that certain Ecovacs robot vacuums and mowers could be accessed through Bluetooth and manipulated to activate microphones and cameras. The researchers reported that attackers could potentially read Wi-Fi credentials and stored room maps, with a practical Bluetooth range of up to about 130 meters before a robot’s internet connection could extend control farther. PCWorld summarized the findings at PCWorld: These smart vacuums and mowers can be hacked to spy on you.
Other reported cases have involved camera-equipped vacuums and household devices where weak PIN validation, exposed video streams or incomplete patches created privacy and control risks. The recurring theme is not a single broken protocol but a product model in which sensing, cloud services and remote operation are added faster than rigorous access controls are verified.
Recent academic work on robotic systems in Internet of Things environments also highlights risks at the network and device layers, including denial-of-service attacks against camera modules, spoofing of sensors and authentication failures affecting actuators. Experimental validation on an AlphaBot platform demonstrated that a flooding-based denial-of-service attack against its camera module was feasible. The study is published at PMC: Robotic systems in Internet of Things.
What vendors must fix
Security-by-design requires more than adding a password prompt to a mobile app. For household robots, the highest-impact controls are likely to be granular authorization, device isolation, secure over-the-air updates, signed firmware, audit logging and limits on what data leaves the home.
- Enforce per-device, per-user authorization at the cloud and application layers, not only in the companion app.
- Prevent wildcard subscriptions or broad topic access in message brokers such as MQTT.
- Require authenticated, signed firmware updates and publish clear patch timelines.
- Minimize cloud retention of video, audio and maps, with local processing where feasible.
- Conduct independent penetration testing before launch and after major architecture changes.
- Give users meaningful controls over cameras, microphones, cloud uploads and data deletion.
IOActive has recommended that robot makers adopt a Secure Software Development Life Cycle, encryption and security audits. Those measures address parts of the problem, but the DJI Romo case suggests that authorization design deserves equal attention: an encrypted channel to a poorly partitioned cloud broker can still leak data at fleet scale.
What users can do now
Consumers cannot redesign a robot’s cloud architecture, but they can reduce exposure. Buyers should check whether a device supports regular security updates, whether camera and microphone access can be disabled, and whether the vendor explains what data is stored and for how long.
- Change default passwords and use a unique account password with multi-factor authentication where available.
- Install firmware and app updates promptly.
- Disable remote camera or microphone features when they are not needed.
- Place camera-equipped robots away from bedrooms and other sensitive areas when practical.
- Review app permissions and remove access for accounts or phones no longer in use.
- Use a separate guest or IoT network for smart devices where the router supports it.
The next 12 to 24 months
Over the next two years, the pressure on robot makers will likely increase as household machines become more autonomous and more capable of acting on voice commands, visual context and learned routines. The more a robot can decide where to go, what to record and which appliances or locks to interact with, the more consequential a security failure becomes.
The central challenge is architectural. Vendors will need to move from reactive patching toward isolated device identities, least-privilege cloud access, local processing for sensitive sensor data and verifiable safety controls. Until then, the practical assumption for consumers should be cautious: a connected robot with a camera, microphone and cloud account is not merely an appliance—it is a mobile sensor platform inside the home.
Primary sources: IOActive, IOActive research paper, Yahoo Tech, PCWorld, University of Washington, and PMC.
