No. ROS 2 can authenticate participants, control which topics they use and encrypt traffic, but those protections come from DDS-Security and the SROS 2 tooling, and they are disabled by default. A robot you have not configured will talk to any participant that reaches it on the network.
What "off by default" means in practice
The ROS 2 design documentation describes security as the set of features collectively called SROS 2, and states that they are disabled by default. In a lab with one laptop and one arm that is a fair trade, because setup stays simple. On a plant network, a warehouse Wi-Fi or a shared test bench, it is not.
If security is off, any machine that can join the same DDS domain can discover your nodes, read topics and publish to them. A command topic that moves a joint or a mobile base is only as protected as the network around it.
What SROS 2 adds when you enable it
The design document names three DDS-Security plugins that ROS 2 uses:
- Authentication verifies the identity of a domain participant, using keys and x.509 certificates signed by a trusted certificate authority.
- Access control limits what an authenticated participant may do, such as which topics it may read or write, driven by governance and permissions files.
- Cryptography handles encryption, signing and hashing, using an authenticated encryption plugin.
These give you identity, authorization and confidentiality at the middleware layer. The design document notes that without a securely confirmed identity it would be very hard to make sure a given ROS identity can only reach specific topics, which is why authentication comes first.
What it does not do
SROS 2 secures the conversation between ROS participants. It does not patch the operating system, harden a web dashboard, protect a vendor teleoperation tool, or limit who can log in over SSH. It also says nothing about the safety function of a robot, which is a separate engineering discipline.
Treat it as one layer. You still want network segmentation, a short list of reachable services and an inventory of what runs on the robot.
First steps for a real deployment
- Decide which robots and nodes need protection first. Anything that sends motion commands is a good start.
- Create a keystore and per node identities, as covered in our post on setting up an SROS 2 keystore and enclaves.
- Start in a test environment, because a wrong permissions file stops nodes from talking and the failure can look like a networking bug.
- Write permissions that list only the topics each node needs.
- Put the middleware strategy on enforce once the system works, so a missing credential stops a node rather than letting it through.
Plan for testing time. Security plugins add work to every message, so check latency on your own hardware rather than assuming it is fine.
A note on teams and handover
The default only becomes a problem when nobody owns the decision. Write down who turns security on for each robot, where the keystore lives and who can read it. When a prototype becomes a product, make enabling security part of the release checklist, not a later task. A robot that leaves your lab with the defaults will usually keep them for its whole working life, because the people who receive it rarely have the context to change them.
Quick check
Does turning on SROS 2 make a robot safe?
No. It protects the ROS communication layer. Physical safety depends on the robot's safety functions and the standards behind them, and host security still depends on patching and access control.
Is ROS 2 insecure, then?
It is capable of strong protection, but only when you configure it. The risk is deploying the defaults to a network you do not control.
Sources
Last reviewed: 19 October 2026.
