The Defense Innovation Unit (DIU) is the point office for the Defense Department’s efforts to bring in commercial technology — including the kind of small unmanned aerial systems (UAS) that have proven so effective in Ukraine. DIU also screens and validates what they call “secure, trusted” UAS through a program called Blue UAS. It focuses on Group 1 and 2 small UAS, particularly commercially built quadcopters for short-range reconnaissance for Army, Marine Corps and special operations units.
DIU produces what’s called the Blue UAS Cleared List of platforms and components, including ground-control systems, from which military units can find verified systems and vendors for their specific missions. We discussed how it works with Blue UAS Project Lead Trent Emeneker.
BREAKING DEFENSE: When you review unmanned systems for the Blue List, how do you determine whether they’re secure and trusted?
TRENT EMENEKER: There’s three pieces of legislation that apply. The 2020 NDAA, the 2023 NDAA, and the 2024 American Security Drone Act all have pieces that apply specifically to hardware and components for use in UAS platforms. Those restrictions can be summarized as if a component can think, talk or communicate in some way, it can’t come from a prohibited country. For all intents and purposes, that means China, Russia, North Korea, Iran, and Venezuela.
The first thing we do is ensure that platforms we are looking to add are in compliance with that part of the law. We do a physical tear down [and] look to see where the components we need to check come from and trace the supply chain back to understand if this is illegal for the law.
Then we look at cybersecurity. What we do is apply a set of commercial best practices [and] our underlying guidance using a NIST set of standards to ensure that the platforms and components we list have the required level of cybersecurity.
That doesn’t mean they’re perfect because frankly there’s no unhackable system that’s ever been invented, at least that we know of. [The use of] commercial best practices makes it harder for an adversary to crack, penetrate, or infiltrate, whether that’s through the platform manufacturer [or] the component manufacturer’s corporate infrastructure where they could insert code maliciously at their site or [conduct] additional hacking while the platforms are in use.
What is it that companies send you for the vetting process — boards, radar panels, entire platforms?
We have the Blue UAS List, which are flying platforms, and Blue UAS Framework, which are components and capabilities. That could be a camera, radio or just a piece of software.
In the case of the full-component flying platform, people normally have shipped them to us intact. Today, for ease of disassembly and to avoid damage, what we ask for now is if it’s possible [to] send us the full BOM, the bill of materials, with all the components. We don’t have to disassemble it, as long as it’s everything that’s used to make the platform.
Same thing for components. We tear the hardware apart, looking at manufacturer markings on it, any serial numbers, shipping labels. We’re tracing that back through a known network as best we can.
That’s not to say that we’re perfect. We catch errors that companies make in good faith all the time. The supply chain in this space is complicated. We’ve never had anyone intentionally mislead us, but we have had companies think they were using something that was okay that turned out it wasn’t. We do a thorough investigation to get to the best possible outcome while still remaining reasonable in our approach.
How many companies are on the Blue List?
We have 16 platforms on the list today, comprising Group 1 and Group 2 UAS platforms. We have two fixed-wing platforms; the remainder are all quadcopters.
On our framework, we have an additional 12 to 15 companies listed. That’s the scale, roughly 30-ish companies that are on the list in one form or another today.
One of the things that the Blue List has done and is doing is listening to our end-user feedback, letting people tell us what their problem sets are. Traditionally and as you see today on our flying platforms, we have Group 1 and Group 2. But we know that there is a clear user-identified need for FPV platforms — the first person view [UAS] that you see in Ukraine that are primarily used for one-way attack missions.
We know that there is a demand for longer-range ISR platforms and what we would call Group 3 or longer-endurance Group 2. Those are going to be fixed-wing platforms, and we’re moving to incorporate those.
In November, we’re going to have the first of what will become an annual competitive refresh event where everyone who’s on the Blue List will compete to stay on. We’ll also open up a competition to new entrants, knowing that the marketplace derives the best outcome.
Blue UAS is almost five years old now [and] historically, when a platform was added, it stayed on. I’ve been in the role about 14 months and one of the things that I learned from listening to our end-users was we need to better meet their needs. The reality of it is [that] some platforms that we have today aren’t meeting end-user needs. If it’s not doing that, we will not keep it on the list. That’s a recent change and is the way that we will move forward.
A lot of the small UAS systems on the Blue List are based on mature technologies. What’s less mature and still a technical challenge for sUAS? Also, what is the ability of the manufacturers of these systems to scale production. Is that part of Blue List criteria?
I’ll start with the second half of that question first. When we add platforms to the Blue List, we do look at company viability. That’s everything from, do they have the financial runway that they’re going to need to start making the platform, [to] what is their manufacturing capacity now, [to] what is it realistically in three months, six months, a year? What does it take for them to ramp and scale? We do look at those things because a company that can make five systems a month doesn’t meet any need or demand that we could have outside of some limited use cases.
To the first part of your question, what we see — and this is a lesson learned from Ukraine but we also see it in the Middle East, Asia and other places — is there’s a need to be able to navigate in denied environments where GPS and the global navigation satellite systems don’t work or are being spoofed. There’s lots of potential solutions and people working on that today.
The other piece is, and this is largely a Ukraine observation, how do you communicate when the electromagnetic spectrum is completely contested? Again, lots of work going on in that space today.
DIU in partnership with SOCOM has recently launched a project, and we’re days away from signing contracts with a couple firms to develop solutions and capabilities in that area. There’s other work going on in DoD [where it’s] partnered with commercial firms to solve navigation in a GPS-denied environment. That’s happening worldwide. Ukraine is working on it, European firms are working on it. We know our competitors are, as well.
What advancements are you looking to see in ground control systems (GCS)?
It is part of the Framework and you will see in the very near future the addition of a GCS to our Framework. But the big conceptual problem in the UAS space today within DoD is we operate a lot of different platforms. There’s very little interoperability between one to the other, and modularity is also lacking. You can’t take a camera from one today and plug it into another. In some cases you can but that’s hard, same thing for our GCS.
One of the things that we are making a requirement going forward is if we’re going to list you on the Blue List your platform has to be modular and interoperable. That doesn’t mean completely plug and play. That is our goal, but we understand there may be a modicum of integration requirements to actually make that happen.
For the GCS, same thing. From a logistics standpoint, we want one GCS to be able to control any platform that’s out there. You could very easily have six to eight different type model series of UAS platforms. We want the operator to be able to control all of them with the same thing.
Does that mean that there’s only one GCS? No. There could be three or four different GCSs but they’re all interoperable — any one of those can control any one of the flying platforms. That’s where we’re going. We’ve made some progress, but this is going to be a requirement going forward for Blue because we know that our end users want and need that.
How that problem gets solved, I don’t know today, but the requirement will be interoperability.
What are possibilities of what a next-generation sUAS looks like, to perform what roles?
If we look at the tactical level of warfare, and I define that as from the brigade or regiment down, small UAS platforms are going to continue to disrupt every single thing that they do today. Everything from ISR to correcting fire, to delivering kinetics to carrying cargo from one place to another. Ukraine has shown us part of the way but I think even there it’s clear that everyone is still grappling with how you adjust.
The only thing that I feel comfortable saying for sure is that if we are properly preparing our warfighters to go to combat, which I hope they never have to do, but if we are, then we’re going to be equipping them with a variety of new tools and capabilities to go do that.
What does that look like? We want things to be modular, interoperable, and from my perspective, what we want to deliver is the minimally viable capability at the right cost. We don’t want to deliver the perfect solution that’s too expensive in 10 years, which is the traditional DoD way. We want to deliver something that mostly gets the job done today at a cost that allows it to be attributable.
And then we see our strategic advantage in the US and the West is software. In this field, software is going to make the difference. [For] the hardware we have to have baseline capabilities, absolutely. But the ability to iterate, to write software that’s going to react and update fast enough on the battlefield and then to provide a tactical edge, that’s where we have and retain an advantage if we choose to use it.
Today within DoD, an average software update approval timeline is between 12 and 18 months. At DIU, it takes us about 90 days. We’re in the process of piloting a continuously monitored software project that’s going to take that down to less than 96 hours.
Direct feedback from Ukraine, if you talk to folks there, they’ll tell you this is the speed you need to move at. The apps on my phone, even Google Maps, update every week. I don’t know what [it’s] doing, but I trust that it’s getting better somehow. That’s the speed that we have to be able to operate and iterate at.