FAQ
ROS1 vs ROS2 — security differences
ROS1 was designed with zero security primitives — communication is plaintext, there is no authentication, and any node on the network can publish or subscribe to anything. ROS2, built on DDS, has a security framework called SROS2 that provides authentication, encryption, and access control. But SROS2 is opt-in, and many production ROS2 deployments do not enable it — in which case ROS2 has essentially the same security posture as ROS1, just on a different transport.
Short answer
ROS1 was designed with zero security primitives — communication is plaintext, there is no authentication, and any node on the network can publish or subscribe to anything. ROS2, built on DDS, has a security framework called SROS2 that provides authentication, encryption, and access control. But SROS2 is opt-in, and many production ROS2 deployments do not enable it — in which case ROS2 has essentially the same security posture as ROS1, just on a different transport.
The practical security model
| Feature | ROS1 | ROS2 (SROS2 off) | ROS2 (SROS2 on) | |---|---|---|---| | Authentication | None | None | DDS-Security based on X.509 certificates | | Transport encryption | None | None (RTPS plaintext) | DDS-Security encryption | | Access control | None | None | DDS-Security ACL: per-topic publish/subscribe permissions | | Topic discovery | ROS Master (central) | DDS dynamic discovery (multicast) | DDS discovery, restricted by ACL | | Default state | Open | Open | Secured |
In ROS1, the ROS Master process holds the topic registry. Any node that can reach the master can register as a publisher or subscriber. In ROS2, the master concept is gone — DDS discovery is peer-to-peer via multicast. Without SROS2 enabled, this is more open than ROS1: any process on the same multicast domain can join.
What this means for assessment
For a Melina ROS engagement, the first scoping question is "is SROS2 enabled?" If yes, we assess the configuration: are the certificate authorities operationally secured, are ACLs configured to enforce least-privilege, is the certificate rotation policy realistic, is key material protected during build and deploy. If SROS2 is not enabled, the assessment scope changes — we focus on network-perimeter assumptions (because perimeter is the only control), on motion-control safety boundaries (because compromise on the bus implies motion-control compromise), and on what an attacker who reaches the internal network can do in worst case.
The most common production posture we see is "SROS2 not enabled; we rely on network isolation." That's a workable posture for closed industrial systems with no remote access, but it fails the moment the robot has a cloud connection, a maintenance VPN, or a debug interface left enabled in the field.
Related FAQs
- FastDDS vs CycloneDDS vs Connext security (P1.5)
Related services and research
- Robotics & Autonomous Systems Security - ROS2 Security Baseline guide
---