A cybersecurity threat model for an unmanned system explains how an adversary could cross a trust boundary and cause an unwanted result: unauthorized motion, corrupted observations, exposed mission data, or loss of control. It connects the vehicle, operator station, communications, autonomy software, maintenance tools, and supporting services to specific defenses and recovery behavior.

For unmanned systems cybersecurity, the useful output is a set of engineering decisions: who may issue a command, which information the controller may trust, what happens when that trust fails, and how those choices will be demonstrated. The model must follow the mission beyond the radio link.

On This Page

Draw the system around its trust boundaries

A trust boundary marks a change in the authority or assumptions applied to data and actions. Two processes inside one vehicle can sit on opposite sides of that boundary. Conversely, a remote operator may legitimately hold more authority than an onboard camera application.

The W3C's Threat Modeling Guide, a June 2026 Group Note Draft for specification development, offers a useful general structure: identify the system and affected people, describe threats, select responses, and record remaining assumptions and risks. Applying that structure to a robot does not make the draft a robotics standard.

Start with the actual mission configuration. Trace an operator's task through the communications endpoint, mission manager, navigation software, motion controller, and actuators. Trace observations back through sensors, processing, storage, and the operator display. Add the paths used for software updates, diagnostics, charging or docking services, and remote support where they exist.

For each interface, record its producer, consumer, message meaning, permitted actions, and owner. Identify where authentication is checked and where an authorization decision is made. Include local serial, Ethernet, USB, and inter-process interfaces when present; a physically short connection is still part of the model.

The ROS 2 robotic threat model illustrates why this scope matters. Its entry points extend from robot hardware and inter-component channels to administration tools, remote applications, and deployment infrastructure. A compromised component can affect another component through apparently legitimate data flows.

For a modular vehicle, record which supplier is responsible for enforcing each boundary. The guide to open architecture in unmanned systems explains the interface agreements needed when components come from different organizations. A documented message format still needs an explicit decision about who is allowed to use it.

Turn threat categories into mission consequences

Microsoft's STRIDE model supplies six prompts: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Use them to inspect each boundary. They identify kinds of problems; they do not establish the likelihood or severity of a particular robot incident.

The following matrix applies those prompts to illustrative unmanned-system interfaces. The controls and demonstrations are proposed engineering checks, not reported test results or a mandatory security profile.

Boundary and threatPossible mission consequenceControl to specifyDemonstration to request
Operator identity is spoofedAn unauthorized station sends a taskAuthenticate the issuer and constrain its command authorityA station without the required identity cannot start or alter the task.
Mission data is tampered withThe vehicle follows an altered routeProtect task integrity and check permitted mission limitsAn altered task is rejected before activation.
A command is later deniedInvestigators cannot establish who changed the missionRecord issuer, task identity, decision, and execution outcomeAn authorized test change can be reconstructed without exposing secrets.
Payload data is disclosedSensitive imagery or mission details leave the systemRestrict recipients and protect data in transit and storageA role without data access cannot retrieve the protected record.
A service becomes unavailableThe controller loses timely commands or observationsBound resource use and define degraded operationInterruption produces the agreed vehicle response.
A payload gains control privilegesA sensing application changes motion limitsSeparate permissions and constrain its controller interfaceThe payload role cannot invoke administrative or motion-control operations.

Prioritize the rows using the mission consequence and the access an adversary would need. A remote outsider, an operator with excessive permissions, a compromised supplier component, and someone holding a recovered vehicle have different starting positions. Record those assumptions instead of assigning an unsupported universal risk score.

For a fleet, also ask whether one compromised identity can affect one robot or every robot. The discussion of system-of-systems architecture provides the coordination context: command ownership and shared services need explicit boundaries as the team grows.

Understand what the security mechanisms actually protect

Authentication establishes an identity or possession of an accepted credential. Authorization determines the actions that identity may perform. Encryption protects confidentiality within its defined scope. A threat model should identify each separately, including the endpoints where protection begins and ends.

MAVLink 2 message signing uses a shared secret and signed packet information, including a timestamp, to support origin and integrity checks and reject stale traffic according to the protocol's rules. Its specification also permits implementation-specific exceptions for accepting unsigned traffic. Those exceptions belong in the interface review.

ArduPilot's MAVLink2 signing documentation makes the confidentiality limit explicit: signing does not encrypt the data. It also describes different treatment of USB connections and telemetry downlinks. If mission data needs confidentiality, identify the additional protection used and whether it covers every relevant hop and stored copy.

Possession of an accepted signing key is also not evidence of a fine-grained operator-role policy. Ask where the vehicle distinguishes permission to read telemetry, change parameters, or issue motion commands. Test the deployed implementation's behavior, including its maintenance interfaces and reconnect behavior.

ROS 2 security depends on the deployed configuration

The ROS 2 DDS-Security design describes authentication, access-control, and cryptographic mechanisms. Signed governance and permission documents govern participation and allowed operations, including access to topics. It also distinguishes enabling security from enforcing startup failure when the required security material is unavailable.

For a ROS 2 system using DDS, ask for the installed distribution, middleware implementation, security configuration, and permissions associated with each application role. The design document describes the architecture; the actual release and deployment must demonstrate it. Include a startup test with missing or invalid security configuration in an isolated environment and verify the intended refusal behavior.

An encrypted channel can still carry an authorized component's incorrect observation. Protecting transport therefore leaves a separate engineering question: how does downstream software decide whether the information is plausible and usable?

Work through a compromised payload

Consider an illustrative inspection robot with a third-party object tracker. The tracker supplies target positions to navigation software, which requests motion from a separate controller. The tracker has no legitimate reason to change actuator limits or install software.

The ROS threat model explicitly considers a malicious tracker influencing movement through false object estimates, leaking imagery, or exhausting computing resources. This is a model of possible behavior, not a claim that a named current product has those vulnerabilities.

Build the example into a concrete review record: the protected asset is controlled motion; the entry point is the tracker process; the crossed boundary is the observation interface into navigation. Limit the tracker's permissions, specify observation validity checks, and prevent its workload from consuming resources reserved for essential control. Treat these as separate measures: topic permissions alone cannot establish that a permitted observation is true.

Ask the integrator to demonstrate a permitted publisher sending deliberately inconsistent observations in an isolated test configuration. Record whether navigation identifies the inconsistency and which motion response follows. The sensor-fusion guide explains the timing, reference-frame, and uncertainty checks relevant to that interface. Combining sensors does not by itself prove resistance to deception.

The resulting requirement is more useful than “secure the payload”: define which data the payload may provide, which actions it cannot request, and what the controller does when that data becomes untrustworthy.

Choose recovery behavior for the operating domain

NIST's PNT profile, IR 8323 Revision 1, treats positioning, navigation, and timing services as dependencies whose signals and data may be disrupted or manipulated. It is voluntary risk-management guidance. An unmanned vehicle's security review should therefore include loss of confidence in position or time, as well as loss of a network connection.

The response depends on the mission. These are representative design scenarios, not universal operating instructions:

  • Aerial inspection: review whether a planned recovery maneuver depends on the same position source now considered unreliable. Define the permitted response with the vehicle's flight-safety constraints.
  • Ground logistics: determine where a stopped vehicle would create an obstruction and how local protective functions remain available if fleet communications fail.
  • Surface survey: specify what authority remains onboard during isolation and how renewed operator control is reconciled with the task already running.
  • Underwater inspection: for a mission designed around intermittent communications, distinguish an expected quiet interval from a condition that invalidates the current task. Document the recovery decision and its navigation dependencies.

For each scenario, state the information the response still requires. A second receiver or communication path needs a review of shared dependencies before it is credited as independent protection. Recovery should be evaluated under the suspected failure, not only under normal conditions.

Make security fit the timing and maintenance constraints

NIST SP 800-82 Revision 3 treats operational-technology security alongside performance, reliability, and safety requirements. That is an appropriate engineering lens for software that can change physical motion. A control that is effective on an office workstation may need different integration and maintenance arrangements on a moving vehicle.

Specify the conditions under which security must operate: participant startup, steady traffic, reconnects, and maintenance. Measure command age and control scheduling with protection enabled and the intended payload workload. Do not assume that a successful idle connection establishes performance during camera processing or fleet discovery.

MAVLink provides one bounded protocol example: signing adds 13 bytes to a packet. That is a framing cost, not a measured latency penalty or a whole-system bandwidth estimate. Processing time and transport behavior still require measurements on the actual configuration.

Maintenance creates a second tradeoff. Restrictive identities and permissions need a workable replacement and recovery process. Ask who can provision a replacement computer, remove a lost operator's access, and restore a vehicle after a failed update. Include offline operating periods in that review.

NIST SP 800-193 frames platform-firmware resilience around protection against unauthorized changes, detection of changes, and secure recovery. Apply those questions separately: what prevents an unauthorized image from loading, what reveals a changed platform, and what restores a trustworthy state? A successful boot alone does not answer all three.

Request recovery demonstrations under controlled maintenance conditions, including a failed update and restoration of an approved configuration. Record who owns the recovery material and how it is protected. These are proposed procurement and integration checks, not evidence that any particular vehicle already provides the functions.

Turn the model into an acceptance demonstration

Choose a consequential threat path and follow it end to end. Record the configuration, adversary access assumption, affected interface, prevented action, remaining permitted behavior, and vehicle response. Agree how the test will be contained and what constitutes success before introducing the condition.

For the tracker example, success needs more than an access-denied event. The tracker must be unable to request forbidden operations, navigation must handle invalid observations as specified, and the vehicle must produce the agreed response. Preserve the event sequence needed to distinguish those outcomes.

Give every unresolved assumption an owner and a review trigger, such as a new payload, middleware update, remote-support feature, or change in command authority. Retain explicit residual risks when a control cannot address the threat. A useful threat model stays attached to the actual system configuration and the demonstrations supporting its use.

Sources

Last checked: September 9, 2026.