Is ROS 2 secure by default?
No. A stock ROS 2 system has no authentication, access control, or encryption on its communications until you enable the security features. By default, any participant that can reach the DDS network can discover nodes, subscribe to topics, and publish to them, including topics that drive actuation. This is fine on an isolated bench and dangerous on anything connected.
The good news is that ROS 2 was designed with a security path. Turning it on is a deliberate step, and many deployments simply have not taken it, which is why exposed ROS 2 and DDS endpoints keep showing up in the wild. Enabling SROS2 is the baseline, and it is where hardening starts.
What does SROS2 protect, and what does it miss?
SROS2, built on the DDS-Security standard, adds participant authentication, access-control permissions on topics, and encrypted communication. It does not authorize individual physical actions or produce verifiable evidence of them. In other words, it decides who may join and which topics they may use, at the transport and pub/sub layer.
| Concern | SROS2 / DDS-Security | Attestation layer |
|---|---|---|
| Participant authentication | Yes | Uses it |
| Topic encryption | Yes | Uses it |
| Access control on topics | Yes (permissions) | Complements |
| Authorize an individual physical action | No | Yes (pre-actuation gate) |
| Per-robot hardware-rooted identity | Certificate-based, not hardware-rooted by default | Yes |
| Tamper-evident action receipt | No | Yes (RFC 6962) |
The table is not a knock on SROS2. It is a map of where the middleware’s job ends. Authenticating a participant and encrypting a topic does not answer whether a specific arm.move command should execute right now, nor does it leave a receipt an auditor can check.
What DDS vulnerabilities have been disclosed?
Security researchers have documented a range of issues in ROS 2’s DDS layer, from large numbers of internet-exposed DDS services to design weaknesses in how permissions and discovery work. Alias Robotics and others have reported publicly reachable DDS endpoints across many countries, along with problems that let an attacker on the network map the system, and in some cases interfere with topics.
These findings do not mean DDS is unusable; they mean transport exposure is a real risk that access control alone does not fully contain. The practical takeaway is to segment the DDS network, enable DDS-Security, and add a layer that authorizes actions regardless of who reaches the bus. See the wider robot threat landscape.
Why do permission and namespace gaps persist?
Because access control in a distributed pub/sub system is hard to get exactly right, and revocation and isolation are the tricky parts. Researchers have highlighted weaknesses such as permission revocation that does not take effect cleanly and namespace isolation that can be worked around, which means a compromised or misconfigured participant may retain more reach than intended.
Design gaps like these are why relying solely on topic-level permissions is fragile. If authorization is enforced only at the channel, a participant that slips through the permission model can influence actuation. Moving the final authorization decision to the action boundary removes that single point of failure.
How does attestation layer above ROS 2 security?
Attestation sits above the middleware: it verifies a per-robot hardware-rooted identity, authorizes each high-consequence command before actuation, and seals the decision as a verifiable receipt. It uses SROS2 and DDS-Security underneath rather than replacing them, the way application security sits above TLS.
So a hardened ROS 2 robot gets participant authentication and encryption from SROS2, and per-action authorization plus tamper-evident provenance from RankShield. Even if an attacker defeats a topic permission or reaches the DDS bus, an unauthorized actuation command still fails the gate. This is defense in depth, and it is the honest way to describe the relationship: complementary, not competing.
How do you pen-test a ROS 2 robot?
Scope the DDS network exposure, the SROS2 configuration, the firmware and update path, wireless interfaces, the teleoperation link, and any cloud APIs, then verify each finding is fixed. A ROS 2 assessment typically checks whether security is even enabled, whether DDS endpoints are reachable, whether permissions are correctly scoped, and whether actuation topics can be influenced by an unauthorized participant.
The result should feed your ISO 10218 / IEC 62443 risk assessment. And because attestation lets you prove a fix holds rather than re-scanning, it pairs naturally with a retest cycle. See robot penetration testing for the full method.
Frequently asked questions
Is ROS 2 secure out of the box?
No. ROS 2 has no authentication, access control, or encryption until you enable SROS2 and DDS-Security. A default system lets any reachable participant discover and publish to topics, including actuation topics.
Does SROS2 stop an unauthorized robot action?
Not directly. SROS2 authenticates participants and controls topic access at the pub/sub layer. It does not authorize a specific physical action or emit a verifiable receipt. An attestation layer adds that above it.
Should I replace SROS2 with attestation?
No. Keep SROS2 and DDS-Security for participant authentication and encryption, and add attestation above them for per-action authorization and tamper-evident provenance. They are complementary.
What DDS issues have been reported?
Researchers have documented internet-exposed DDS services and design weaknesses in permissions, revocation, namespace isolation, and discovery. Segmentation, DDS-Security, and an action-authorization layer together address them.
How does attestation help a ROS 2 fleet?
It gives each robot a hardware-rooted identity, authorizes high-consequence commands at the action boundary, and produces verifiable receipts, so even a participant that defeats a topic permission cannot cause an unauthorized actuation.