Robot Cybersecurity: The Ultimate Guide

A compromised web server leaks data. A compromised robot moves. That single sentence is the whole reason robot security is a distinct discipline rather than a subfolder of IT security. When an attacker reaches the control loop of a 6-axis industrial arm, a warehouse AMR, or a delivery drone, the payload is torque, velocity, and a two-tonne mass swinging through a space where people stand. The confidentiality-integrity-availability triad that organizes classic infosec gets reordered on the factory floor: integrity and availability of the control path dominate, because a corrupted setpoint or a denied heartbeat becomes kinetic energy in the physical world.

This guide is for the people who build and operate these systems: the robotics engineer who wired up a ROS 2 stack with security switched off because the tutorials did, the OT security lead who now owns a fleet of autonomous machines alongside the PLCs, and the drone operator who has heard "GPS spoofing" thrown around and wants to know what is real. We go through the full attack surface (middleware, network, firmware, sensors, supply chain), how to threat-model a machine where a hack becomes motion, the tight coupling between safety and security, the concrete secure-design controls that work, the standards you will be audited against, and how to keep a fleet patched without turning the update channel into the biggest vulnerability you own.

The take: A robot is an OT asset with an IT attack surface and a physical blast radius, so you secure it with defense in depth that treats the control path as safety-critical. The highest-leverage moves are unglamorous: authenticate and encrypt the middleware (SROS 2 / DDS-Security), segment the control network away from the enterprise and the internet, sign firmware and enforce secure boot, sign and stage OTA updates with rollback, and generate an SBOM so you can answer "am I affected?" in hours instead of weeks. Sensor spoofing (GPS, lidar, camera) is a real and physics-bound threat that authentication alone does not fix; you defend it with sensor fusion, plausibility checks, and redundancy. The organizing principle is that a safety function and a security control protect the same thing from different adversaries, so they must be engineered together.

Companion reading: ROS 2, robot safety & functional safety, industrial automation: PLC, SCADA & fieldbus, drone navigation: GNSS & RTK, and counter-drone / C-UAS.

Table of contents

1. Key takeaways
2. Why robot security is different
3. The robot attack surface
4. ROS, ROS 2, and DDS exposure
5. Sensor spoofing and physical-signal attacks
6. Threat modeling a cyber-physical system
7. The safety-security interplay
8. Secure design: authentication, encryption, segmentation
9. Firmware, secure boot, and supply chain / SBOM
10. Standards: IEC 62443 and the certification map
11. Fleet and OTA update security
12. Detection, monitoring, and incident response
13. Frequently asked questions

Why robot security is different

Standard IT security optimizes for confidentiality first: keep the data secret, keep it intact, keep it available, roughly in that order. Operational technology flips the priority because the asset does work in the physical world. For a robot the ordering is starker still. A denial-of-service that drops the control heartbeat can trip an emergency stop (a safety event with physical consequences). A tampered joint setpoint can drive an arm into a person. A spoofed position can steer a mobile robot off a mapped path into a pedestrian aisle. The output of the system is kinetic, so the loss function is measured in injuries, damaged product, and stopped production lines.

Three properties make robots harder to secure than either a typical IT host or a static PLC.

Real-time constraints limit what security you can add. A control loop running at 1 kHz has a 1 ms budget. You cannot drop a heavyweight TLS handshake or a deep-packet-inspection firewall in the middle of a hard-real-time joint-control path without blowing the deadline, and a missed deadline on a balancing or high-speed system is itself a hazard. Security has to live where it does not steal the timing budget, which usually means at the network edges and the middleware layer rather than inside the innermost loop. See real-time control systems for why that budget is inviolable.

Long lifecycles meet short security half-lives. An industrial robot runs for 10 to 20 years. The Linux kernel, the ROS distribution, the TLS library, and the CVE landscape underneath it turn over every few years. A robot commissioned in 2015 is running software whose vulnerabilities are now public and unpatched, on hardware nobody wants to touch because re-validating the safety case after a software change is expensive. The result is a large installed base of machines that are simultaneously safety-certified and cryptographically stale.

The perimeter dissolved. Robots increasingly carry cellular modems, connect to cloud fleet managers, accept OTA updates, and support remote teleoperation. Each of those is a path from the internet to a machine that can move. A delivery drone, a teleoperated surgical robot, and a cloud-managed AMR fleet all have a live network path from a remote attacker to an actuator. The air gap that once protected the factory floor is mostly gone, and where it remains it is often bridged by an engineer's laptop or a USB stick.

Rule of thumb: Rank your threats by physical consequence above data value. On a robot the worst outcome is unintended motion, well above a leaked file. Design your controls so the paths that can cause motion are the most heavily defended.

The robot attack surface

Map the surface before you defend it. A modern robot exposes five layers, and an attacker only needs one.

Middleware and application. The pub/sub bus (ROS 2 topics and services over DDS, or a vendor middleware), the motion-planning and control nodes, web dashboards, REST/gRPC APIs, and any scripting or plugin interface. This is where an attacker who has reached the robot's network can publish a malicious command, subscribe to sensitive topics, or crash a node.

Network and connectivity. Wi-Fi, Ethernet, 4G/5G modems, Bluetooth, the teleoperation link, and the cloud backhaul. Weak or absent transport encryption, default credentials, open management ports (SSH, VNC, web UIs), and unauthenticated discovery protocols live here. Shodan-style internet scans routinely find exposed robot and industrial control interfaces reachable from the public internet.

Firmware and boot chain. Motor-controller firmware, the microcontrollers on the motor controllers, the main compute's bootloader and OS image, and the robot wiring and connectors that expose debug ports (JTAG, UART). An attacker with firmware write access installs a persistent implant that survives reflashing of the higher layers.

Sensors. Cameras, lidar and depth cameras, GNSS receivers, IMUs, and encoders. These accept physical signals from the environment, and an attacker who controls the environment (a spoofed radio signal, a laser, a projected image) can inject false data through a perfectly legitimate channel. Cryptography does not help when the lie enters at the transducer.

Supply chain. Third-party ROS packages, open-source libraries, container images, vendor firmware blobs, and the build and update pipeline itself. A poisoned dependency or a compromised update server delivers malware to every robot that trusts it, which is the highest-leverage attack of all.

Layer	Example asset	Primary threat	Primary control
Middleware / app	ROS 2 topics, services, dashboards	Unauthorized command injection, node crash	SROS 2 auth + encryption, access-control policy
Network	Wi-Fi, cellular, teleop link, cloud API	Sniffing, MITM, exposed ports, default creds	Segmentation, mutual TLS, VPN, no default creds
Firmware / boot	Bootloader, MCU firmware, debug ports	Persistent implant, downgrade, physical access	Secure boot, signed firmware, disabled debug ports
Sensors	GNSS, lidar, camera, IMU	Spoofing / injection of false but valid data	Sensor fusion, plausibility checks, redundancy
Supply chain	Third-party packages, update server	Poisoned dependency, malicious OTA push	SBOM, signed artifacts, provenance, staged rollout

Rule of thumb: An attacker chooses the cheapest path to the goal. If your middleware is hardened but a teleop web UI on the same box still has a default password, you spent your effort on the wrong layer. Defense in depth means the weakest layer sets your security, so raise the floor; a higher ceiling buys nothing.

ROS, ROS 2, and DDS exposure

The Robot Operating System is the connective tissue of most research and a growing share of commercial robots, so its security posture is the single most important software fact about a large fraction of the fleet. See the ROS 2 guide for the architecture.

ROS 1 had no security model. The original ROS relied on a central roscore master and unauthenticated, unencrypted TCP/UDP (TCPROS/UDPROS). Anyone with network reach to the master could enumerate topics, subscribe to camera feeds, publish command-velocity messages, and kill nodes. There was no authentication, no encryption, no access control. On any network an attacker can reach, a ROS 1 robot is fully controllable. Researchers demonstrated exactly this repeatedly, and internet scans found thousands of ROS masters exposed to the public internet. The practical rule is blunt: never expose a ROS 1 system to an untrusted network, and treat "on the robot's Wi-Fi" as untrusted.

ROS 2 replaced the master with DDS and added a security model, but it is off by default. ROS 2 is built on the Data Distribution Service (DDS), an OMG standard with a decentralized discovery mechanism and a formal security specification, DDS-Security. The relevant plugins give you five capabilities:

• Authentication (mutual, via X.509 certificates and a per-domain certificate authority): each participant proves its identity before joining.
• Access control (permissions files signed by a permissions CA): a policy that says which participant may publish or subscribe to which topics.
• Cryptographic (encryption and message authentication of the data on the wire).
• Logging and data tagging (audit and labeling).

SROS 2 is the ROS 2 tooling that generates the keys, certificates, and XML policy files that drive these plugins. When you enable it, discovery and traffic are authenticated and encrypted, and a node can only touch the topics its permissions allow. Turned on, this closes the ROS 1 hole: an unauthenticated participant cannot join the domain, and even a valid participant is confined to its granted topics.

The catch is that none of this is on unless you configure it. A default ros2 install talks plaintext DDS with open discovery. Worse, DDS default discovery is chatty and, if the robot's subnet reaches broader networks, participants can discover each other across boundaries you did not intend. There have been publicized classes of vulnerabilities in DDS implementations themselves (parsing bugs, amplification and reflection in the discovery protocol, resource exhaustion), so even beyond configuration you keep the DDS library patched.

# The practical SROS 2 posture, in order of impact:
1. Set ROS_SECURITY_ENABLE=true and ROS_SECURITY_STRATEGY=Enforce
   (Enforce, not Permissive: Permissive lets unsecured
    participants still join, which defeats the point.)
2. Run your own Identity CA + Permissions CA; issue a
   per-node keystore. No shared keys across the fleet.
3. Write least-privilege permissions: each node gets ONLY
   the topics/services it actually uses. Default deny.
4. Constrain discovery: use a Discovery Server or scoped
   ROS_DOMAIN_ID + subnet, so participants cannot see the
   whole network.
5. Keep the DDS vendor library patched; subscribe to its CVEs.

War story: A team demos a mobile robot at a conference on the venue Wi-Fi with ROS 2 running default (no SROS 2). Someone in the audience runs ros2 topic list, sees /cmd_vel, and publishes a twist message. The robot lurches. Nothing was hacked in the exploit sense; the middleware did exactly what it is designed to do, which is let any participant on the domain publish to any topic. The lesson is that "we use ROS 2" is not a security statement. Default ROS 2 is an open bus, and the only question is who else is on the network.

Sensor spoofing and physical-signal attacks

The layers above assume the attacker comes through the network. Sensors invert that assumption: the attacker manipulates the physical world so the robot's own honest sensors report false data. Cryptography is useless here, because the falsehood enters at the transducer, before any signing or encryption applies. This is the attack class most specific to robots and autonomous systems.

GNSS / GPS spoofing. Civilian GPS/GNSS signals are unauthenticated and extremely weak at the receiver (roughly around -160 dBW), so a modest transmitter can overpower the real satellites and feed a receiver a coherent but false position and time. Spoofing is more dangerous than jamming because the receiver reports a confident wrong fix rather than no fix. Documented real-world events include large-scale spoofing near conflict zones and around sensitive sites, and researchers have walked drones and vehicles off course with it. Defenses layer up: anti-spoofing/anti-jam receivers, signal-authentication schemes (Galileo OSNMA broadcasts navigation-message authentication), multi-constellation and multi-frequency cross-checks, RTK/PPK cross-validation, inertial and visual odometry that flag a fix inconsistent with dead reckoning, and antenna techniques (CRPA arrays) that reject signals from the wrong direction. See drone navigation: GNSS & RTK for the positioning stack and counter-drone / C-UAS for the offensive side of this.

Lidar spoofing and injection. An attacker with a pulsed laser synchronized to the lidar can inject fake returns (spoof phantom obstacles) or relay/delay real returns to move an object's apparent position, and can blind or saturate the sensor. Demonstrations have added and removed obstacles from an autonomous vehicle's perception. Defenses include randomized pulse timing/coding so an attacker cannot predict the next pulse, cross-checking lidar against camera and radar, and rejecting physically implausible returns.

Camera attacks. Projected or printed adversarial patterns, laser dazzle, and infrared injection can create phantom objects, hide real ones, or fool a neural perception model into a misclassification (an adversarial sticker on a stop sign is the canonical example). Defenses combine sensor fusion, adversarial-robustness training, and plausibility checks against the other modalities.

IMU and acoustic attacks. MEMS gyroscopes and accelerometers have mechanical resonances, and a tuned acoustic tone at the resonant frequency can inject false inertial readings, enough in published work to destabilize a drone's flight controller. Defenses are physical (acoustic damping, resonance-shifted sensor design) and algorithmic (sensor fusion that rejects an IMU that disagrees with vision/GNSS).

The common thread is that no single sensor should be trusted absolutely. The general defense is estimation with built-in disagreement detection: fuse multiple modalities, and when one contradicts the consensus beyond a plausibility bound, down-weight or reject it. This is the same sensor fusion and Kalman filtering machinery used for accuracy, repurposed as a security control.

# Plausibility / consistency check (conceptual):
#   Fuse GNSS, IMU, wheel/visual odometry into one estimate.
#   Each measurement gets an innovation (residual vs prediction).
#   A spoofed GNSS jump shows up as a huge innovation that the
#   inertial + odometry prediction contradicts.
#
#   if innovation > gate * sqrt(S):     # chi-square gate on the
#       reject_or_downweight(measurement)  #  Mahalanobis distance
#
# Spoofing that is smooth and slow is harder to catch than a
# jump, which is why redundancy + authenticated signals matter.

Rule of thumb: You cannot encrypt your way out of a sensor-spoofing attack, because the lie is well-formed data arriving through the intended channel. Defend the physical layer with redundancy and cross-modality plausibility checks, and prefer authenticated signals (OSNMA GNSS) where they exist. Treat any single sensor as capturable.

Threat modeling a cyber-physical system

Threat modeling is the structured process of asking, before deployment, "who would attack this, how, and what happens." For robots the "what happens" branch reaches into the physical world, so a standard IT threat model is necessary but not sufficient.

Start with STRIDE, extend to physical outcomes. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) organizes the categories. For a robot, annotate each with its kinetic consequence: Tampering with a setpoint is unintended motion, DoS on the safety heartbeat is an unplanned stop or a bypassed guard, Spoofing a sensor is navigation into a hazard. The physical annotation is what tells you which threats are safety-critical rather than merely embarrassing.

Build a data-flow diagram and mark trust boundaries. Draw where data crosses from a less-trusted zone to a more-trusted one: internet to cloud backend, cloud to robot, teleop link to controller, sensor to perception, perception to planner, planner to motor controller. Every trust boundary is a place where you must authenticate, authorize, and validate. The motion path (command source to actuator) gets the most scrutiny.

Use attack trees for the kinetic goals. Put the attacker's physical objective at the root ("cause the arm to move outside its safe zone," "crash the drone," "halt the production line") and enumerate the paths: through the middleware, through a spoofed sensor, through the OTA channel, through a physical debug port. This surfaces the cheapest path and where a single control breaks many branches.

Map the ATT&CK for ICS kill chain. MITRE ATT&CK for ICS catalogs adversary techniques against industrial control systems (initial access via the engineering workstation, lateral movement across a flat OT network, manipulation of control, inhibition of a safety function). Robots inherit this playbook because they are control systems. Walking your architecture against those techniques finds the gaps a purely-IT model misses, especially the "inhibit response function" and "impair process control" tactics that have no IT-side analogue.

The output of threat modeling is a ranked list of risks tied to controls, and the ranking is by physical consequence times likelihood. The command path and the safety path sit at the top, the fleet-update channel close behind because of its blast radius, and data-confidentiality threats usually below them, an inversion of the typical IT priority.

Rule of thumb: The question that separates a robot threat model from an IT one is "what moves if this succeeds?" If the answer is a joint, a wheel, or a rotor, that threat is safety-critical and gets a control with the rigor of a safety function, including a failure mode that fails safe.

The safety-security interplay

Functional safety and cybersecurity are two answers to the same question, "how do we stop this machine from hurting someone," against two different adversaries. Safety engineering (see robot safety and functional safety) protects against random and systematic failures: a sensor dies, a wire shorts, a bug fires. It is quantified with probabilistic targets: a Safety Integrity Level (SIL, from IEC 61508) or a Performance Level (PL, from ISO 13849), each with a required probability of dangerous failure per hour. Security protects against a deliberate, adaptive human adversary who will find and exploit the one path your probabilities assumed was independent.

The two intersect in a way that is easy to get wrong.

A security failure can defeat a safety function. A safety-rated speed-and-separation monitor that slows a cobot when a person is near is a safety function. If an attacker can reach the network that carries the "person detected" signal and suppress it, the safety function silently stops protecting anyone, and the probabilistic safety case (which assumed only random failures) is void. Safety functions were historically designed assuming benign faults; a networked robot breaks that assumption, so the safety function's inputs and logic now need security controls to hold their integrity.

A security control must not create a safety hazard. A lockout that bricks the robot on a failed authentication, or a firewall that adds latency to a real-time safety message, can itself cause a dangerous state. The classic principle is that on a genuine safety event the system fails to a safe state (stop, de-energize), and a security mechanism must not override or delay that. When a security control and a safety requirement conflict, the safe state wins.

The standards are converging. In automotive, ISO 26262 (functional safety) and ISO/SAE 21434 (cybersecurity) are now applied together, and the notion of a "cybersecurity assurance level" parallels the safety integrity level. In industrial systems, IEC 61508/62061/ISO 13849 (safety) sit alongside IEC 62443 (security), and the current guidance is to run a combined safety-and-security risk assessment rather than two disconnected ones. The practical demand is a single analysis where each safety function's inputs, logic, and outputs are reviewed for both random failure and deliberate compromise.

Safety rule: Design the safe state to be reachable independently of anything an attacker can touch. A hardwired e-stop and a safety-rated controller that cannot be reprogrammed over the network are worth more than any software guard, because they hold even when the compute stack is fully owned. Keep the last line of defense out of the attacker's reach.

Secure design: authentication, encryption, segmentation

The controls that actually move the needle are well known from OT and IT security, adapted for the real-time and physical constraints of robots.

Authenticate every actor and every device. No default credentials, ever (a large share of IoT and robot compromises are just default passwords). Per-device identity via X.509 certificates or hardware-backed keys, mutual authentication on every connection (robot to cloud, teleop to robot, node to node via SROS 2), and short-lived, rotatable credentials. A stolen credential should expire and should not unlock the whole fleet.

Encrypt data in transit and at rest. TLS (mutual TLS for machine-to-machine) on every network link, DDS-Security encryption on the middleware, disk encryption for maps and configuration that reveal the environment. Encryption protects against sniffing and man-in-the-middle on the increasingly-wireless links robots depend on, and it is cheap outside the innermost real-time loop.

Segment the network ruthlessly. This is the single highest-ROI architectural control. Put the real-time control network (the fieldbus, the safety network, the motor controllers) on its own segment, isolated from the robot's application compute, which is in turn isolated from the enterprise IT network and the internet. The reference model is the Purdue/ISA-95 hierarchy that industrial automation uses: levels from the physical process up through control, supervisory, and enterprise, with firewalls (and a DMZ) mediating every level crossing. For the tightest cases a data diode enforces one-way flow so telemetry can leave the control zone but nothing can come back in. Most catastrophic OT incidents began with a flat network where an ordinary IT compromise (a phished laptop) had an unobstructed path to the control plane.

Enforce least privilege everywhere. Each node, service, and cloud API gets only the permissions it needs (default deny in the SROS 2 permissions file, scoped cloud IAM roles, no blanket admin). A compromised perception node should not be able to command motion; a compromised telemetry uploader should not be able to push firmware.

Harden the hosts. Minimal OS image, no unused services, closed management ports (or reachable only over a VPN/bastion), disabled physical debug interfaces in production, application sandboxing, and read-only or immutable root filesystems where feasible. Every open port and running service is surface you have to defend.

Control	Protects against	Robot-specific note
Mutual TLS + per-device certs	MITM, credential theft, impersonation	Rotate keys; never share one key across a fleet
SROS 2 / DDS-Security	Rogue middleware participant, sniffing	Enforce mode, least-privilege permissions
Network segmentation + firewall	Lateral movement from IT to control	Isolate real-time + safety network; Purdue model
Least privilege / default deny	Privilege escalation, blast radius	Perception node must not reach the motor bus
No default credentials	Trivial remote takeover	Audits and scans find these first
Host hardening, closed ports	Remote exploitation, persistence	Disable JTAG/UART in production

Rule of thumb: If you do only one thing, segment the network so that reaching the control plane requires crossing a firewall you control. Segmentation contains the blast radius of every other failure, and it is the control that most reliably turns a fleet-ending incident into a single-node one.

Firmware, secure boot, and supply chain / SBOM

The layers below the OS are where an attacker goes for persistence, and the supply chain is where they go for scale.

Secure boot with a hardware root of trust. The boot chain verifies each stage's signature before executing it: an immutable boot ROM checks the bootloader, which checks the OS image, which checks the application, anchored in a key fused into the silicon or held in a secure element (TPM, secure enclave). Secure boot stops a persistent implant: an attacker who modifies the firmware breaks the signature and the device refuses to boot (or boots a known-good recovery image). Without it, a single firmware write survives every OS reinstall.

Signed firmware and anti-rollback. All firmware and OS updates are cryptographically signed by a key the device trusts, and the device enforces a monotonic version counter so an attacker cannot downgrade to an older, vulnerable version whose signature is still valid (a rollback attack). Measured boot (recording each stage's hash into a TPM) supports remote attestation, letting a fleet manager verify a robot is running known-good software before trusting it.

The supply chain is the highest-leverage target. Modern robot software is mostly third-party: dozens to hundreds of open-source ROS packages, container base images, language runtimes, and vendor binary blobs. A poisoned dependency (a malicious package version, a typosquatted name, a compromised upstream maintainer) or a compromised build pipeline ships malware to everyone downstream. The mitigations are provenance and inventory: pin and verify dependency versions and checksums, build from trusted sources with a hardened CI pipeline, sign your own artifacts, and generate a Software Bill of Materials.

SBOM: you cannot patch what you cannot see. An SBOM is a machine-readable inventory of every component and version in a build (formats: SPDX, CycloneDX). Its security value is speed of response: when the next widely-used-library CVE drops (the Log4j event is the reference case, where organizations spent weeks just discovering where the library was), an SBOM turns "are we affected, and which robots?" from a multi-week manual hunt into a database query. Regulation is making it mandatory: US Executive Order 14028 requires SBOMs for software sold to the federal government, and the EU Cyber Resilience Act (with obligations phasing in through 2027) requires vulnerability handling and effectively an SBOM for products with digital elements sold in the EU, robots included.

# Vulnerability-response loop that an SBOM enables:
new CVE published  ->  query SBOM inventory for affected
                       component + version across the fleet
                   ->  identify exact robots/firmware images
                   ->  build + sign patched image
                   ->  staged OTA rollout with rollback
                   ->  attest patched version via measured boot
# Without an SBOM, step 1->2 is a manual audit that can take weeks.

Rule of thumb: Treat every third-party component as untrusted code you are choosing to run, and keep a signed inventory of all of it. The two firmware controls that matter most are secure boot (stops persistence) and signed, anti-rollback updates (stops downgrade and poisoned pushes). Everything else assumes these hold.

Standards: IEC 62443 and the certification map

You will be audited against frameworks, and knowing the map saves months. The robotics-relevant standards fall into a few families.

IEC 62443 is the central framework for industrial automation and control system (IACS) security, and it is where most robot security programs anchor. It is a family of standards covering the asset owner, the system integrator, and the product supplier. Two concepts recur. Zones and conduits: you partition the system into security zones (groups of assets with a common security level) connected by controlled conduits (the communication paths between zones), which is the formalization of network segmentation. Security Levels (SL 1 to 4): SL 1 defends against casual or accidental violation, up to SL 4 against a sophisticated, well-resourced actor with specific intent. You assign a target SL per zone based on consequence, then implement the foundational requirements (identification/authentication, use control, system integrity, data confidentiality, restricted data flow, timely response, resource availability) to meet it. IEC 62443-4-1 (secure development lifecycle for the supplier) and 62443-4-2 (technical requirements for components) are the parts a robot maker builds to; 62443-3-3 (system security requirements) is what an integrator satisfies.

Safety standards run in parallel and must be co-satisfied. ISO 10218 (industrial robots), ISO/TS 15066 (collaborative robots), and ISO 13849 / IEC 62061 (safety of machinery control systems) define the safety case. As covered above, the current expectation is a combined safety-and-security assessment.

Sector and general frameworks fill in the rest. ISO/SAE 21434 (road-vehicle cybersecurity) and UN Regulation No. 155 govern automotive and by extension self-driving platforms. The NIST Cybersecurity Framework and NIST SP 800-82 (guide to OT security) provide the general OT program structure. IEC 63074 specifically addresses the security aspects of safety-related control systems, bridging the two worlds. The EU Cyber Resilience Act and the Machinery Regulation (EU 2023/1230, which for the first time brings cybersecurity into machinery safety requirements) are the emerging regulatory teeth.

Standard / framework	Scope	What it gives you
IEC 62443 (family)	Industrial control system security	Zones/conduits, Security Levels, SDL, component requirements
ISO/SAE 21434 + UN R155	Automotive / AV cybersecurity	CSMS, cybersecurity assurance levels, type approval
ISO 10218 / TS 15066	Industrial and collaborative robot safety	The safety case that security must protect
IEC 63074	Security of safety-related control systems	The explicit safety-security bridge
NIST CSF / SP 800-82	General + OT security program	Identify-Protect-Detect-Respond-Recover structure
EU CRA / Machinery Reg. 2023/1230	EU market products with digital elements	Mandatory vuln handling, SBOM, security-by-design

Rule of thumb: Anchor on IEC 62443's zones-and-conduits and Security Levels for the architecture, satisfy the machinery safety standards jointly, and let the applicable regulation (CRA in the EU, sector rules elsewhere) set the compliance floor. The standards agree more than they differ: segment, authenticate, sign, monitor, and document.

Fleet and OTA update security

A single robot is a bounded risk. A fleet sharing a cloud backend and an update channel is where a compromise becomes a fleet-wide catastrophe, so fleet and OTA security carry the largest blast radius in the whole system.

Over-the-air updates are the double-edged sword. OTA is essential (it is the only way to patch vulnerabilities across a deployed fleet quickly), and it is also a direct path to push code to every robot at once. A compromised update server, or a fleet that accepts unsigned updates, lets an attacker deliver malware to the entire population in one action. The defenses:

• Sign every update with a key held offline or in an HSM, and have each robot verify the signature before installing. This is the single most important OTA control.
• Use a robust update framework. TUF (The Update Framework) and its automotive profile Uptane were designed for exactly this threat, with separated roles and thresholds of keys so that compromising one key does not let an attacker forge a valid update, and with protections against freeze, rollback, and mix-and-match attacks. Uptane is the reference for vehicles and applies directly to robot fleets.
• Stage the rollout. Canary to a small cohort, monitor for failures and anomalies, then expand. A bad or malicious update caught in the canary phase does not reach the fleet.
• Support atomic update and automatic rollback. A/B partition schemes let a failed update revert to the last known-good image without bricking the robot, which also removes the temptation to disable signature checks "to recover a stuck device."
• Verify the result. Measured boot and remote attestation confirm each robot actually booted the intended version.

Fleet identity and backend security. Each robot gets a unique, hardware-backed identity so one stolen credential does not impersonate the fleet. The cloud backend uses least-privilege APIs (a telemetry endpoint cannot issue commands), mutual TLS, rate limiting, and strong isolation between tenants and between the telemetry and command planes. The fleet-command channel (the path that can tell many robots to move) is the crown jewel and gets the strongest authentication, authorization, and monitoring you have.

Remote teleoperation deserves its own hardening because it is a live human-to-actuator path over a network. Encrypt and mutually authenticate the link, authorize the operator, log every session, and enforce a safe fallback (stop) on link loss or anomaly. See robot teleoperation for the operational side and edge AI / robot compute for where the on-robot autonomy that must survive a link drop lives.

War story: The failure pattern that keeps recurring is the un-isolated cloud command API. A fleet operator exposes a management endpoint that, through a missing authorization check or a leaked API token, lets a request issue movement or configuration commands to many robots. The cause is a business-logic and access-control gap in the backend, with no memory-corruption exploit involved. The blast radius is the whole fleet, which is why the command plane must be isolated from telemetry, least-privileged, and monitored as the highest-value asset you run.

Detection, monitoring, and incident response

Prevention fails eventually, so you also need to see the compromise and recover from it. Robots add a physical dimension to detection that pure-IT monitoring lacks.

Monitor the network and the middleware. Intrusion detection tuned for OT protocols and for DDS/ROS traffic patterns catches an unexpected participant joining the domain, a topic being published by the wrong source, or anomalous discovery traffic. Baseline the normal communication graph (which node talks to which) and alert on deviations; robot communication is far more regular than enterprise IT traffic, which makes anomalies stand out.

Monitor the physical process. This is the robot-specific layer. A command stream that violates the kinematic or safety envelope (a velocity spike, a path outside the mapped free space, a torque that does not match the commanded motion) is a signal that either a fault or an attack is underway. Cross-checking the commanded behavior against a physics model, and against the safety-rated monitor, catches manipulations that look valid at the network layer but are physically wrong. Sensor plausibility checks (from the spoofing section) feed the same detection.

Log with integrity and centralize. Tamper-evident logs (append-only, signed, or shipped off-device in real time) from robots, backend, and network, aggregated in a SIEM, are what let you reconstruct an incident. An attacker who can edit local logs erases their tracks, so get the logs off the device fast.

Plan the response for a machine that moves. An incident-response plan for robots has a step no IT plan has: bring the physical system to a safe state first. Isolate the affected robot (or fleet segment) from the network, trigger the safe stop, preserve forensic state, then investigate. Practice the fleet-wide "stop and isolate" so that when a compromised-update or command-injection alarm fires, the operator can halt motion across the fleet in seconds. Recovery means reflashing from known-good signed images, rotating the compromised credentials, and only then bringing robots back online with attestation.

Rule of thumb: Your first incident-response action on a robot is physical: reach the safe state. Everything else (isolate, preserve, investigate, recover) follows, but a machine that can move must be made safe before you start the forensics.

Frequently asked questions

Is ROS 2 secure by default? No. ROS 2 supports strong security (authentication, access control, and encryption through DDS-Security and SROS 2), but it is off unless you deliberately enable it. A default ros2 install communicates in plaintext with open discovery, so any participant that reaches the domain can publish, subscribe, and disrupt. Enable SROS 2 in Enforce mode, run your own CA, and write least-privilege permissions. Original ROS 1 has no security model at all and must never touch an untrusted network.

What is the single most important robot security control? Network segmentation. Isolating the real-time control and safety network from the application compute, the enterprise IT network, and the internet, with a firewall mediating every crossing, contains the blast radius of nearly every other failure. Most catastrophic OT incidents began on a flat network where an ordinary IT-side compromise had an open path to the control plane.

Can I encrypt my way out of GPS or sensor spoofing? No. Spoofing injects false but well-formed data at the sensor, before any signing or encryption applies, so cryptography on the internal network does not help. Defend it with sensor fusion and plausibility checks (an inertial or visual estimate that contradicts the GNSS fix flags the spoof), redundancy across modalities, authenticated signals where they exist (Galileo OSNMA), and anti-spoofing receivers and antenna arrays for GNSS.

How are safety and security related on a robot? They defend the same thing (the machine not causing harm) against different adversaries: safety against random and systematic faults, security against a deliberate attacker. They interact directly. A security breach can defeat a safety function by suppressing its inputs, and a badly-designed security control can itself cause a hazard. The current standards expect a combined safety-and-security assessment, and the safe state must remain reachable independently of anything an attacker can touch.

What is IEC 62443 and do I need it? IEC 62443 is the primary framework for industrial control system security, built around security zones connected by controlled conduits and Security Levels (SL 1 to 4) chosen by consequence. If you build or operate industrial robots or automation, it is the framework you will be assessed against: suppliers build to 62443-4-1 and 4-2, integrators to 62443-3-3. It formalizes the segmentation, authentication, and integrity controls that robot security needs anyway.

Why does OTA update security matter so much? Because the update channel can push code to your entire fleet in one action, a compromised update server or a robot that accepts unsigned updates is a path to fleet-wide compromise. Sign every update (key in an HSM), use a framework like TUF/Uptane that survives single-key compromise, stage the rollout with a canary, support atomic update with automatic rollback, and verify the installed version with attestation. OTA is essential for patching, which is exactly why it must be locked down.

What is an SBOM and why do I need one? A Software Bill of Materials is a machine-readable inventory of every component and version in your software (SPDX or CycloneDX format). When a widely-used library gets a critical CVE, an SBOM turns "which of our robots are affected?" from a multi-week manual hunt into a fast query, which is the whole point. It is increasingly mandatory: US EO 14028 and the EU Cyber Resilience Act both require it in effect for products they cover.

How do I secure firmware against a persistent implant? Secure boot with a hardware root of trust, where each boot stage verifies the next stage's signature anchored in silicon or a secure element, so tampered firmware fails to boot. Add signed updates with anti-rollback (a monotonic version counter blocks downgrade to a vulnerable signed version), disable physical debug ports (JTAG/UART) in production, and use measured boot for remote attestation. Without secure boot, one firmware write survives every OS reinstall.

Are robots really attacked in the real world, or is this theoretical? Both the theory and the incidents are real. Internet scans routinely find exposed robot and industrial control interfaces reachable from the public internet, default credentials are a leading cause of IoT and robot compromise, GNSS spoofing has affected drones and vehicles in the field, and researchers have demonstrated lidar injection, adversarial camera attacks, and acoustic IMU attacks on real hardware. The physical consequences (unintended motion, disabled safety functions, stopped lines) make robots an attractive target as they connect to networks.

Where should I start if my robots have no security at all? In order of impact: change all default credentials and close exposed management ports; segment the control network off the enterprise network and the internet; enable middleware security (SROS 2 in Enforce mode for ROS 2); require signed OTA updates with rollback; generate an SBOM so you can respond to vulnerabilities; and add secure boot and per-device identity as you refresh hardware. Segmentation and killing default credentials give the biggest immediate risk reduction.