A threat model checklist for a connected robot or vehicle

To threat model a connected robot, drone or vehicle, list every way data or commands reach it, mark where trust changes, and decide what each untrusted input is allowed to cause. Then check updates, the cloud backend and safe failure behavior. This checklist is built from public cases such as the Jeep Cherokee hack and the Kia dealer portal flaw.

Step 1: list the entry points

Write down every path in, with no judgment yet.

• Radio links: cellular, Wi-Fi, Bluetooth, remote control and telemetry radios.
• Wired ports: diagnostic ports, USB, service connectors.
• Sensors that read the physical world, such as cameras and satellite navigation receivers.
• The companion app and the cloud API behind it.
• Dealer, installer and support tools.
• The update channel.

The Jeep case began with an infotainment system. The Kia case began with a dealer portal. Neither was the first thing most teams would draw on a diagram.

Step 2: draw the trust boundaries

Mark each place where a message crosses from a less trusted zone to a more trusted one. On a vehicle, that includes the gateway between infotainment and driving networks. On a robot, it can be the boundary between a camera driver and the motion controller.

For each boundary ask what is checked. A shared bus like CAN has no sender authentication in its standard form, so any unit on it can be believed unless you add checks.

Step 3: ask what each input can cause

For each entry point, write the worst thing a hostile input could do, and the controls in the way.

1. Can a message from this link move an actuator?
2. Can a bad sensor reading cause an unsafe action, such as a spoofed satellite position?
3. Can a misread of the world, such as a modified road sign, produce a wrong decision with no second check?

Step 4: check identity and ownership

Many real incidents are about who is allowed to command the machine.

• Can anyone create a privileged account?
• Can ownership change without notifying the owner?
• Is one key shared across a fleet?
• Are credentials per device, per node and per person?

Step 5: check updates

• Is every update verified before install, and replay rejected?
• Is there a safe state if an update fails midway?
• Can you update in the field, quickly?
• Do you know which version each unit runs?

Step 6: check the software supply chain

List the open source components and models in each release. Know who maintains them. A current SBOM per release is the starting point, and Safeguard can generate one and scan dependencies for software you build.

Step 7: define safe failure

Write down what the machine does when it loses links, when sensors disagree, and when an input looks wrong. Safe failure is part of the security design, not a separate safety exercise.

Step 8: plan for outsiders

Publish a way to report vulnerabilities. Decide who reads reports, and how fast you answer. Contests and researchers will probe public products, so a prepared team has an easier time than a surprised one.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Chrysler recalls 1.4 million vehicles after Jeep Cherokee hack (Security Affairs)
• Hacking Kia (Sam Curry)
• CAN bus (Wikipedia)

Last reviewed: 19 October 2026.