Why Connext DDS Secure Is the Smart Choice for Industrial IoT Security

“Security should be built in, not bolted on.” This principle is especially true as the Industrial Internet of Things (IIoT) expands. Yet, many systems still adopt security as an afterthought. Understanding why can help architects avoid costly retrofits.

Often, threat models and security requirements are not fully integrated into the architecture phase. Existing solutions are then retrofitted with encryption or access controls, which can be expensive, fragile, and insufficient. Management may prioritize performance over security, assuming that isolation or an air‑gap will protect the system. By the time security is added, re‑architecting the entire solution can be prohibitively expensive.

Designing secure systems requires balancing protection against attack with minimal impact on performance, interoperability, and scalability—challenges that intensify as systems grow more complex. The DDS Security Specification and RTI’s Connext® DDS Secure address these challenges with a peer‑to‑peer, data‑centric framework that natively supports fine‑grained security controls, multicast, and zero‑copy data distribution.

If you are already using DDS or evaluating it, Connext DDS Secure offers a clear path to align security with business risk and performance goals. Below, we explore how it meets the needs of critical IIoT environments and illustrate its impact with a medical device interoperability case study.

Is DDS Security the Right Fit for Your Use Case?

RTI engineers evaluate potential customers against five key questions. If at least three answer “yes,” DDS is likely the optimal connectivity framework:

1. Is a brief outage unacceptable for your system?
2. Have you used the terms “millisecond” or “microsecond” in the past two weeks?
3. Do you have more than ten software engineers?
4. Do you need to publish data to multiple destinations (e.g., cloud, database, edge devices)?
5. Are you designing a new IIoT architecture?

Question 1 – Availability
When uptime is critical, DDS’s peer‑to‑peer topology eliminates single points of failure. QoS policies such as Ownership, Durability, Liveliness, and Deadline enable graceful degradation. DDS Security adds domain segregation, participant authentication, and message authentication, which mitigate DoS attacks while preserving availability.

Question 2 – Real‑time Performance
High‑frequency data streams demand minimal latency. DDS Security lets you configure confidentiality, integrity, and authenticity per topic or participant without changing application code. This fine‑tuned approach ensures that only the necessary security mechanisms are applied, keeping round‑trip times low.

Question 3 – Development Efficiency
Large teams benefit from DDS’s data‑centric design, which decouples data models from processing APIs. Security policies are defined in declarative files (domain governance, participant permissions) that can be audited and updated independently of code, reducing integration risk and accelerating delivery.

Question 4 – Multicast Optimization
Unlike TLS/DTLS, which cannot leverage multicast, DDS Security natively supports multicast for efficient data distribution. This is essential for broadcast‑style applications such as telemetry, diagnostics, and control messaging.

Question 5 – New‑Architecture Flexibility
When you’re building a fresh system, you can embed security from the outset. DDS is an open, vendor‑neutral standard, and DDS Security offers pluggable authentication, authorization, cryptography, and logging APIs, making it ideal for scalable, cross‑vendor IIoT deployments.

RTI Connext DDS Secure has been validated by numerous commercial and government customers. Feedback has continuously informed product enhancements and contributions to the DDS community.

Example: DDS Security for Secure Medical Device Interoperability

The ASTM F2761‑09 Integrated Clinical Environment (ICE) standard promotes interoperability among heterogeneous medical devices. OpenICE, an open‑source ICE implementation, uses DDS as its communication backbone. Without explicit security, an insider could act as a man‑in‑the‑middle, falsifying patient data and compromising care.

OpenICE enables connectivity across diverse medical devices. By applying DDS Security, administrators can enforce per‑device access controls, ensuring that only authorized participants publish or subscribe to sensitive topics. This mitigates insider threats and preserves patient safety.

Transport‑Level Security Alone Isn’t Enough

Even when all traffic is encrypted with TLS/DTLS, a compromised device can still publish malicious data if fine‑grained controls are missing. DDS Security’s role‑based access policies prevent such attacks without affecting existing transport security.

For resource‑constrained devices or bandwidth‑sensitive applications, you can tailor security levels—enabling only integrity or authenticity where appropriate—minimizing overhead while maintaining compliance.

RTI also offers custom TLS/DTLS transports that can be integrated with DDS for use cases that require them. Our Architecture Studies help you choose the right blend of transport and middleware security based on risk and performance.

Conclusion and References

For critical infrastructure, we recommend adopting RTI Connext DDS Secure and the OMG DDS Security standard. Key references:

• [1] OMG DDS Security Specification – https://www.omg.org/spec/DDS-Security/
• [2] Industrial Internet Reference Architecture (IIRA) – https://www.iiar.org/
• [3] Industrial Internet Connectivity Framework (IICF) – https://www.iicf.org/
• [4] Industrial Internet Security Framework (IISF) – https://www.iisf.org/
• [5] ICE Security – https://www.ice-security.org/