Security for connected robots

A connected robot is a computer on wheels or arms, with cameras and microphones, network links and the ability to move in the physical world. That makes it an attractive target: an attacker who takes control can steal data, spy on a building, disrupt operations or, in the worst case, cause physical harm. Researchers have repeatedly found serious weaknesses in commercial robots, from default passwords and unauthenticated ROS interfaces to unsigned firmware updates. Security therefore belongs in robot software engineering from the start, not as an afterthought. This lesson covers threat modeling, securing ROS 2 communication with SROS2 and DDS Security, secure boot and update chains, software supply chain security, network and remote access, industrial security standards, and the regulatory context in Canada and the United States.

Why robots are different

Robots combine the risks of three kinds of system. Like IT systems, they hold credentials, maps of buildings and personal data such as camera images. Like industrial control systems, they have real-time controllers and field buses (CAN, EtherCAT) that were designed for reliability, not security, and that trust every message. Like consumer IoT devices, they are deployed in large numbers, often on networks the manufacturer does not control, and updated over the air. Most importantly, they act physically, so a security failure can become a safety failure. This is why safety and security analyses must be linked: the hazard analysis asks what could hurt someone, and the threat analysis asks whether an attacker could make it happen.

Threat modeling with STRIDE

Threat modeling is the structured search for ways a system could be attacked, done early and revisited as the design changes. The process starts with a data-flow diagram of the system: components, data stores, external entities, the flows between them and the trust boundaries that flows cross, such as the line between the robot and the building network, or between the main computer and the motor controller bus. Each element is then examined against a checklist of threat types. Microsoft's STRIDE mnemonic is the most widely used: Spoofing (pretending to be someone or something else), Tampering (modifying data or code), Repudiation (denying an action because there is no proof), Information disclosure, Denial of service and Elevation of privilege.

Threats are then prioritized. A simple approach scores each threat's likelihood and impact on small scales and multiplies them, or uses the Common Vulnerability Scoring System (CVSS) for known vulnerabilities. High-scoring threats get mitigations, which become security requirements traced to tests just like functional requirements (lesson 2).

# Prioritize threats by likelihood x impact (1-5 scales), before and after mitigation
threats = [
    ("Spoofed velocity commands on Wi-Fi", 4, 5, 1, 5),
    ("Unsigned update image installed",     3, 5, 1, 5),
    ("Camera stream intercepted",           3, 4, 2, 4),
    ("Network flood stops missions",         3, 3, 3, 2),
    ("Malicious CAN frames from main PC",    2, 5, 2, 3),
]
print(f"{'threat':38} before after")
for name, l0, i0, l1, i1 in sorted(threats, key=lambda t: -t[1] * t[2]):
    print(f"{name:38} {l0 * i0:6d} {l1 * i1:5d}")
total0 = sum(t[1] * t[2] for t in threats); total1 = sum(t[3] * t[4] for t in threats)
print(f"total risk score {total0} -> {total1} ({1 - total1 / total0:.0%} reduction)")

threat                                 before after
Spoofed velocity commands on Wi-Fi         20     5
Unsigned update image installed            15     5
Camera stream intercepted                  12     8
Malicious CAN frames from main PC          10     6
Network flood stops missions                9     6
total risk score 66 -> 30 (55% reduction)

Securing ROS 2 communication

By default, ROS 2 traffic is not authenticated or encrypted: any device on the same network and ROS domain can discover the robot's nodes, read its topics and publish commands. ROS 1 had no security model at all, and many early robots were exposed this way. ROS 2 builds on the DDS Security specification, which adds authentication of participants with certificates, access control that defines which participants may publish or subscribe to which topics, and encryption of messages. SROS2 is the ROS 2 tooling that generates the keys, certificates and access-control policies and enables them for a set of nodes, using environment variables such as ROS_SECURITY_ENABLE and ROS_SECURITY_STRATEGY.

# SROS2 workflow (listing)
ros2 security create_keystore ~/robot_keys
ros2 security create_enclave ~/robot_keys /delivery/nav
ros2 security create_enclave ~/robot_keys /delivery/base_controller
# policy.xml grants /delivery/nav permission to publish cmd_vel and
# /delivery/base_controller permission to subscribe to it; nothing else may publish it
ros2 security create_permission ~/robot_keys /delivery/nav policy.xml
export ROS_SECURITY_KEYSTORE=~/robot_keys
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce       # refuse to start nodes without valid credentials
ros2 run nav_pkg navigator --ros-args --enclave /delivery/nav

Security has costs: encryption adds CPU load and latency, certificates must be provisioned to each robot and rotated before they expire, and policies must be maintained as the node graph changes. Teams therefore apply it deliberately: authenticate and restrict everything that crosses a trust boundary, and measure the latency impact on time-critical topics. Keeping ROS 2 traffic on an isolated internal network, with only a hardened gateway talking to the outside, reduces exposure further.

Secure boot, signed updates and the supply chain

Secure boot ensures that a robot runs only software its manufacturer approved. Each stage of start-up, from the boot ROM to the bootloader, the operating-system kernel and the root filesystem, verifies the cryptographic signature of the next before running it, anchored in keys stored in hardware such as a trusted platform module (TPM) or a secure element. Combined with signed OTA updates (lessons 7 and 9), this prevents an attacker from installing modified software even with physical access to the storage. Disk encryption protects data such as maps and logs if a robot is stolen.

Modern robot software contains hundreds of open-source dependencies, from the Linux kernel to ROS packages, Python libraries and container base images. A vulnerability in any of them can expose the robot. Software supply chain security starts with knowing what is inside: a software bill of materials (SBOM), in a standard format such as SPDX or CycloneDX, lists every component and version in each release. Scanners compare the SBOM against vulnerability databases such as the CVE list and the National Vulnerability Database, so that when a new vulnerability is announced the team can answer within hours which releases and robots are affected. Frameworks such as SLSA describe levels of build integrity, from scripted builds up to hardened, signed build pipelines with provenance records.

# Match an SBOM against an advisory list (versions as tuples for correct comparison)
sbom = {"openssl": "3.0.13", "libyaml": "0.2.5", "rclcpp": "28.1.4", "zlib": "1.2.13"}
advisories = [   # (package, first affected, first fixed, id) -- illustrative entries
    ("openssl", "3.0.0", "3.0.14", "ADV-1"),
    ("zlib", "1.2.0", "1.3.1", "ADV-2"),
    ("libyaml", "0.1.0", "0.2.2", "ADV-3"),
]
ver = lambda s: tuple(int(x) for x in s.split("."))
for pkg, lo, fixed, adv in advisories:
    v = sbom.get(pkg)
    if v and ver(lo) <= ver(v) < ver(fixed):
        print(f"{adv}: {pkg} {v} is affected; upgrade to {fixed} or later")
    elif v:
        print(f"{adv}: {pkg} {v} not affected")

ADV-1: openssl 3.0.13 is affected; upgrade to 3.0.14 or later
ADV-2: zlib 1.2.13 is affected; upgrade to 1.3.1 or later
ADV-3: libyaml 0.2.5 not affected

The comparison uses version tuples rather than strings, because as strings '3.0.9' sorts after '3.0.13'. Such details matter: automated tooling is only trustworthy if it is tested like any other code.

Networks, remote access and least privilege

Network design is a major line of defense. Robot networks should be segmented: internal sensor and control traffic on an isolated network or VLAN, robot-to-fleet traffic through an authenticated, encrypted tunnel that the robot initiates outward (so no inbound ports need to be open on customer networks), and no services such as SSH or web dashboards exposed without strong authentication. Default passwords must never ship; each robot should have unique credentials, ideally certificates. Remote access for support should be time-limited, approved, logged and limited to the robot in question, with multi-factor authentication for engineers.

Inside the robot, the principle of least privilege applies: each service runs as its own unprivileged user with only the files, devices and capabilities it needs; containers drop privileges; the web interface cannot write to the motor controller; and the safety functions sit on separate hardware that the main computer cannot override. Field buses deserve attention too: a compromised main computer could send arbitrary CAN frames, so motor controllers should enforce their own limits and, where supported, use authenticated protocols. Regular patching, with the staged rollout of lesson 7, closes known holes.

Standards and regulation

Industrial security is governed mainly by the IEC 62443 series, which defines security levels, zones and conduits for industrial automation and control systems, requirements for component suppliers (62443-4-1 for the secure development life cycle and 62443-4-2 for component technical requirements) and for system integrators. Robots in factories are increasingly expected to meet it. The NIST Cybersecurity Framework 2.0 (2024) provides a general structure of govern, identify, protect, detect, respond and recover, and ISO/IEC 27001 covers organizational security management.

In the United States, NIST SP 800-82 Revision 3 (2023) is the main federal guide to operational technology security, and CISA publishes advisories for industrial control systems, including vulnerabilities in robots and controllers, along with secure-by-design guidance for manufacturers. The FCC's voluntary U.S. Cyber Trust Mark labeling program for consumer IoT devices, approved in 2024 and launched in 2025, signals products that meet NIST-based baseline criteria; its administration was being reorganized in 2026, so its status should be checked. Personal data captured by robots is governed by sector laws and state privacy laws, such as California's CCPA and CPRA, and biometric laws such as Illinois's BIPA.

Security also continues after release. Manufacturers should publish a way to report vulnerabilities (a coordinated vulnerability disclosure policy, often with a security.txt file on their website), respond to reports promptly, ship fixes through the update pipeline and notify customers. The CISSP courses in this catalog cover the governance side of these practices in depth.