DJI's new security audit is useful evidence. It is not procurement clearance.
On 2026-05-28, DJI released findings from an independent assessment by U.S. cybersecurity firm OnDefend. The tested systems were specific: DJI Air 3S with RC 2, and DJI Matrice 4E with RC Plus 2 Enterprise. According to DJI's announcement, OnDefend found zero critical, high, or medium-risk findings across software, hardware, firmware, and radio-frequency testing.
That is materially better than another vendor white paper. The OnDefend executive report adds details that procurement teams can actually use: test dates, unit sourcing, tested controllers and apps, Local Data Mode behavior, radio-frequency scope, low-risk findings, and a recommendation for continuous validation.
But the audit does not remove DJI from the FCC Covered List debate. It does not override CISA/FBI warnings for critical infrastructure operators. It does not guarantee future firmware behavior. It does not make every DJI model equivalent to the Matrice 4E.
For buyers already weighing dji-ban-alternatives-enterprise-buyers and dji-firmware-waiver-2029-enterprise-fleets, the question is not "Did the audit prove DJI is safe?" The better question is: "Which claims can I now support in a procurement file, and which risks still need a policy decision?"
Quick Answer
| Buyer decision | What changed after the audit | What did not change |
|---|---|---|
| Existing fleet operation | Buyers now have model-specific evidence that no major technical findings were observed in the tested systems | Customer rules, agency bans, grant conditions, and critical-infrastructure policies still apply |
| Matrice 4E exception request | The Matrice 4E and RC Plus 2 were in scope, making the audit directly relevant | The exception must still name firmware, app, mission, data controls, and exclusions |
| New DJI procurement | The audit improves the technical evidence file | It does not create normal procurement clearance or remove Covered List exposure |
| Alternative evaluation | The audit raises the evidentiary bar for both DJI and non-DJI vendors | Buyers still need cost, training, payload, repair, and policy-risk comparisons |
What OnDefend Actually Tested
The audit was not a general review of every DJI product. It was a five-month engagement from 2025-10-21 to 2026-03-13, covering two units of each tested drone model across controlled indoor and outdoor environments. DJI says consumer units were purchased from retail outlets without pre-notification, while enterprise units were sourced from existing dealer stock.
That sourcing detail matters. It reduces the easy objection that DJI handed the auditor specially prepared units. It does not eliminate sponsor bias, because DJI authorized and funded the engagement, and the report is distributed through a DJI-hosted asset path. Buyers should acknowledge both facts.
The right sentence is not "independent audit proves DJI is safe." The right sentence is: "A DJI-authorized independent audit, using retail and dealer-stock units, found no major technical findings in two named systems during a defined testing window." That wording is less dramatic, but much more defensible.
For enterprise buyers, defensible language matters because the audit will be read by people with different incentives. Drone operators will focus on mission continuity. IT security will focus on data and firmware. Legal will focus on procurement exposure. Public-sector buyers will focus on whether the audit can survive a board, council, or grant review. The recommendation here is therefore deliberately narrow: cite the audit, but cite it with scope and caveats attached.
| Audit element | Scope |
|---|---|
| Drones | DJI Air 3S and DJI Matrice 4E |
| Controllers | RC 2 and RC Plus 2 Enterprise |
| Apps | DJI Fly and DJI Pilot 2 |
| Software testing | Static/dynamic app testing, certificate bypass, traffic analysis, jailbreak and privilege escalation attempts |
| Hardware/RF testing | PCB-level teardown, component analysis, supply-chain integrity review, 1 MHz to 6 GHz RF scanning |
| Operational states | Standard mode and Local Data Mode, across pre-flight, flight, and post-flight behavior |
Source: DJI announcement and OnDefend executive report.
The report is therefore most useful when a buyer can say: our aircraft, controller, app, firmware, data settings, and mission profile are close to the tested scope. The farther the buyer moves away from that scope, the weaker the audit becomes as evidence.
The Evidence Ladder
The cleanest way to use the audit is to grade claims by strength.
| Claim | Evidence strength | Buyer interpretation |
|---|---|---|
| OnDefend did not find hidden backdoors, non-U.S. data transmission, viable hijacking paths, or weaponization paths in the tested Air 3S and Matrice 4E systems | Strong within tested scope | Useful in a technical risk memo |
| Local Data Mode prevented user data from leaving the DJI flight-control application during testing | Strong, with caveat | Useful only if buyers also control controller network behavior |
| The tested systems had no critical, high, or medium-risk findings | Strong within test window | Does not mean there were no findings |
| The ten low-risk findings do not create a realistic widespread exposure under normal operation | Moderate | Still convert them into controls and follow-up questions |
| DJI products broadly are safe for all enterprise missions | Not supported | Scope is too narrow |
| The audit resolves FCC Covered List or public-procurement restrictions | Not supported | Policy risk remains separate |
The Low-Risk Findings Are The Useful Part
Many headlines stop at "zero critical, high, or medium findings." Enterprise buyers should keep reading.
OnDefend reported ten low-risk findings and thirteen observations. The low-risk items included egress traffic during Local Data Mode testing on controllers, persistent access-token behavior, cryptographic key-storage weaknesses, authentication tokens exposed in URLs, persistent PSK with WPA wireless authentication, weak TLS protocols and ciphers, a denial-of-service condition on an open port, and a local file inclusion/path traversal issue in FlyShare.
Those findings did not become major findings in the report. That is good. But they are still the most actionable material for a buyer.
| Finding category | Buyer control |
|---|---|
| Local Data Mode egress behavior | Require LDM plus controller network-off procedure for sensitive missions |
| Token and session handling | Require app version, firmware version, and patch status in the fleet file |
| Weak TLS or cryptographic configuration | Ask vendor/reseller for remediation status and release notes |
| Wireless hardening issues | Disable unnecessary quick-transfer features on sensitive missions |
| Open-port or file-sharing issues | Restrict controller use, lock down non-mission features, and document approved workflows |
Local Data Mode Is Not A Full Air Gap
The most important caveat is Local Data Mode.
The report says Local Data Mode prevented user data from being sent from the DJI flight-control application to internet-based locations. Even after returning to normal mode, past flight data was not sent via the internet during the test.
But the report also says Local Data Mode did not fully isolate the controller itself because the controller operating system and other applications could still connect. The next-step recommendation is plain: for complete isolation, operators should disable the controller's network connection in addition to Local Data Mode.
That is the sentence buyers should bring into operating procedure.
For sensitive missions, "turn on Local Data Mode" is incomplete. A stronger control is:
- Enable Local Data Mode.
- Disable Wi-Fi and cellular connectivity on the controller where operationally feasible.
- Store imagery and telemetry in an approved internal workflow.
- Log firmware, app, and controller versions before deployment.
- Prohibit quick-transfer or cloud-sync workflows unless approved.
This is not anti-DJI language. It is simply the operational meaning of the audit.
The Matrice 4E Is The Most Important Scope Point
The Matrice 4E matters because it is the enterprise model in the test. It is relevant to surveying, mapping, construction, mining, and other geospatial workflows. It is not the same procurement question as every Matrice, Mavic, Agras, or public-safety drone package.
A buyer considering Matrice 4E can cite the audit more directly than a buyer using a different DJI platform. But even for Matrice 4E, the evidence should be model-locked:
- Matrice 4E, not all DJI enterprise drones
- RC Plus 2 Enterprise, not any controller
- DJI Pilot 2, not every app or third-party integration
- tested firmware/software window, not all future updates
- the buyer's mission type, not every enterprise mission
This scope discipline also protects buyers from the opposite mistake. A policy team may reject all DJI aircraft by default. The audit gives technical teams a more precise argument: if we are discussing Matrice 4E in a lower-sensitivity mission with documented data controls, the evidence is better than it was before 2026-05-28.
FCC And CISA Risk Remain Separate
The audit lands inside a policy environment that did not disappear.
On 2025-12-22, the FCC released DA 25-1086, adding foreign-produced UAS and UAS critical components to the Covered List. That action is broader than a technical bug report. It reflects national-security and supply-chain judgments about foreign-produced drone systems.
On 2026-05-08, the FCC released DA 26-454, extending the waiver that allows software and firmware updates for certain already-authorized covered UAS through at least 2029-01-01. That helps existing fleets. It does not reopen ordinary new procurement.
CISA and the FBI have also published guidance for critical infrastructure owners and operators about Chinese-manufactured UAS risk. Their recommended controls include network segmentation, patch management, logging, supply-chain diligence, and secure-by-design procurement.
That is the contradiction buyers must live with:
| Evidence stream | What it says |
|---|---|
| OnDefend technical audit | The tested systems did not show major technical findings in the test window |
| FCC Covered List action | Foreign-produced UAS remains a national-security and supply-chain category risk |
| FCC 2029 waiver | Existing fleets need security and functionality updates, but new procurement remains separate |
| CISA/FBI guidance | Critical-infrastructure operators should still treat Chinese-manufactured UAS as a serious risk category |
When Not To Use The Audit For Approval
The audit should not be used as the main approval argument when the mission has a stronger controlling rule.
Do not rely on the audit alone if:
- the program is federally funded or tied to a grant condition that excludes DJI
- the customer, state, local, or agency policy already bans DJI equipment
- the mission involves restricted infrastructure, law-enforcement evidence, or sensitive public-safety data
- the buyer is using a DJI model, controller, app, or firmware outside the Air 3S / RC 2 or Matrice 4E / RC Plus 2 Enterprise scope
- the workflow requires cloud sync, uncontrolled controller networking, or third-party integrations not covered by the assessment
In those cases, the audit can still be attached as context. It should not be treated as the approval basis.
How To Write A Model-Specific Exception
If the organization keeps using DJI, the approval should not say "DJI is approved." That is too broad.
A stronger exception reads like this:
The organization permits continued use of DJI Matrice 4E aircraft with RC Plus 2 Enterprise controllers for non-sensitive inspection and mapping missions where Local Data Mode is enabled, controller network connectivity is disabled where feasible, firmware and app versions are logged, and imagery is stored in approved internal systems. This exception relies in part on the May 2026 OnDefend assessment of the Matrice 4E and does not authorize use for restricted infrastructure, law-enforcement evidence workflows, federally funded missions, or customer programs that prohibit DJI equipment.
That paragraph does four things. It names the model. It names the mission. It names the controls. It names the exclusions.
That is the difference between risk governance and wishful thinking.
Decision Matrix By Mission
Buyers should not make one DJI decision for the entire organization.
| Mission type | Audit value | Suggested stance |
|---|---|---|
| Construction progress, roof inspection, agriculture scouting | High enough for controlled continuity | Keep DJI where customer rules allow |
| Surveying and mapping with Matrice 4E | Stronger because Matrice 4E was tested | Consider model-specific exception |
| Utility inspection or critical facility mapping | Useful but incomplete | Pilot alternatives while documenting DJI controls |
| Public safety evidence workflows | Limited | Move sensitive workflows first unless explicit exception exists |
| Federally funded or restricted programs | Low | Follow funding/procurement rules over technical audit evidence |
RFP Questions For DJI And Alternatives
The audit should change how buyers question every drone vendor.
For DJI proposals, ask:
- Which exact aircraft, controller, app, and firmware versions are being proposed?
- Do they match the OnDefend-tested scope?
- Which low-risk findings have been remediated, and in which release notes?
- Can the reseller document Local Data Mode behavior and network-off operating procedure?
- How are firmware updates approved, logged, and rolled back?
- What data is stored locally, what is synced, and what is deleted?
For non-DJI proposals, ask similar questions:
- Has the vendor undergone comparable third-party testing?
- Are network, firmware, RF, and hardware findings available to buyers?
- What is the payload, repair, training, and support delta versus DJI?
- Can the platform perform the same mission without adding aircraft, staff, or unacceptable downtime?
This matters because a weak alternative is not automatically a lower-risk decision. A strong alternative should beat DJI on policy risk without collapsing mission economics.
What Should Be Attached To The Buyer File
If an organization cites the audit, the memo should have attachments. A paragraph alone is not enough.
Attach:
- the DJI announcement or OnDefend executive report link
- the exact fleet inventory by aircraft, controller, app, and firmware
- a Local Data Mode and controller-network procedure
- the allowed and prohibited mission list
- a firmware update approval log
- an alternative-platform comparison for the same mission profile
- the relevant customer, state, federal, or grant procurement rule
This is not bureaucracy for its own sake. It is how a technical audit becomes procurement evidence. Without those attachments, the audit can be misused as a slogan. With them, it becomes one part of a controlled decision.
What Buyers Should Do Now
Use the audit as an evidence update, not a conclusion.
- Inventory DJI aircraft, controllers, apps, firmware, batteries, payloads, and integrations.
- Separate existing fleet support from new procurement.
- Map each DJI mission into keep, transition next, or transition first.
- Require Local Data Mode plus controller network-off procedure for sensitive work.
- Ask resellers for remediation status on low-risk findings.
- Compare alternatives by mission cost, not just aircraft price.
- State clearly that the audit reduces technical uncertainty but does not remove policy uncertainty.
The final line belongs in the memo. It is the sentence that keeps the organization honest.
Methodology
This article is based on DJI's 2026-05-28 announcement, the OnDefend DJI Security Assessment Executive Report, FCC DA 25-1086, FCC DA 26-454, and CISA/FBI Cybersecurity Guidance: Chinese-Manufactured UAS. Because the OnDefend assessment was DJI-authorized, this article treats it as strong technical evidence within scope, not as a neutral policy ruling.
FAQ
Does the DJI OnDefend audit prove DJI drones are safe?
It proves something narrower: OnDefend found no critical, high, or medium-risk findings in the tested Air 3S and Matrice 4E systems during the test window. It does not prove every DJI product, firmware version, workflow, or mission is safe.
Does the audit change DJI's FCC Covered List status?
No. The audit may be useful evidence in policy arguments, but FCC Covered List and procurement restrictions remain separate risk categories.
Is Local Data Mode enough for sensitive missions?
Not by itself. The OnDefend report says Local Data Mode prevented user data egress from the flight-control application, but complete isolation requires disabling controller network connectivity in addition to Local Data Mode.
Should enterprise buyers stop evaluating DJI alternatives?
No. The audit can support controlled existing-fleet decisions, especially for tested models, but buyers still need alternatives for missions where policy, customer, funding, or critical-infrastructure rules make DJI difficult to defend.
Related Entries
By China Made & Tech Team. Independent publication covering Chinese manufacturing and technology innovation for global audiences