Key takeaways
- No — core DDS, as published by OMG, defines the data model, QoS and wire protocol for pub/sub messaging, but does not mandate authentication, access control or encryption as part of that baseline specification.
- CISA's advisory ICSA-21-315-02, "Multiple Data Distribution Service (DDS) Implementations," was originally published 11 November 2021 and updated (Update A) on 1 February 2022.
- Don't assume DDS Security is active just because the implementation supports it.
Core DDS — the real-time publish/subscribe middleware that OMG standardizes and that ROS 2 uses as its default middleware — carries no mandatory authentication, access control or encryption of its own; those are the job of a separate specification, DDS Security, that a deployment can simply not install. A 2021 coordinated disclosure (CISA advisory ICSA-21-315-02), the product of research by Trend Micro Research, TXOne Networks, Alias Robotics and ADLINK Technology, found 13 CVEs spanning six independent DDS implementations — from network-amplification flaws to a heap-based buffer overflow CISA rated capable of remote code execution — none of them a break of DDS Security's cryptography, because in most of the affected deployments that layer was never the thing being tested.
What is DDS, and where is it actually used?
DDS (Data Distribution Service) is a publish/subscribe middleware standard maintained by the Object Management Group (OMG), currently at specification version 1.4 (adopted March 2015), built for real-time data exchange between distributed participants without requiring them to know about each other in advance — publishers and subscribers connect through named Topics and a shared Quality of Service contract, with a companion specification, DDS-RTPS, defining the interoperable wire protocol different vendors' implementations use to talk to each other. That design — low-latency, broker-less, peer-discovery-based pub/sub — is why DDS shows up anywhere real-time data has to move between many participants with predictable timing: ROS 2's own documentation states that ROS 2 "uses DDS as its middleware" and supports multiple interchangeable DDS vendors, with eProsima's Fast DDS as the default RMW (ROS Middleware) implementation and RTI Connext DDS, Eclipse Cyclone DDS and GurumNetworks GurumDDS also supported — meaning DDS sits underneath a large share of the world's research and commercial robotics stacks. Beyond robotics, DDS implementations are deployed in autonomous vehicles, medical devices, air-traffic control, power generation and smart-grid management, simulation and training systems, and military and aerospace platforms — the same breadth of safety- and mission-critical use cases our NIST SP 800-82 Guide to OT Security covers for operational technology generally, since a growing share of that OT estate now runs DDS internally rather than a traditional fieldbus.
Does core DDS include security, and what does the separate DDS Security spec add?
No — core DDS, as published by OMG, defines the data model, QoS and wire protocol for pub/sub messaging, but does not mandate authentication, access control or encryption as part of that baseline specification. Security is the subject of a standalone companion specification, DDS Security, first adopted as version 1.0 in August 2016, revised to version 1.1 in July 2018, and most recently updated to version 1.2 in February 2026. OMG describes DDS Security as establishing "the Security Model and Service Plugin Interface (SPI) architecture for compliant DDS implementations" — a design built around five distinct Service Plugin Interfaces that an implementation can invoke:
| Plugin (SPI) | What it does |
|---|---|
| Authentication | Verifies the identity of a participant and/or user invoking DDS operations; performs mutual authentication between participants and establishes a shared secret |
| Access Control | Enforces policy decisions on what an authenticated participant may do — which domains it can join, which Topics it can publish or subscribe to — typically configured through XML governance and permissions documents |
| Cryptographic | Implements the actual encryption, decryption, hashing and digital-signature operations, including deriving session keys from the Authentication plugin's shared secret |
| Logging | Supports auditing of security-relevant DDS events |
| Data Tagging | Adds classification tags to individual data samples |
DDS Security also ships builtin reference implementations of each plugin, so compliant vendors have an interoperable default rather than each writing incompatible authentication and crypto code — but every one of these plugins is opt-in. A DDS deployment that never loads the Security plugins is still a standards-conformant DDS system, running with none of the protections above, in the same way a GOOSE substation network can be fully IEC 61850-conformant while carrying no IEC 62351-6 message authentication at all.
What did the 2021 multi-vendor DDS vulnerability disclosure find?
CISA's advisory ICSA-21-315-02, "Multiple Data Distribution Service (DDS) Implementations," was originally published 11 November 2021 and updated (Update A) on 1 February 2022. It documents 13 CVEs across six independent, widely-deployed DDS implementations — the result of coordinated research by Trend Micro Research, TXOne Networks, Alias Robotics and ADLINK Technology, reported to CISA by Federico Maggi (Trend Micro Research), Ta-Lun Yen and Chizuru Toyama (TXOne Networks, Trend Micro), with Patrick Kuo, Mars Cheng, Víctor Mayoral-Vilches (Alias Robotics) and Erik Boasson (ADLINK Technology) also credited as contributors.
| Vendor / product | Affected versions | CVE(s) | CVSS v3 | What it allowed |
|---|---|---|---|---|
| Eclipse CycloneDDS | Before 0.8.0 | CVE-2021-38441 (CWE-123), CVE-2021-38443 (CWE-228) | 6.6 | A "write-what-where" condition and improper handling of invalid structures in the XML parser |
| eProsima Fast DDS | Before 2.4.0 | CVE-2021-38425 (CWE-406) | 7.5 | Network amplification — a specially crafted packet floods a target device with unwanted traffic |
| GurumNetworks GurumDDS | All versions | CVE-2021-38423 (CWE-131), CVE-2021-38439 (CWE-122) | 6.6; 8.6 | Incorrect buffer-size calculation, and a heap-based buffer overflow CISA states "may cause a denial-of-service condition or remotely execute arbitrary code" |
| OCI OpenDDS | Before 3.18.1 | CVE-2021-38445 (CWE-130), CVE-2021-38447 (CWE-405), CVE-2021-38429 (CWE-406) | 7.0; 8.6; 7.5 | Improper length-parameter handling, asymmetric resource consumption, and network amplification |
| RTI Connext DDS Professional / Secure / Micro | 4.2x–6.1.0 (Professional/Secure); 3.0.0+ (Micro) | CVE-2021-38427, CVE-2021-38433 (both CWE-121), CVE-2021-38435 (CWE-131), CVE-2021-38487 (CWE-406) | 6.6; 6.6; 6.6; 7.5 | Two stack-based buffer overflows, incorrect buffer-size calculation, and network amplification |
| TwinOaks Computing CoreDX DDS | Before 5.9.1 | CVE-2021-43547 (CWE-406) | 7.5 | Network amplification via a specially crafted discovery packet |
The pattern that recurs most across vendors is network amplification (CWE-406): per CISA, "an attacker sends a specially crafted packet to flood target devices with unwanted traffic" — abusing DDS's own discovery protocol so a single spoofed packet can direct a flood of traffic at a victim, a class of bug independent of whether DDS Security's cryptography is in use. The buffer-overflow findings are implementation-level memory-safety bugs in parsing untrusted input (packets or XML configuration), not a break of the Authentication or Cryptographic plugins' design. CISA's advisory notes the affected software is deployed worldwide across vendors headquartered in multiple countries, and recommends the same defense-in-depth baseline it applies to any ICS finding: minimize network exposure, keep control-system devices off the public internet, isolate them behind firewalls from the business network, and use a VPN for any necessary remote access.
What should a device maker using DDS check first?
Inventory the exact DDS implementation and versionyour product ships — including any DDS vendor bundled inside a ROS 2 distribution — and confirm it is patched past the vulnerable version ranges CISA listed in ICSA-21-315-02 (CycloneDDS 0.8.0+, Fast DDS 2.4.0+, OpenDDS 3.18.1+, CoreDX DDS 5.9.1+, and the RTI and GurumDDS fixed releases referenced in that advisory). Don't assume DDS Security is active just because the implementation supports itThe plugin architecture exists in the spec but has to be explicitly configured — governance and permissions documents written, participants provisioned with identity material — before authentication, access control or encryption are actually enforced on the wire; an implementation that bundles DDS Security can still run completely open. Treat an unsecured DDS domain as an unauthenticated broadcast mediumAnyone able to reach the network segment can discover participants via DDS's built-in discovery protocol and, depending on what Access Control policy (if any) is configured, publish or subscribe to any topic — the same trust assumption an unsecured IEC 61850 GOOSE network makes. Segment DDS traffic away from general IT networks and the internet, whether it's a robot's internal pub/sub bus, a medical device's control plane, or a plant's control-system backbone — consistent with CISA's own ICSA-21-315-02 mitigation guidance, and with the research teams behind the 2021 disclosure separately reporting DDS endpoints they found reachable from the public internet during their work. Re-check after every firmware, middleware or ROS 2 distribution upgradethat the DDS implementation version didn't regress to a vulnerable release and that DDS Security configuration (if in use) survived the change.
A passive capture on a device's network segment is a practical way to see which DDS implementation and version is actually on the wire, whether DDS Security authentication is active, and what topics are being published or subscribed to, without needing source access to the product: SoftWSP's OT Snapshot identifies the protocols and connections a device actually uses from that capture and flags patterns such as unsecured DDS discovery traffic or a DDS implementation version matching a known CISA advisory, with an engineer reviewing every finding and the AI-assisted report citing the specific traffic each finding is based on — see OT Snapshot.
This guide draws on OMG's own published version history and specification pages for core DDS and DDS Security, the OMG DDS Security v1.1 specification document, CISA ICS advisory ICSA-21-315-02 fetched directly, Trend Micro Research's published summary of its 2021 DDS security research, and ROS 2's own documentation on DDS as its default middleware. The full text of the DDS Security specification PDF could not be reliably parsed in this research pass (OMG's PDFs returned as raw binary/compressed data rather than extractable text); plugin-architecture detail in this guide is drawn from OMG's specification landing pages and the OMG DDS Foundation's own wiki summary of the same spec rather than a line-by-line read of the PDF, and should be confirmed against the primary document before an implementation decision. A separate RTI-specific security notice referencing CERT/CC identifier VU#770071 and OMG issue DDSIRTP26-6 is referenced on RTI's own community site, but could not be independently verified — kb.cert.org returned no accessible record for that VU number at the time of research — so it is not cited as a source here and should not be treated as equivalent to the 13-CVE ICSA-21-315-02 disclosure this guide documents. This guide is general information, not a substitute for a current CISA ICS advisory search for your exact DDS implementation and version.
Sources
- OMG: DDS (Data Distribution Service) specification — version history and catalogue
- OMG: DDS Security specification — version history (1.0 Aug 2016, 1.1 Jul 2018, 1.2 Feb 2026)
- OMG: DDS Security Version 1.1 (PDF)
- CISA ICS Advisory ICSA-21-315-02: Multiple Data Distribution Service (DDS) Implementations (Update A, published 11 Nov 2021, updated 1 Feb 2022)
- Trend Micro Research: "A Security Analysis of the Data Distribution Service (DDS) Protocol" (white paper)
- Trend Micro Research: "Critically Underrated: Studying the Data Distribution Service (DDS) Protocol"
- ROS 2 Documentation: RMW Implementations (DDS vendor support, default RMW)
- ROS 2 Design: "ROS on DDS"
- OMG DDS Foundation Wiki: DDS Security guidebook entry (plugin architecture summary)
Frequently asked questions
Does core DDS include authentication or encryption by default?
No. The core Data Distribution Service specification — maintained by the Object Management Group (OMG), currently at version 1.4 (adopted March 2015) — defines a publish/subscribe data model, Quality of Service policies and a wire protocol (DDS-RTPS) for real-time data exchange between participants on a network, but it does not mandate authentication, access control or encryption as part of that baseline. Security is instead the subject of a separate, standalone specification, DDS Security, first adopted by OMG in August 2016 (version 1.0), revised in July 2018 (version 1.1), and most recently in February 2026 (version 1.2). That split mirrors how IEC 62351 layers security onto the base IEC 61850 substation protocol, or how MQTT's own spec only recommends, rather than requires, TLS and authentication: a real-time middleware designed first for low-latency data delivery, with cryptographic protection added afterward as an optional, separately-versioned layer that an implementation or deployment can skip entirely and still be a conformant DDS system.
What does the DDS Security specification actually add on top of core DDS?
A Security Model built on five Service Plugin Interfaces (SPIs) that compliant DDS implementations can invoke: an Authentication plugin that verifies the identity of a participant and performs mutual authentication to establish a shared secret; an Access Control plugin that enforces policy decisions on what an authenticated participant may do — which domains it can join, which Topics it can publish or subscribe to — typically configured through XML governance and permissions documents; a Cryptographic plugin that implements the actual encryption, decryption, hashing and digital-signature operations, including deriving session keys from the shared secret the Authentication plugin established; a Logging plugin that supports auditing of security-relevant DDS events; and a Data Tagging plugin that lets implementations attach classification tags to individual data samples. OMG's own specification page states DDS Security defines "the Security Model and Service Plugin Interface (SPI) architecture for compliant DDS implementations," and the spec also ships builtin reference implementations of each plugin so vendors have an interoperable baseline rather than needing to write authentication and crypto code from scratch. Critically, every one of this is opt-in: a DDS deployment that never loads the Security plugins is still a standards-conformant DDS system, running with none of the above.
What did the 2021 multi-vendor DDS vulnerability disclosure actually find?
CISA's advisory ICSA-21-315-02, "Multiple Data Distribution Service (DDS) Implementations" (originally published 11 November 2021, updated 1 February 2022), documents 13 CVEs across six independent DDS implementations, the product of research by Trend Micro Research, TXOne Networks, Alias Robotics and ADLINK Technology, reported to CISA by Federico Maggi (Trend Micro Research), Ta-Lun Yen and Chizuru Toyama (TXOne Networks, Trend Micro), with Patrick Kuo, Mars Cheng, Víctor Mayoral-Vilches and Erik Boasson also credited as contributors. The affected implementations were Eclipse CycloneDDS (versions before 0.8.0), eProsima Fast DDS (before 2.4.0), GurumNetworks GurumDDS (all versions), Object Computing Inc.'s OpenDDS (before 3.18.1), Real-Time Innovations (RTI) Connext DDS Professional and Connext DDS Secure (4.2x through 6.1.0) and Connext DDS Micro (3.0.0 and later), and TwinOaks Computing CoreDX DDS (before 5.9.1). The bug classes recur across vendors rather than clustering in one: several implementations shared a network-amplification flaw (CWE-406) where, per CISA, "an attacker sends a specially crafted packet to flood target devices with unwanted traffic" — exploiting DDS's discovery mechanism to turn one spoofed packet into a flood aimed at a victim; others had stack- or heap-based buffer overflows (CWE-121, CWE-122) in packet or XML parsing, the most severe of which, a GurumDDS heap-based buffer overflow (CVE-2021-38439, CVSS v3 8.6), CISA states "may cause a denial-of-service condition or remotely execute arbitrary code." CISA's advisory frames DDS's reach plainly, noting the affected software is used in sectors worldwide with vendor headquarters across multiple countries — consistent with DDS's role as the default middleware for ROS 2 robots, plus deployments in medical devices, autonomous vehicles, aerospace and industrial control.
What should a device maker or integrator using DDS check first?
Inventory which DDS implementation and version your product or deployment actually ships — ROS 2 alone supports multiple interchangeable DDS vendors (eProsima Fast DDS is ROS 2's default RMW implementation, with RTI Connext DDS, Eclipse Cyclone DDS and GurumNetworks GurumDDS also supported) — and confirm it is patched past the versions CISA listed as vulnerable in ICSA-21-315-02 (CycloneDDS 0.8.0+, Fast DDS 2.4.0+, OpenDDS 3.18.1+, CoreDX DDS 5.9.1+, and the RTI and GurumDDS fixes referenced in that advisory). Do not assume DDS Security is active just because the implementation supports it: like IEC 62351 authentication on a GOOSE network, the plugins exist in the spec but have to be explicitly configured — governance and permissions files set up, participants provisioned with identity certificates — before any authentication, access control or encryption is actually enforced on the wire. If DDS Security is not in use, treat the DDS domain as an unauthenticated broadcast medium: anyone who can reach the network segment can discover participants and, depending on configuration, publish or subscribe to any topic, which is the same trust assumption GOOSE and Sampled Values make on an unsecured substation LAN. Segment DDS traffic — whether it is a robot's internal pub/sub bus, a hospital's medical-device network, or a plant's control-system backbone — away from general IT networks and the internet, consistent with CISA's own mitigation guidance in ICSA-21-315-02 to minimize exposure and isolate control-system devices behind firewalls; the research teams behind the 2021 disclosure separately reported finding DDS endpoints reachable from the public internet during their work, underscoring that this is not a theoretical exposure.
In this cluster
