ROS 1 had no built in security model, because flexibility was valued above everything else. ROS 2 runs on DDS, which has a security specification, so identity, access control and encryption are possible. They are still off until you enable them. The change is capability, not default behavior.
How the ROS 2 design document frames it
The ROS 2 design document says that in ROS 1 flexibility was valued above all else, at the cost of security. It then says ROS 2 can keep that flexibility while being secured through DDS-Security. That is a useful summary of the whole shift.
In practical terms, ROS 1 gave you a graph of nodes that trusted each other. If you could reach the network, you were part of the system. ROS 2 gives you a way to say who a participant is and what it may do.
Side by side
| Question | ROS 1 | ROS 2 |
|---|---|---|
| Built in participant identity | No | Yes, through DDS-Security authentication |
| Per topic permissions | No | Yes, through access control and permissions files |
| Encrypted traffic | No | Yes, through the cryptographic plugin |
| Enabled out of the box | Not applicable | No, disabled by default |
| Middleware | ROS specific | DDS, from several vendors |
The ROS 2 column is a capability list. Each row only applies once you set it up.
What ROS 2 did not fix
- Defaults. You still have to turn security on, as described in our post on ROS 2 defaults.
- Everything around the middleware: the operating system, remote shells, web tools, update channels and third party packages.
- Mixed fleets. Many sites run ROS 1 and ROS 2 together through bridges, and a bridge is a point where the weaker side sets the floor.
If you still run ROS 1
Treat the network as the security boundary, because the software offers none. That means a dedicated segment for the robot, no route from the internet, and tight control over who can join the segment. A VPN or a gateway in front of the robot network is a common pattern, but check that it does not simply extend the trusted segment to every laptop that connects.
Plan a migration for anything that will live more than a few years, and use the move to add an inventory of packages and their versions.
Which should you pick for a new project?
For a new build, ROS 2 is the choice that gives you security options. Whether you use them is up to you, and the sooner you start, the cheaper the permissions work is, because you design topic names and nodes with access in mind.
A migration habit worth adopting
When you port a node, do not only move the code. Note which topics it publishes and subscribes to, because those lists become the seed of your permissions file. A migration that records topic access as it goes gives you least privilege almost for free, while one that ignores it leaves you to reconstruct the information later from running systems.
Quick check
Is ROS 2 automatically more secure than ROS 1?
Not automatically. It is capable of more, but its security features are disabled by default, so an unconfigured ROS 2 system is open in much the same way.
Sources
Last reviewed: 19 October 2026.
