Inside the DJI Trust Center

A penetration tester’s read of the published “security audits & certifications” — what the reports actually say versus how they are sold

Independent review of the items linked from dji.com/trust-center/resource/security-audits-certification, plus the DJI Drone Security White Paper v3.1 (2025), the DOI flight-test report and FAQ, the OnDefend attack-simulation data sheet, and both the 3-page summary and 27-page full versions of the 2018 Kivu report. All primary documents are included in the accompanying archive.

Prepared as an analysis companion to the document archive • Compiled 2026

First, the disclaimer the vendor’s own tester puts in writing

Before a single DJI finding is discussed, start where the testers themselves start. OnDefend — the firm behind DJI’s flagship 2026 assessment and the one DJI leans on hardest for “national security” framing — devotes a section of its own Attack Simulation Testing info guide to the heading “A Snapshot In Time”, and states plainly:

“Security tests are a snapshot which provide detailed information on what an attacker can do once they take advantage of that first vulnerability. Enterprises are like living things, always changing as new systems come online, upgrades to applications are made, infrastructure changes are made… and patches are released. New vulnerabilities are announced every day, meaning that a system that is fully patched and secure today may not be tomorrow. As such, security testing needs to be a continuous process, not just a single effort completed every once in a while.”

That is the whole ballgame, conceded by the practitioner. A penetration test — any penetration test — is a measurement of one specific product, in one specific firmware/software version, in one specific configuration, inside one specific time-boxed window. It is evidence about that snapshot and nothing else. It does not, and cannot, underwrite a sweeping claim that a product line is “secure,” or that it poses no “national security” risk — past, present, or future. The moment the next firmware ships, the moment the next CVE lands, the moment a different model rolls off the line, the snapshot is stale by the tester’s own admission.

Every document in this archive is a snapshot. Read against that single sentence, the gap between what the reports measured and what the marketing claims they proved is the entire subject of this report.

The “puppy-mill” pattern

Anyone who has spent years in this trade recognizes the shape of a commodity engagement: client infrastructure (and a check) goes in one end; a reassuring, checkbox-shaped report comes out the other. The scope is drawn by the client. The window is short. The ugly findings get quietly remediated before the final draft. The deliverable is written to be quotable, not to be adversarial. None of that makes the testers incompetent or dishonest – several of these reports are technically careful. It makes the output a marketing asset, and a marketing asset is exactly what a trust page is built from.

Across the DJI portfolio the same five moves recur:

■ Scope it narrow. A network-traffic-only review; a single drone; one firmware build; a cloud product’s management system; in three cases, a robot vacuum cleaner.

■ Define the scary question in the vendor’s favor. “No first-party data left the US,” measured from a US vantage point — quietly sidestepping third-party egress and server-side behavior.

■ Control the unit or the build. Vendor-supplied hardware, or a bespoke “Government Edition” engineered specifically not to phone home.

■ Remediate mid-engagement, then omit. The worst findings are fixed during the test and reframed as “no longer a vulnerability” before the public ever sees them.

■ Publish the summary, withhold the report. The glossy executive summary circulates; the full report stays “confidential & proprietary,” behind a dead link, or as an un-searchable scan.

The throughline, stated once: each report answers the smallest, most controllable version of “is DJI safe?” and the marketing presents it as the largest.

Time-boxing and scope limitations, in the reports’ own words

These are not inferences. The limiting language is printed in the documents:

Every one of these is a legitimate, defensible engagement at its stated scope. The problem is never the testing. The problem is the translation from “we observed X under conditions Y for window Z” into the trust page’s “independently validated — secure.”

What the “audits & certifications” actually are

Counting carefully, the headline number is padded. Of the items DJI lists:

■ 2 are ISO management-system certs (27001 / 27701) scoped only to DJI FlightHub 2, a single cloud product —not the drones, apps, or firmware. (The white paper’s own footnotes concede FlightHub 2 lacked MFA until Q3 2025 and has no RASP — you can be ISO-certified and still ship enterprise cloud without multi-factor auth.)

■ 3 are certs for the DJI ROMO robotic vacuum cleaner (models CR8E/CR8F) — ETSI EN 303 645 (TÜV SÜD), UL IoT “Diamond,” and EU RED (TÜV Rheinland). A vacuum, listed on a drone trust page.

■ FIPS 140-2 is the generic NIST/CSE consolidated certificate page; the validated item is the “DJI Core Crypto Engine” at CMVP Level 1 — the lowest of four tiers (approved algorithms; essentially no physical tamper-resistance). Booz Allen separately found the datalink crypto was not FIPS-validated.

■ SOC 2 (2017) is listed with no document at all — a claim, not an artifact.

■ FTI 2020 is a dead link (HTTP 404) on DJI’s own site — recovered here from the Wayback Machine.

■ INL 2019 is published as a flat image scan with no text layer — the one report you cannot search or
quote-check without OCR (included here).

That leaves a genuinely substantive core — OnDefend (2026), FTI (2024 & 2020), Booz Allen (2020), INL (2019), DOI (2019), Kivu (2018) — all of which are real network/RF/data-flow tests, and none of which claims what the trust page implies. (The Kivu 2018 report — long cited but not on the current download list — is included in this archive in both its 3-page summary and 27-page full forms; see the case study below.)

How “no data goes to China” is actually worded

Every report says some version of it. Read the qualifier each time — the load-bearing words are in bold:

■ FTI: “all first-party data transmissions, or transmissions to DJI owned infrastructure, resided within the United States.” Third-party egress (NTP→Germany, u-blox→Ireland, Akamai/Adjust→Germany) is acknowledged and set aside.

■ FTI: data “appeared to resolve to IP addresses located primarily within the United States,” collection done “on the East Coast of the United States” — geo-IP from a US vantage point, not server-side truth.

■ OnDefend: connections resolved to US endpoints “including content-delivery infrastructure associated with Alibaba and Tencent”; recommends DJI “migrate services to infrastructure that is more consistently identified as US-based” — i.e. attribution was ambiguous.

■ Booz Allen: “It is very difficult to verify custodianship of any data when using cloud based services; however, our limited testing… showed no evidence of connections to China.”

■ INL: “At a glance, the four platforms… do not appear to be leaking any data,” and “No data leakage was found…
but that does not mean it cannot happen.”

■ Kivu (2018): the GO 4 code uses conditional US/China server selection — “when a drone is operated in China, the application is designed to use different domains and access different APIs.” SkyPixel uploads go to Alibaba Cloud (US-located). The app also queried apilocate.amap.com (AutoNavi/Alibaba) — resolving to a US IP.

This is textbook absence-of-evidence presented as evidence-of-absence — measured inside a box specifically shaped so the evidence would be hard to find (US vantage point; shielded chamber; US-only testing; the network-neutered GE build).

The “Government Edition” story the press release deletes

Three documents (Booz Allen, INL, DOI) plus DOI’s own FAQ tell a coherent arc that the July 9, 2019 DJI press release — “U.S. Federal Agency Validates And Approves DJI’s High-Security Solution” — compresses into a product launch:

■ A prior cyber test found a real data leak in stock DJI (DOI FAQ: a partner “successfully identified a data leak”).That leak is why GE exists.

■ DJI and DOI co-built a locked-down, offline, government-only edition (permanent Local Data Mode, restricted hardware pairing, no Wi-Fi, no over-the-air updates).

■ That bespoke build was validated by partners — one of whom (INL) asked to remain unnamed, yet later became a named “Idaho National Laboratory” trust-badge.

■ It was approved narrowly: two models, GE config only, non-sensitive / publicly-releasable data only, no updates without re-validation, explicitly an interim fix.

■ The press release keeps “validated and approved” and the line “Government Edition… can never be intentionally or accidentally shared” — an absolute that OnDefend’s 2026 test later empirically contradicted (egress detected with Local Data Mode enabled).

Crucial fairness point: the DOI report DJI hosts is byte-for-byte identical to the government’s own archived copy (verified by content hash). DJI did not doctor the evidence. The distortion lives entirely in the summary layer — the press release and white paper that describe the report.

Case study: the Kivu “independent study” in four versions

The 2018 Kivu engagement is the single best illustration of how one piece of work broadens as it travels from the full report to the trust-page one-liner. The same engagement exists in four forms, and each strips something the last one disclosed:

■ (1) The full report (27 pp, Feb 13 2018). Cover page: “Prepared For: McDermott Will & Emery LLP.” Page 2:
“Kivu… was retained by McDermott Will & Emery LLP (‘MWE’) on behalf of its client, SZ DJI.” The study was
commissioned through DJI’s outside law firm — the classic structure that wraps a security review in
attorney-client/work-product privilege, so an unfavorable result could lawfully have been buried and never seen
daylight.

■ (2) The summary letter (3 pp, Feb 14 2018). Same findings, reformatted as a letter addressed directly to “DJI
Research LLC, Palo Alto” — the law-firm client relationship and the privilege wrapper have vanished. It now
reads as Kivu writing straight to DJI.

■ (3) The DJI press release (Apr 23 2018): “Independent Study Validates DJI Data Security Practices,”
asserting “DJI had no input into Kivu’s findings or conclusions.” True of the findings — while omitting that DJI’s
lawyers commissioned and scoped the engagement and DJI funded it.

■ (4) The current Trust Center / white-paper entry shrinks it to: Kivu “reviewed DJI’s data security practices and concluded that DJI is capable of protecting users’ personal data.” That is broader and vaguer than anything Kivu wrote. Kivu’s actual conclusion was narrow and conditional: “users have control over the types of data DJI drones collect, store, and transmit” — a statement about user-toggleable settings, not a clean bill of health.

What the full report contains that the gloss drops:

■ Scope is narrow and point-in-time: four consumer drones (Spark, Mavic Pro, Phantom 4 Pro, Inspire 2), GO 4 app v4.1.22, tested only in the United States, early 2018. (To Kivu’s credit, units were independently purchased — but DJI provided engineer access in Palo Alto and Shenzhen plus the GO 4 source repositories.)

■ Mid-engagement remediation (the recurring pattern): “Kivu identified certain potential vulnerabilities and immediately notified DJI… worked with DJI to complete the recommended steps and then validated the remediation.” Found, fixed, and closed before publication.

■ A real breach, folded into a reassuring line: Kivu acknowledges DJI AWS data “was recently and inadvertently made publicly available” (the 2017 exposure) and notes DJI “corrected this issue.”

■ Buried technical detail absent from the summary: when uploading flight logs, “The AWS bucket, credential, and user access controls are encoded, but not encrypted, when sent.” And on app launch a file “10A” was extracted that “identifies the operating system of the mobile device and the SSID of the connected Wi-Fi network.”

■ Genuine clearances worth stating: Kivu confirmed the drones do not use facial recognition, do not record onboard audio, and do not auto-upload media or flight logs without user action.

Credit where due: Kivu independently bought the hardware, found and drove real fixes, and cleared facial recognition and silent media upload. But the engagement was commissioned through DJI’s law firm under privilege, remediated mid-stream, and US-only at a 2018 snapshot — and by the time it reaches the trust page it has become the unqualified “capable of protecting users’ personal data.” Four versions; each one a little broader and a little less encumbered than the evidence underneath.

Mid-engagement cleanup — the “retest” tell

Booz Allen 2020 is the clearest specimen. The report carries explicit “Initial Testing” and “Retest” columns. Mid-engagement (Feb 2020) the vendor supplied software updates, after which the two most damaging findings — a “government edition” drone reaching commercial infrastructure and pulling a non-GE firmware build over the internet (#7, #8) — were downgraded to “no longer considered a vulnerability.” Everything else got “N/A” on retest: the Triple-DES/AES-128 non-FIPS datalink crypto, no data-at-rest encryption, no remote zeroization, USB multimode attack surface, and an anonymous-capable FTP service were never re-examined. OnDefend 2026 runs the same play more politely: a default shared Wi-Fi password “identified and patched by DJI via firmware update” during the engagement. Kivu 2018 did the same — vulnerabilities “immediately notified” to DJI, “remediated,” and “validated” before the report shipped. Across three vendors, a decade apart, the worst findings are consistently
closed off-page before the public summary exists.

Bottom line

This is not a body of adversarial, independent research that clears DJI of “national security” concerns. It is a curated compliance portfolio with good production values. The methodologies are largely genuine; the engineering DJI documents (TEE, secure boot, AES-256-XTS media encryption, per-device certificates) is real. But as a trust instrument the portfolio does one job: it takes a stack of narrow, time-boxed, scope-limited snapshots — several of a sanitized build, three of a vacuum, two of a cloud SaaS, one behind a dead link, one un-searchable, one commissioned under legal privilege — and presents them as a standing guarantee.

By the standard OnDefend itself prints, that guarantee cannot exist. Security tests are “a snapshot,” and “a system that is fully patched and secure today may not be tomorrow.” A test speaks to a product, a version, a configuration, a window — and to nothing else.

Any claim that these documents establish DJI is, was, or will be free of national-security risk is a claim the testers expressly disclaim. The honest reading is narrower and more useful: under specific, vendor-shaped conditions, specific snapshots showed no obvious first-party exfiltration — and the careful, qualifying sentences that say exactly that are the ones the marketing leaves out.

Note on neutrality. None of this demonstrates that DJI does exfiltrate data or contain a backdoor — the documents don’t show that
either, and the primary government sources are careful to say origin alone is not proof of risk (DOI: treat all technology as a potential risk regardless of where it is made). The finding is about the framing gap, not a verdict on the hardware.