ROS 2 security: SROS2, DDS and network hardening

Why ROS 2 is open by default

ROS 2 communicates over DDS. Out of the box, DDS discovery uses multicast on the local network, and any process that joins the same ROS domain can list, subscribe to and publish on every topic. For domain 0, discovery and data traffic use UDP ports starting at 7400.

ROS_DOMAIN_ID keeps separate systems from interfering with each other, but it isn't a security control. Anyone can set the same domain ID.

ROS 1 is weaker still. The ROS master on TCP port 11311 accepts registrations and commands from anyone who can reach it. ROS 1 Noetic reached end of life in May 2025, so ROS 1 robots should be isolated and moved to ROS 2.

What SROS2 adds

Turning on SROS2

The basic steps with the ROS 2 command-line tools:

# 1. Create a keystore (your certificate authority)
ros2 security create_keystore ~/sros2_keystore

# 2. Create an enclave for each node or group of nodes
ros2 security create_enclave ~/sros2_keystore /cell1/arm_controller

# 3. Turn security on and enforce it
export ROS_SECURITY_KEYSTORE=~/sros2_keystore
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce

# 4. Start the node in its enclave
ros2 run my_pkg arm_controller --ros-args --enclave /cell1/arm_controller

Then tighten permissions so each enclave can use only the topics it needs, with ros2 security create_permission and a policy file. Keep the keystore's private keys off the robots, and test in Enforce mode before production. Permissive mode lets nodes without security keep connecting, so use it only for testing.

Network exposures to close

• Discovery range. On ROS 2 Iron and later, set ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST for nodes that only talk on the same machine, and use SUBNET only where needed.
• rosbridge and web dashboards. rosbridge (TCP 9090 by default) and similar bridges give anyone who can reach them full ROS access over WebSocket. Bind them to localhost, or put them behind authentication and a firewall.
• Shared networks. Keep robots off networks shared with office PCs and guest Wi-Fi.
• Remote login. Use SSH keys on robot computers, with no shared accounts and no password logins.
• Software supply. Install packages from trusted sources, pin versions, and keep the operating system and ROS distribution in support.

ROS 2 security checklist

1. Isolate. Put ROS robots on their own network segment, behind a firewall.
2. Enable SROS2. Create a keystore, give every node an enclave and set the strategy to Enforce.
3. Least privilege. Write permissions so each enclave can use only its own topics.
4. Limit discovery. Restrict the discovery range to localhost or the subnet that needs it.
5. Close bridges. Bind rosbridge and dashboards to localhost or protect them with authentication.
6. Protect keys. Keep the certificate authority's private key off the robots and rotate enclave certificates.
7. Update. Stay on a supported ROS 2 distribution and operating system.
8. Retire ROS 1. Isolate remaining ROS 1 systems and plan their migration.

Common questions

Related