ROS 2 uses three of the five DDS-Security plugin interfaces: authentication, access control and cryptography. Authentication proves who a participant is, access control limits what it can do, and cryptography encrypts and signs the traffic. The other two interfaces, logging and data tagging, are not used.
Authentication
The design document defines this plugin as verifying the identity of a given domain participant. ROS 2 uses the built in PKI based plugin, which relies on keys and x.509 certificates signed by a trusted certificate authority.
What it protects against: an unknown machine joining your domain and posing as a node. Without it, access control has nothing reliable to attach to. The document puts it plainly: without a securely confirmed identity it would be very hard to make sure a ROS identity could only reach specific topics.
Access control
This plugin enforces restrictions on the DDS operations an authenticated participant may perform. It can restrict which domains a participant joins, and which topics it may read or write. The built in plugin needs governance and permissions files.
Think of governance as domain level rules and permissions as per participant rules. A camera driver might be allowed to publish images and read nothing. A planner might read images and publish velocity commands. A diagnostics tool might read everything and publish nothing.
What it protects against: a compromised or misconfigured node that sends commands it should never send.
Cryptography
This plugin handles encryption, signing and hashing. ROS 2 uses the built in AES-GCM-GMAC plugin, which provides authenticated encryption.
What it protects against: someone on the same network reading camera feeds, maps or telemetry, and someone altering messages in flight.
Why only three of five
The document states ROS 2 uses only these three of the five plugin interfaces. Logging and data tagging are omitted because they are not required for DDS-Security compliance. If you need security event logging, you will gather it at the host and network level instead.
Planning around the plugins
- Certificates have lifetimes. Decide who renews them and how robots in the field get new ones.
- Permissions files are code. Review them like code, and store them with version history.
- Encryption has a cost. Measure latency on the real hardware before you encrypt high rate topics.
- Test failure modes. A node with an expired certificate should fail in a way an operator can diagnose.
Reading the files without fear
Governance and permissions files look intimidating, but they are structured documents that say which domain a participant may join and which topics it may publish or subscribe to. Start with a draft that mirrors what your system does today, then remove access nobody needs. A review question that works well: if this node were taken over, what is the worst thing it could publish? Tighten the permissions until the answer is acceptable.
Quick check
Can I use access control without authentication?
Not usefully. Permissions attach to an identity, and authentication is what makes that identity trustworthy.
Does encryption replace access control?
No. Encryption hides traffic from outsiders. Access control stops an authenticated but over privileged node from doing things it should not.
Sources
Last reviewed: 19 October 2026.
