Hacking 7,000 Robot Vacuums by Accident Exposes IoT Security Vulnerabilities: How SEALSQ Can Fix It

The Accidental Hacking of 7,000 Robot Vacuums proves that manufacturers are still shipping IoT-enabled products with serious security vulnerabilities

Sammy Azdoufal just wanted to steer his new DJI Romo robot vacuum with a video game controller. While building his own remote-control app with the help of an AI coding assistant, he reverse-engineered how the vacuum communicated with DJI's cloud servers in order to extract an authentication token. That token, it turned out, worked for rather more than just his own device.

The same credentials that allowed him to see and control his own device also provided access to live camera feeds, microphone audio, maps, and status data from nearly 7,000 other DJI Romo vacuums across 24 countries. With that access, he could view real-time video from inside people's homes, activate microphones, and compile 2D floor plans of the buildings the vacuums were cleaning. He could also identify approximate locations from the devices' IP addresses.

Admirably, Azdoufal did not exploit the access. He reported his findings to The Verge, which contacted DJI, and the vulnerability was patched. But the incident made headlines precisely because it illustrated something that cybersecurity professionals have been warning about for years: the IoT industry has a deeply ingrained habit of treating security as an afterthought, rather than a critical feature that should be built into the silicon from the outset.

The DJI case is instructive not just because of what went wrong, but because the specific failures it exposes are the tip of a very big iceberg. By recent estimates there are approximately 22 billion IoT devices globally (at time of writing Feb 2026) - so even a small fraction of these having basic vulnerabilities leaves many millions of households at risk of serious privacy breaches. Fortunately, the solutions to all of these flaws exist today, in hardware, at a cost and complexity level that any product team can justify.

What Actually Went Wrong – The Four Vulnerabilities

SEALSQ, the specialist digital identity and secure element manufacturer whose VaultIC devices are distributed by Ineltek in the UK, analysed the reported failures and identified four distinct security breakdowns that contributed to the breach.

Credentials

The first and most significant was the use of identical credentials across all devices. Rather than issuing each DJI Romo with a unique cryptographic identity, the authentication architecture apparently relied on shared credentials that, once compromised for one device, provided access to the entire fleet. This is not a DJI-specific problem. It is arguably the most common single security error in connected consumer electronics, driven by the operational simplicity of not running a per-device key provisioning process during manufacturing.

Pin Bypass

The second failure was a PIN bypass on the camera system, which meant that even a secondary layer of access control could be circumvented without knowledge of the device owner's credentials.

Poor firmware update protocol

The third was the possibility of loading rogue firmware onto a device indicating that firmware update processes were not protected by cryptographic signature verification. This means that potentially harmful software of completely arbitrary origin can and was executed on the vulnerable hardware.

Undisclosed

A fourth category of vulnerabilities, not fully disclosed in public reporting at the time of writing, remains under investigation.

Together, these failures describe a device that had no reliable way to prove its own identity to a server, no way to establish that a secure session was genuinely with its rightful owner, and no way to verify that the firmware it was running had been issued and authorised by the manufacturer. These are not obscure or difficult problems. They are precisely what hardware secure elements are designed to solve.

What SEALSQ VaultIC Secure Elements Would Have Done Differently

The VaultIC292 and VaultIC408 are tamper-resistant secure microcontrollers from SEALSQ, designed to provide connected devices with the cryptographic foundation that the DJI Romo demonstrably lacked. Understanding how they address each failure mode makes the case clearly.

Unique device identity and per-device TLS sessions

The fundamental requirement for IoT security is that every device has a unique, verifiable identity that cannot be cloned or shared. The VaultIC292 is specifically designed to provide exactly this: each chip contains a unique ECC P-256 key pair and X.509 certificate, provisioned during SEALSQ's certified production process under the VaultiTrust service. When the device communicates with a cloud server, it presents its certificate to establish a unique TLS 1.3 session that is cryptographically bound to that specific device alone. Gaining the credentials of one device provides access to nothing else on the network. The shared-credential vulnerability is structurally impossible when each device has its own certificate.

Critically for manufacturers, this does not require establishing a secure production environment. SEALSQ can deliver VaultIC chips pre-provisioned with unique digital identities and birth certificates, tailored for connection to AWS, Azure, or a private cloud platform. DJI's existing production lines and EMS partners would not need to change their processes at all.

Hardware-enforced firmware signature verification

Rogue firmware attacks rely on the ability to push unsigned software to a device without detection. VaultIC secure elements address this through cryptographic code signing and verification: firmware updates are signed by the manufacturer's private key, and the secure element verifies that signature before any update is accepted. Without a valid signature from an authorised key – which exists only in the manufacturer's secure environment – the device rejects the update entirely. The key material that makes this possible lives inside the tamper-resistant hardware of the secure element, protected against side-channel attacks, physical probing, and voltage/temperature manipulation by dedicated hardware countermeasures. It cannot be extracted by software and cannot be copied from one device to another.

Access control that cannot be bypassed in software

The PIN bypass in the DJI case represents a failure of software-only access control: when authentication logic runs on a general-purpose processor, it can in principle be circumvented by someone with sufficient knowledge of the software stack. VaultIC secure elements move authentication logic into hardware that executes independently of the host processor, in a security domain that the host application cannot manipulate. Challenge-response authentication on the VaultIC408, for example, uses ECDSA digital signatures that require possession of the device's private key – a key that never leaves the secure element and cannot be extracted even if the host MCU is fully compromised.

VaultIC292 and VaultIC408 – Which Fits Your Design?

SEALSQ offers two VaultIC products suited to the IoT authentication use case, with the choice driven principally by required cryptographic capability and interface preference.

Feature	VaultIC292	VaultIC408
Primary Use Case	Secure TLS identity, firmware verification, USB-C and QI auth	Full-featured secure storage, advanced authentication, IP protection
Cryptographic Algorithms	ECC NIST P-256 (ECDSA, ECDH)	AES 128/192/256, RSA up to 2048-bit, ECC up to 576-bit, GCM/GMAC
Memory	1,680 bytes NVM (5 key pairs + 2 X.509 certificates)	Up to 16kB EEPROM file system
Communication Interface	I2C (up to 100kHz)	SPI and I2C
Security Certification	EAL5+ ready hardware	EAL5+ ready hardware; FIPS 140-3 Level 3 CMVP (v1.2.x)
Pre-Provisioning Service	VaultiTrust – unique identity, AWS/Azure/private cloud ready	VaultiTrust – unique identity, AWS/Azure/private cloud ready
Package	DFN-6 (2x3mm), UDFN-8 (2x3mm)	SOIC-8 (5x8mm), QFN-20 (4x4mm)
Supply Voltage	1.62V to 5.5V	1.62V to 5.5V
Operating Temperature	-40°C to +105°C	-40°C to +105°C

For a connected consumer or industrial IoT device primarily requiring unique device identity, TLS session establishment, and firmware signature verification – the exact failure modes exposed in the DJI case – the VaultIC292 is the appropriate solution. Its small package, simple I2C interface, and pre-provisioning capability make it straightforward to integrate into new designs or retrofit into existing products with minimal bill-of-materials impact.

The VaultIC408 suits applications requiring broader cryptographic services: full AES encryption, RSA-based authentication, role-based access control, and secure file storage for more complex identity and entitlement management scenarios. Both products are built on the same silicon heritage as national ID cards, e-passports, bank cards, and SIM cards; the applications where security has been pressure-tested most rigorously for the longest time.

Industry Applications – Where These Vulnerabilities Are Hiding

The failures exposed in the DJI case are far from unique to premium consumer robotics. The same architecture – shared credentials, unsigned firmware, software-only access control – is replicated across categories including smart energy meters (where firmware integrity is a regulatory requirement under UK Smart Metering Implementation Programme standards), industrial IoT sensors (where device authentication is required under IEC 62443), IP cameras and surveillance systems, medical remote monitoring devices, and connected automotive accessories. Any product that connects to a cloud back-end, accepts over-the-air firmware updates, or handles data that an attacker would find valuable is a candidate for the same class of attack.

The commercial argument for addressing this at the silicon level rather than through software patches is straightforward: a software authentication mechanism can be bypassed by someone who controls the host processor; a hardware secure element cannot be compromised even if the host is fully owned. And the cost of adding a VaultIC292 to a product BOM is a small fraction of the cost of a single product recall, a regulatory investigation, or the reputational damage of appearing in mainstream technology news as the device whose security failed catastrophically.

Conclusion – One Accidental Hack Tells the Whole IoT Security Story

The DJI robot vacuum story ended well because Sammy Azdoufal turned out to be curious rather than malicious. Not every discoverer of a vulnerability will make the same choice. As AI coding tools lower the barrier to reverse-engineering device protocols, and as the installed base of inadequately secured IoT hardware continues to grow, the number of people capable of finding and exploiting these vulnerabilities is increasing faster than the industry is fixing them.

The good news is that the technical solution is not complex, it is not expensive, and it does not require manufacturers to redesign their products or rebuild their production processes. A secure element like the VaultIC292 or VaultIC408 integrates into existing designs over a standard I2C or SPI interface, arrives pre-provisioned with unique device identities through the VaultiTrust service, and closes the specific vulnerabilities that turn a fleet of robot vacuums into a surveillance network.

Ineltek distributes SEALSQ's VaultIC portfolio across the UK and Europe. To discuss your design requirements, request samples, or arrange a meeting with SEALSQ and Ineltek at Embedded World 2026, contact us now. SEALSQ can be found in Hall 5 at Stand 178.

---

FAQs - IoT Secure Elements

Q. What specific vulnerabilities does a secure element like VaultIC292 address in a connected IoT product?

A. A secure element addresses three of the most common IoT vulnerability classes: the use of shared device credentials (by providing every device with a unique cryptographic identity and certificate), software-only access control bypasses (by executing authentication logic in tamper-resistant hardware independent of the host processor), and rogue firmware installation (by requiring all firmware updates to carry a valid cryptographic signature before execution). These three classes account for the majority of publicly disclosed IoT breach incidents, including the February 2026 DJI Romo case.

Q. Does adding a VaultIC secure element to a product require changes to the existing production line?

A. Not necessarily. SEALSQ's VaultiTrust service delivers VaultIC292 chips pre-provisioned with unique device identities and X.509 certificates configured for AWS, Azure, or a private cloud. The manufacturer's existing production line and EMS partners do not need a separate secure provisioning process.

Q. What is the difference between the VaultIC292 and VaultIC408?

A. The VaultIC292 is optimised for TLS and MATTER device identity, firmware signature verification, and simple I2C integration in a compact DFN-6 or UDFN-8 package. The VaultIC408 provides a broader cryptographic service set including AES-256, RSA-2048, role-based access control, and a 16kB secure file system, making it suitable for more complex authentication and secure storage requirements. Both are EAL5+ ready and VaultIC408 is certified FIPS 140-3 CMVP. Both support industrial temperature ranges.

Q. Why is hardware-based IoT security more effective than software-only approaches?

A. Software authentication mechanisms can be bypassed by an attacker who controls or has compromised the host processor. A hardware secure element executes its cryptographic operations in an isolated security domain that cannot be manipulated by the host application, even if the host is fully compromised. Private keys stored in a secure element cannot be extracted via software attacks, side-channel analysis, or physical probing, making the root of trust genuinely tamper-resistant rather than merely difficult to attack.