Trust in Uncrewed Systems, Part 3: When the Drone Can’t Phone Home

Modern identity has moved heavily toward centralized and cloud-based services. In most environments, that makes sense. It gives organizations a single place to manage users, access, policy and revocation.

The problem is that an uncrewed system cannot always assume that connection will be available. A drone may be operating from a remote location, across a degraded link or in a contested environment where the path back to a central identity service is unreliable or gone completely.

That does not have to mean falling back to a weaker identity model. A local identity service at the ground station, edge node or deployed environment can operate from the latest known good state it received while connected. The users, credentials, policies and authorization rules are already there, so when connectivity drops the local instance keeps making those decisions on its own.

That is the part I think is important. Losing connectivity should not mean losing identity. It should mean that the decision point moves closer to the mission.

For a drone operation, that means the local environment can still authenticate the operator, enforce what they are allowed to do and record what happened, even if the cloud is unreachable. The system can keep operating because it already has the identity and policy state it needs.

The harder problem starts when the two sides stop matching.

An operator could be revoked centrally while the deployed system is disconnected. The central environment knows that access is gone, but the local instance is still working from the last state it received. At the same time, the mission may require a local change. An operator might need additional authority, a maintainer might need access that was not planned before deployment, or the local team may need to adjust roles because of what is happening on the ground.

When connectivity returns, both sides may contain legitimate changes.

That is where the source of truth stops being a simple technical question. The central environment may have the newest policy, while the deployed system may have the most accurate record of what actually happened during the mission.

The uncomfortable part is that there may not always be a clean technical answer. If both sides changed while disconnected, and one of them may also have been compromised, "take the newest version" is not much of a security policy.

Some changes will be easy to reconcile. Others will not. A normal profile update is very different from a revoked operator account, a change in command authority or a deployed environment that may have been compromised while it was offline.

In those cases, automatically choosing one side over the other may be the wrong answer. The right response depends on the threat model, the operating environment and the impact of getting the decision wrong. Sometimes the system can resolve that on its own. Sometimes a human needs to make the call.

None of this is unique to drones. The same problem exists anywhere identity has to keep working at the edge or in a disconnected environment. But uncrewed systems make the problem easy to see because the mission may need to continue even when the network does not.

If disconnected operations are part of the mission, then local identity should be part of the architecture too. And the rules for bringing the local and central worlds back together should be decided before the link goes down.

‍