Trust in Uncrewed Systems 

Who Is Authorized to Command the Drone?

The obvious identity in an uncrewed system is the operator. But they are far from the only ones. Maintainers, mission planners, ground stations, payloads, software services and the aircraft itself all need some way to establish trust. Before one part of the system accepts a command, an update or even a connection from another, it needs to know who or what it is dealing with.

Any security model has to consider how unauthorized access can happen. That could be a vulnerability, a compromised device, a supply-chain issue or a stolen credential. Identity is only one part of that picture. But it is a big one, and it is one we already know how to think about reasonably well.

It also does not stop at login. 

• A drone maintainer may be allowed to service an aircraft or load approved software. That does not mean they should be able to change a mission plan. 
• A vendor may need access to one component, but probably not the rest of the system. 
• An operator may be fully authenticated and still not be authorized to command a particular aircraft, with a particular payload, for a particular mission.

This is where the problem gets interesting. Knowing someone’s identity is not the same as deciding what they are allowed to do. And with uncrewed systems, that question is not limited to people.

• A ground station needs to know it is communicating with the right aircraft. 
• The aircraft needs to know where a command came from. 
• A payload may need to know whether the system asking it to act is actually allowed to do so. 

Once you start looking at the system that way, there are identities everywhere. The same applies to software. 

• A firmware update is not just a file being copied somewhere. It changes the behaviour of the system. 
• A mission plan is not just data either. It can determine where the aircraft goes and what it does. 

Identity and authorization are not just controls around the edge of the system. They are part of the trust model of the system itself.

This gets harder when connectivity is degraded or unavailable. In a normal enterprise environment, identity and authorization decisions often depend on central services being reachable. That is not something an operational uncrewed system can always assume. If part of a fleet is offline, how long should an identity remain trusted? How do you revoke access? What happens when a system reconnects after operating for hours or days without receiving updated policy?

These challenges deserve more discussion which I will get to in Part 2 (stay tuned) where I will address this in more detail, especially command authority and disconnected operations.

Canada’s Defence Drone Initiative gives us a good reason to start thinking about these questions now. As new capabilities are developed, identity, authorization, software integrity, communications security and supply-chain controls should all be considered together instead of one at a time.

This is really what defence in depth is about. Identity is not the whole answer, and we should be suspicious of anyone claiming that it is. But it connects a lot of the other pieces.

Knowing who someone is is not the same as deciding what they are allowed to do.

And yes, you may have noticed I have managed to get almost to the end without using the term “zero trust.” That was deliberate. Zero Trust has become a bit of a buzzword. But most of what I have described here is basically what a zero trust architecture is trying to do: know who or what you are dealing with, verify it, limit what it can do, and do not trust something simply because it is already inside the environment.

For uncrewed systems, secure communications, encryption and resilience in contested environments all matter. None of those replace the need to understand identity and authority.

If we do not know who or what we are trusting, and what that identity is allowed to do, the rest of the security model is standing on shaky ground.

Read Part 2 here (coming soon).