Robotics
Robotics security for ROS 2 robots and drones
Robotics security is the protection of a robot's or drone's software, firmware, communications and update path against attacks that could expose data or cause unsafe behaviour. For a ROS 2 robot or a drone, that means enforcing SROS 2 on DDS traffic, keeping companion-computer and flight-controller firmware patched, and tracking every third-party package you ship.
Free plan, no card required.
What is the attack surface of a robot or drone?
A modern robot is a small distributed system on wheels, legs or propellers: a real-time controller for motion and safety, a companion computer for perception and connectivity, middleware that connects the processes, radio links and an update mechanism. Each layer brings third-party code, and each boundary between layers is an interface an attacker can try to use.
- Middleware: ROS 2 nodes exchange messages over DDS. Without security enabled, participants are not authenticated, so anything on the same network and DDS domain can read topics and publish messages.
- Companion computers: usually Linux, with a kernel, system libraries, network services and remote access that all need patching.
- Flight controllers: PX4 runs primarily on the NuttX real-time operating system on flight-control boards; ArduPilot runs on ChibiOS on STM32-based boards and also supports Linux-based boards.
- Telemetry links: MAVLink connects flight controllers, companion computers and ground stations. MAVLink 2 message signing lets a system verify that messages come from a trusted source, but it does not encrypt them.
- Over-the-air updates: an unprotected update channel lets an attacker install malicious code on every unit.
- Third-party packages: ROS packages, Python and C++ libraries, container images and vendor drivers that you did not write but do ship.
How does ROS 2 security (SROS 2) work?
ROS 2 security builds on the DDS-Security specification. The ROS 2 design documentation describes three plugins in use: authentication of each participant with X.509 certificates signed by a certificate authority you trust; access control, where signed governance and permissions files define how the domain is secured and which topics each participant may read or write; and a cryptographic plugin that provides authenticated encryption with AES-GCM. The runtime support and tools are called Secure ROS 2 (SROS 2), and security files are organised per enclave in a keystore.
The detail that matters most in practice: by default, none of these features are enabled. Security is switched on with the ROS_SECURITY_ENABLE environment variable, and unless ROS_SECURITY_STRATEGY is set to Enforce, a process that cannot find its security files starts without security instead of failing. For a product, use Enforce, manage the certificate authorities and private keys like any other production secret, and review permissions whenever nodes are added, so that a camera driver cannot publish velocity commands.
Drone firmware security: flight controllers, companion computers and updates
Drone firmware security splits along the hardware. The flight controller runs the autopilot on a microcontroller with a real-time operating system. The companion computer is closer to a small server, and talks to the flight controller over MAVLink or, with PX4, also uXRCE-DDS for ROS 2. Treat them as two products: different toolchains, update paths and ways of listing components.
For both, the controls are familiar. Know the exact components and versions in each build; sign firmware and verify signatures before installing; lock down debug interfaces and bootloaders; and keep a record of which firmware version runs on which airframe. On radio links, enable MAVLink 2 message signing where supported.
Does the Cyber Resilience Act apply to robots and drones?
The CRA applies to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. A robot or drone with such a connection will usually fall within that definition unless an exclusion applies. That brings the Annex I essential requirements and vulnerability handling for products placed on the market from 11 December 2027 and, since 11 September 2026, the Article 14 duty to report actively exploited vulnerabilities and severe incidents. The CRA does not apply to products certified under Regulation (EU) 2018/1139, the EU aviation safety regulation, so check the position of each drone model.
Robot makers usually meet a second law: the Machinery Regulation (EU) 2023/1230, which applies from 20 January 2027 and includes safety requirements on protection against corruption and on control systems that withstand malicious attempts. CRA recital 53 says meeting the CRA could facilitate compliance with those requirements, but the manufacturer has to demonstrate the link. The Machinery Regulation excludes means of transport by air, and aeronautical products covered by Regulation (EU) 2018/1139 insofar as that regulation covers the relevant requirements, so check how both exclusions apply to a drone.
Securing third-party ROS packages and dependencies
Robot software is assembled from ecosystems: ROS packages declared in package.xml, system dependencies resolved through rosdep keys, source repositories pulled with vcstool .repos files, Python and C++ libraries, and the Linux distribution underneath. The CRA requires due diligence on third-party components, including open source (Article 13(5)), and an SBOM covering at least the top-level dependencies (Annex I Part II). In practice, you need to know which versions ended up in the image you shipped, not only which ones the workspace asked for.
Practical steps: pin versions in rosdep and .repos files; generate the SBOM from the built image or container, not only from source manifests; follow the security advisories of your DDS implementation and your Linux distribution; track the end-of-life date of the ROS 2 distribution you build on; and give each robot model a support period and an update path you can actually deliver for its lifetime.
Available in KROMSE today
KROMSE covers several layers of a robot's software today; robot-specific vulnerability data is still on the roadmap.
- ROS package manifests (package.xml, rosdep keys, vcstool .repos files) are listed in the inventory; most are not matched to advisories yet, except components pinned to a commit or tag on a public forge or with a PyPI, npm, crates.io or Go package identifier.
- Dependencies of ROS nodes are checked against OSV.dev where a supported lockfile or manifest exists, such as pip requirements, Poetry or uv for Python. C++ build files such as CMake, Conan and vcpkg are listed, and mostly not matched to advisories yet.
- Source code analysis for 11 languages, including C, C++ and Python.
- Linux firmware images for companion computers, up to 512 MB, are unpacked; packages and binaries are checked for known vulnerabilities, and the root file system is also checked for misconfigurations and secrets.
- PX4 .px4 files are unwrapped and scanned like other firmware, but the NuttX components inside are not identified yet.
- Container images in a registry reachable from the internet, such as the images your ROS 2 nodes run in, are analysed for vulnerabilities, misconfigurations and secrets.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q4 2026 (December)Robotics security. KROMSE will add ROS 2 advisories, component identification inside PX4 and ArduPilot firmware, and robot-specific vulnerability data.
- Coming · Q1 2027Bare-metal and RTOS firmware. KROMSE will identify components in firmware without a Linux file system, such as bare-metal and RTOS images built on FreeRTOS or Zephyr.
- Coming · Q1 2027Machinery Regulation evidence. KROMSE will collect evidence for the cybersecurity-related requirements of the EU Machinery Regulation (EU) 2023/1230, next to your CRA record.
Frequently asked questions
Is ROS 2 secure by default?
No. ROS 2 can use DDS-Security for authentication, access control and encryption through SROS 2, but the ROS 2 design documentation states that none of these security features are enabled by default. You enable them with ROS_SECURITY_ENABLE, and you should set ROS_SECURITY_STRATEGY to Enforce so that a node without valid security files fails to start instead of running unprotected.
What is SROS 2?
SROS 2, or Secure ROS 2, is the set of features and tools that expose DDS-Security in ROS 2. It uses X.509 certificates for authentication, signed governance and permissions files for access control, and AES-GCM for authenticated encryption, with security files stored per enclave in a keystore. The ROS 2 design also describes a ros2 security command-line tool to generate these files.
Does the Cyber Resilience Act apply to drones?
It can. The CRA covers products with digital elements that have a data connection to a device or network, which includes many drones, but it does not apply to products certified under Regulation (EU) 2018/1139, the EU aviation safety regulation. Whether a particular drone is excluded depends on its certification. KROMSE does not decide whether a law applies, so confirm the position for each model.
Can KROMSE scan PX4 or ArduPilot firmware?
Partly. PX4 .px4 files are unwrapped and scanned like other firmware, but the NuttX components inside are not identified yet, so the result is limited. ArduPilot firmware and other bare-metal or RTOS images are not supported today. Linux-based companion-computer images up to 512 MB are unpacked and scanned. Component identification for PX4 and ArduPilot is on the roadmap.
What should a robot maker prepare for the CRA first?
Start with an inventory: an SBOM for each released robot model and firmware version, covering the companion computer, the controller firmware and the ROS workspace. Then set a support period, a signed update path you can deliver for that period, a coordinated vulnerability disclosure policy with a contact address, and a process for reporting actively exploited vulnerabilities within 24 hours of becoming aware.
Related guides
Sources
- ROS 2 design: ROS 2 DDS-Security integration
- ROS 2 documentation: End-of-Life distributions
- PX4 documentation: architectural overview
- PX4 documentation: companion computers
- ArduPilot developer documentation: introduction
- MAVLink: message signing
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- Regulation (EU) 2023/1230 (Machinery Regulation), EUR-Lex