Trust in Uncrewed Systems Part 2
Part 2: Who Gets to Do What? Command Authority in Uncrewed Systems
As countries build out their drone initiatives, much attention will go toward keeping unauthorized people out of these systems. But getting through the front door is only part of the problem. Once someone is authenticated, we still need to decide what they are actually allowed to do and for what time period.
Authentication confirms who someone is. Authorization determines what they can do. In an uncrewed system, that distinction matters: being able to sign in should not, by itself, give someone permission to issue commands or change a mission.
An operator may be qualified to fly an aircraft without being authorized to control it on a particular mission. A maintainer may need to diagnose problems and make approved configuration changes without having permission to change mission tasking. A vendor may need to troubleshoot one component without gaining access to the wider system.
Broad standing access is the wrong default. Access should match the work being done, the system involved and, where it makes sense, the mission itself. The controls built into the system should enforce those limits.
Time matters, too. Someone who receives additional access for maintenance, a deployment or a specific task should lose that access when the work is done. Otherwise, permissions have a habit of sticking around long after the original reason for granting them has disappeared.
None of this is particularly new. We have been dealing with authentication, least privilege, temporary access and revocation in traditional IT systems for a long time. We know what good access control is supposed to look like. The problem is that knowing how to do it and actually doing it well are two different things.
Stolen credentials, excessive privileges and access that should have been removed can turn a small foothold into a much larger incident.
The underlying ideas are well understood. The implementation is often where things fall apart.
Operational technology (OT) gives us another useful comparison. Much of OT was designed for environments where the network itself was trusted, connectivity was limited, and keeping the process running mattered more than defending every interaction from a hostile actor. Authentication and authorization were sometimes basic, shared, or simply not designed for the kind of contested environment we think about today.
That does not make those systems poorly designed for their original purpose. It means the assumptions around them changed.
This lesson matters for uncrewed systems. If we expect uncrewed systems to operate in hostile or contested environments, then we should assume that networks can be monitored, devices can be compromised, credentials can be stolen and legitimate access can be abused. Authentication and authorization need to be part of the architecture, not assumptions we make about everything around it.
We also already know how access tends to grow over time. People change jobs, projects end, temporary access becomes permanent, and nobody notices until much later. I do not think we should assume an operational environment will somehow be immune to the same problem.
The difference is that the impact can be much more significant. Stale access in an office environment might mean somebody can still get into an old application. In an uncrewed system, it could mean access to mission data, configuration, payload controls or the aircraft itself.
Revocation matters for exactly that reason. Yesterday’s legitimate access should not automatically become today’s legitimate access. If a role changes, a mission ends, or a credential is suspected of being compromised, the security model has to be able to reflect that quickly.
That becomes harder when an aircraft, ground station or deployed drone cannot receive an updated policy. How do you limit authority when the system cannot learn that someone’s access has changed? That is the challenge I’ll explore next.
For now, the point is that authentication is only the start. Knowing who someone is matters, but so does knowing what authority they have, where that authority applies and when it should end.
Canada has an opportunity to think about those limits early, while these capabilities are still being built out. We already know a lot about what good access control looks like, and we have decades of examples of what happens when we get it wrong.
I would rather bring those lessons into the architecture now than rediscover them later in a much less forgiving environment.