DJI Romo Case: When Firmware Architecture Becomes a Cybersecurity Headline

Disclaimer: The following analysis is based on publicly available reporting, security research disclosures, and our team’s expert interpretation of the technical patterns described. We have no inside knowledge of DJI’s internal engineering processes. Where we describe decisions or motivations, these reflect our professional assessment of what the evidence suggests, not verified facts.

In late 2024, a hobbyist reverse-engineered the DJI Romo robot vacuum app, built a custom MQTT client using his own legitimate authentication token, and within minutes was watching telemetry from roughly 7,000 active Romo devices across dozens of countries, including floor maps, cleaning states, and pathways to live camera feeds.

Headlines called it a hack. Security commentators labeled it a cloud vulnerability. Both framings are partially true and almost entirely misleading.

This was not a cybersecurity failure that slipped past a diligent engineering team. It was an architectural decision, made months before launch in the embedded and backend design phase, that created systemic risk for every device in the fleet. The security function failed to catch it, but it did not cause it.

If you’re in firmware or backend engineering and your takeaway is “this is a cloud config bug,” you’re already missing the real lesson. If you’re a CTO and your takeaway is “we need more penetration testing,” you’re looking at the wrong stage of the pipeline.

Before the Technical Detail: The Accountability Question

For CTOs and engineering leaders: if you’re a firmware or security engineer, skip to the next section; your detail is below.

Two org-level questions matter more than any technical detail here:

• Who formally asks, “What can an authenticated user do that they should not be able to do?” If the answer is “the penetration tester before launch,” the process is already too late. By that stage, the MQTT topology is frozen, the broker configuration is deployed, and fixing tenant isolation requires a re-architecture project nobody wants to schedule.
• Who owns the trust boundary between your device identity model and your cloud infrastructure? If the answer is “security reviews it at the end,” the real answer is nobody owns it during design.

The technical failure at DJI Romo was the symptom. The org design failure was the disease.

What Actually Happened

MQTT is a lightweight publish/subscribe protocol standard in IoT: devices publish status to a broker; apps subscribe to receive it. Think of it as a message bus where topics are named channels. A device publishes to `devices/ABC123/status`, and the owner’s app subscribes to that exact topic to receive updates.

The DJI Romo connects to DJI’s cloud-hosted MQTT broker and publishes status every few seconds: serial number, cleaning state, obstacle data, battery level, floor map data, and in some configurations, media stream metadata.

The authentication layer worked exactly as designed. The hobbyist’s token was valid. TLS was in place. By the conventional checklist of “is this connection secure,” DJI Romo passed.

The problem was what happened after authentication. The broker did not restrict which topics an authenticated client could subscribe to. Wildcard subscriptions, the MQTT equivalent of `SELECT * FROM devices` rather than `WHERE device_id = mine`, were unrestricted. Device serial numbers were sequential, making enumeration trivial. The result: any authenticated user could receive telemetry for the entire fleet, not just their own device.

This is Broken Object Level Authorization (BOLA): the system verified who you are, but never asked what you are allowed to see. Authentication and authorization are not the same control, and treating them as if they are is the error at the center of this incident.

DJI framed their fix as resolving a “permission validation issue.” That language implies a configuration someone forgot to check. It was an architectural pattern that was never safe to ship.

For security engineers: BOLA on a shared MQTT broker should appear in any IoT threat model under “authenticated insider abuse.” Its absence from DJI’s internal review is as significant as the vulnerability itself.

Where the Real Decision Was Made

MQTT topic schemes are not a security team’s call. They are an architectural decision owned by the backend and embedded teams designing the device-to-cloud communication layer, made months before any penetration tester received the product.

The pattern is familiar to anyone who has built IoT infrastructure under delivery pressure. Development environments need full visibility: you want to watch all device traffic when debugging, wildcard subscriptions are enormously useful in staging, and sequential device IDs make local testing simple.

This was never a configuration bug. It was a debug-era architecture that shipped as a product.

At some point, that topology got promoted toward production, and the question, “Should an authenticated customer be able to subscribe to everyone else’s device topics?” either never got asked, got deferred, or got answered with “we have TLS and tokens, so we’re covered.”

One compounding factor: because all device control and media access flowed through a single central broker rather than any local-first model, a single ACL gap created simultaneous exposure for thousands of homes. The blast radius of a trust boundary failure scales directly with architectural centralization.

For firmware engineers: the trust boundary between your device identity model and the broker’s topic namespace is a security boundary. It deserves the same design rigor as your hardware root of trust or your OTA signing chain.

What Correct Looks Like

The fix is not exotic. A correctly designed multi-tenant MQTT infrastructure enforces these controls at the broker layer, not the application layer, and each one maps directly to a decision the architecture team owns:

• Per-device topic isolation: an authenticated token may only publish to and subscribe from topics scoped to its own device identifier. Wildcards across device namespaces are rejected at the broker by default.
• Non-enumerable device identifiers: serial numbers in topic structures must not be sequential or guessable. UUIDs or cryptographic identifiers are the baseline.
• Least-privilege by default: consumer-facing tokens carry minimal scope. Diagnostic or fleet-management access requires a separate, explicitly elevated credential class.
• Separated media authorization: streaming credentials (WebRTC, RTSP) must re-authenticate independently from the MQTT session. Broker-level trust is not inherited by media services.

None of these are advanced controls. They are basic isolation principles that should be legible in any architecture review. What makes them easy to miss is that they require asking an adversarial question during design: not “does the happy path work?” but “what is the worst thing a legitimate user can do?”

At PerformaCode, that question is not a checklist item at the end of a project. It is the first design constraint we apply when defining the device-to-cloud trust model, before a broker topology is chosen, before a topic scheme is sketched, before a line of firmware is written.

Why Security Didn’t Catch It

The security team’s job is precisely to surface the mistakes that engineers make under delivery pressure. In that sense, the security function failed here, too. But the failure mode matters.

A basic IoT security test plan should include wildcard MQTT subscription attempts, horizontal access across device identifiers, and enumeration of sequential IDs. A hobbyist found all of this in minutes with standard tooling. That means one of three things was true internally: the test plan did not cover these scenarios, findings were not acted on, or a formal security review did not happen at all.

The more structural problem, common across embedded and IoT organizations, is that security teams arrive too late. By the time a penetration tester receives the product, the broker topology is frozen in production infrastructure, and the device authentication model is baked into certified firmware. The security team can document problems. It usually cannot fix the architectural decisions that caused them without a re-architecture project that nobody wants to own post-launch.

Security review at the end of the pipeline is quality control. Threat modeling at the beginning is quality assurance. The DJI Romo case required the latter and received neither.

For security engineers: being brought in late is a structural problem, not a resourcing one. The conversation to have with engineering leadership is not “we need more time to test.” It is “we need to be in the architecture review before the broker topology is decided.”

The Broader Point

The DJI Romo case will be catalogued as a privacy and security failure. It should also be understood as a case study in the cost of designing IoT architecture entirely for the happy path, without a single formal exercise in adversarial reasoning before the product ships.

The fix does not live primarily in more penetration testing. It lives upstream: in the architecture phase, where firmware and backend engineers decide how devices identify themselves, how tenants are isolated, and where trust boundaries sit in a shared cloud infrastructure.

Those decisions are made once. They are expensive to undo.

That decision lives where firmware architecture, cloud topology, and trust boundaries are drawn, not in the final security checklist.

The DJI Romo case was decided long before any hacker arrived. So is yours.

Disclaimer: This analysis reflects PerformaCode’s reading of publicly available sources and our experience building connected device firmware, not access to DJI’s internal systems or processes.