“NDAA compliant” has become one of the most overused and least verified phrases in the domestic UAS market. Every vendor claims it. Procurement teams often accept the claim at face value because verifying it feels complicated and the alternatives — a failed audit, a GAO protest, or a platform that turns out to be running firmware from a prohibited vendor — seem unlikely until they happen.
They happen more than people admit.
This post is a practical breakdown of what NDAA compliance actually requires for UAS procurement, where vendor claims commonly fall short, and what due diligence looks like when you are making a procurement decision that needs to survive scrutiny.
The Legislative Background
The National Defense Authorization Act provisions relevant to UAS procurement have evolved significantly since 2018. The core restrictions stem from Section 848 of the FY2020 NDAA, which prohibited the Department of Defense from procuring or operating UAS manufactured or assembled by specific Chinese entities — DJI, Dajiang, and their affiliates being the most prominent.
Subsequent NDAAs have expanded and tightened these restrictions. The FY2023 NDAA introduced the American Security Drone Act, which extended restrictions beyond DoD to the broader federal government, prohibiting federal agencies from procuring covered UAS using federal funds. The threshold is no longer limited to final assembly — the restrictions now encompass components, subsystems, and software from covered foreign entities.
The practical effect is that “assembled in the USA” is not sufficient for compliance. A platform assembled domestically using sensors, processors, RF modules, or flight control firmware sourced from covered entities is still a covered UAS under current law. The compliance question is not where the drone was put together — it is where every meaningful component came from.
Understanding this distinction is the starting point for any serious NDAA compliance evaluation. If a vendor cannot answer the component sourcing question in detail, the assembly location is irrelevant.
What “Covered UAS” Actually Means
The statutory definition of a covered UAS under the American Security Drone Act includes UAS manufactured or assembled by a covered foreign entity, and UAS that use critical components manufactured or supplied by covered foreign entities.
“Critical components” is the operative phrase and the one that creates the most compliance risk. The statute does not provide an exhaustive list, but DoD guidance has identified several categories that consistently apply: flight controllers, communication modules, cameras and imaging sensors, data storage systems, and the software stacks that govern flight operations and data handling.
The covered foreign entities list is maintained and updated. At time of writing it includes the five Chinese entities named in the original FY2020 NDAA — DJI, Dajiang, Hikvision, Dahua, and Hytera — as well as entities added by subsequent executive action and statute. The list is not static. Procurement teams that verified compliance against the 2022 list and have not revisited the question since may be working with outdated information.
The correct practice is to verify against the current covered entity list at the time of procurement and to require vendors to certify against the current list, not the list as it existed when their product was originally designed.
The Blue UAS Cleared List
The most practical compliance shortcut available to federal procurement teams is the Department of Defense’s Blue UAS Cleared List, maintained by the Defense Innovation Unit. The Cleared List identifies UAS platforms that DIU has evaluated and determined meet NDAA requirements for federal procurement.
We have covered the Blue UAS Cleared List in detail separately, but the core value proposition is straightforward: a platform on the Cleared List has been through a structured evaluation that includes supply chain review. Procuring from the Cleared List does not eliminate the need for vendor due diligence entirely, but it substantially reduces the compliance risk because DIU has already done significant verification work.
The Cleared List is not exhaustive. Not every compliant platform is on it, and the evaluation process has a backlog. A platform that is not on the Cleared List is not necessarily non-compliant — it may simply not have been evaluated yet. But procurement teams working under time pressure and without dedicated supply chain review resources should weight the Cleared List heavily in their evaluation process.
For teams using OTA agreements to accelerate procurement, the Cleared List is especially useful: it provides a defensible basis for compliance determinations that would otherwise require significant legal and technical review within the OTA timeline.
Where Vendor Claims Fall Short
The gap between “we are NDAA compliant” and actual verifiable compliance is wider than most procurement teams assume. Several patterns appear repeatedly in the market.
Final Assembly Claims Without Component Disclosure
The most common compliance misrepresentation is a vendor that correctly states their platform is assembled in the United States but cannot or will not disclose the origin of key components. Final assembly location is a necessary but not sufficient condition for NDAA compliance. A vendor that deflects component sourcing questions with “we assemble domestically” is not answering the compliance question — they are changing the subject.
The correct follow-up is to require a Bill of Materials (BOM) with component-level sourcing documentation. Any vendor with a genuinely compliant supply chain can produce this. It is not a proprietary trade secret to name the manufacturer of a flight controller or an imaging sensor. If a vendor treats the BOM as confidential to the point of refusing to share it under NDA with a procurement team doing due diligence, that refusal is informative.
Software and Firmware Provenance
Hardware compliance is only half the picture. A platform built from domestic hardware components can still fail a compliance evaluation if the flight control firmware, mission planning software, or sensor processing stack has dependencies on software libraries maintained by covered entities or hosted on infrastructure they control.
This is a harder problem to verify than hardware sourcing because software dependency chains are less visible. A flight controller running open-source firmware with no covered entity dependencies is straightforwardly compliant. A flight controller running a proprietary firmware stack with undisclosed dependencies is a compliance unknown.
Ask vendors specifically about their software dependency chain. Require disclosure of any third-party libraries or services integrated into the platform software. For classified or sensitive applications, require the ability to audit the firmware directly.
Our battlefield mapping software is built with this audit requirement in mind — the dependency chain is documented and available for review by customers with specific security requirements.
The “NDAA Compliant Components” Claim
Some vendors have begun marketing their platforms as using “NDAA compliant components” — a phrase that has no statutory definition and no standard verification process. It is a marketing claim, not a compliance determination. The statute does not define component-level compliance in a way that allows vendors to self-certify individual components and aggregate those certifications into a platform-level compliance claim.
The compliance question is whether the platform, as a whole system including all components and software, is procurable under current NDAA restrictions. That determination requires a holistic review, not a checklist of component-level marketing claims.
What Meaningful Due Diligence Looks Like
Procurement teams that take NDAA compliance seriously approach vendor evaluation with a defined process rather than relying on vendor assertions. The process does not have to be elaborate, but it has to be substantive.
Request a component-level BOM under NDA. The BOM should identify the manufacturer and country of origin for all critical components: flight controller, communication module, imaging sensors, data storage, and battery management system. Review it against the current covered entity list.
Require software dependency disclosure. Ask for a list of all third-party software libraries integrated into the platform software and firmware. Verify that none originate from covered entities or depend on infrastructure those entities control.
Verify against the current covered entity list. Do not rely on compliance certifications that were issued more than twelve months ago without re-verification. The covered entity list changes, and a determination that was accurate in 2024 may not be accurate in 2026.
Require a written compliance certification. Any vendor confident in their compliance posture will provide a written certification identifying the specific NDAA provisions they are certifying compliance with, the date of the certification, and the basis for the determination. Verbal assurances are not sufficient for a procurement decision that will survive audit.
Confirm Blue UAS Cleared List status or document why it is not applicable. If the platform is on the DIU Cleared List, document that. If it is not, document the alternative compliance basis. Either is defensible — absence of documentation is not.
The Supply Chain Risk Beyond Compliance
NDAA compliance is a legal minimum, not a security posture. A platform that is technically compliant under current statute can still present supply chain risks that are operationally significant.
The threat model for UAS supply chain risk in sensitive applications goes beyond the covered entity list. Components from any foreign manufacturer can introduce firmware that is difficult to audit, update dependencies that require connectivity to foreign-controlled infrastructure, or hardware vulnerabilities that are not publicly documented.
For units operating in sensitive environments — the SOF applications we have written about separately, or the C-UAS architectures described in our counter-UAS procurement guide — the relevant question is not just whether the platform meets the statutory minimum but whether the supply chain is transparent enough to trust in a high-stakes environment.
That requires a higher standard than NDAA compliance alone. It requires domestic component sourcing where technically feasible, documented firmware provenance, and the ability to audit the software stack without relying on vendor assurances. It requires a vendor relationship in which supply chain transparency is a feature, not an obstacle.
The Bottom Line
NDAA compliance for UAS procurement is not a checkbox. It is a verification process that requires actual documentation, reviewed against the current covered entity list, applied to the full platform including software — not just the airframe.
Vendors that resist this process are telling you something important. The domestic UAS industry has capable, genuinely compliant options that can produce the documentation a thorough evaluation requires. There is no legitimate reason for a compliant vendor to treat supply chain transparency as a proprietary secret.
If you are working through a UAS procurement and want to discuss VST’s compliance documentation — including our component-level BOM and software dependency disclosure — contact our team. We provide full supply chain documentation to procurement teams conducting due diligence, under NDA where required.