Designing MedTech Systems for Security from the Ground Up

MedTech Demands Built-In Cybersecurity

Connected medical devices, from robotic-assisted surgery systems to remote teleoperation setups, rely on continuous, real-time data streaming. As medical architectures expand across operating rooms, hospital networks, and cloud environments, protecting patient data and device availability is vital.

In modern connected healthcare, cybersecurity is no longer an isolated IT consideration. Designing security directly into distributed medical systems can help manufacturers:

• Safeguard patient safety by preventing unauthorized command injection or disruption of system state, processing, and controls.
• Protect sensitive health data (PHI) against eavesdropping and data exfiltration.
• Streamline regulatory compliance with FDA cybersecurity mandates (such as Section 524B of the FD&C Act) and international standards including IEC 81001-5-1.

However, medical device manufacturers often struggle to balance security with the need for connectivity, device integration, and real-time performance. Traditional perimeter defenses like firewalls fail when an untrusted device connects inside the hospital network. However, bolting custom cryptographic wrappers onto applications as an afterthought often has the unwanted side-effect of adding latency and increasing engineering overhead.

To help development teams solve these challenges, we have added a new module to the RTI MedTech Reference Architecture: Module 4: Mitigating Security Threats with RTI Security Extensions.

This new module provides a practical reference architecture demonstrating how to apply the security capabilities of production-proven RTI Connext to protect real-time medical systems against cyber threats.

The MedTech Reference Architecture

The RTI MedTech Reference Architecture serves as a buildable reference framework that demonstrates best practices for connected medical systems using RTI Connext.

The architecture is organized into modular building blocks:

Using Module 1 - Surgical Robotics as its foundation, Module 4 illustrates how RTI Security Extensions protect data in motion. Rather than discussing security in the abstract, this module introduces active cyber threats directly into the simulated surgical environment to show how attacks succeed when unsecured, and how Connext stops them cold when security is enabled.

Inside the Threat Vectors: Exfiltration and Injection

Module 4 models two practical threat scenarios facing connected medical devices:

1. Data Exfiltration (ThreatExfiltrator)

• The Attack: A rogue, unauthenticated node connects to the network and attempts to passively discover and subscribe to sensitive data streams (t/PatientVitals and t/ArmTelemetry).
• The Impact: Patient health information (PHI) is stolen, violating HIPAA and patient confidentiality, while proprietary robotic telemetry and kinematic parameters are compromised.
• The Implementation: A Python application (ThreatExfiltrator.py) boots up an unauthorized participant in the operational domain and attempts to capture live topic streams.

2. Command Injection (ThreatInjector)

• The Attack: An unauthorized participant impersonates a legitimate surgical controller by publishing rogue trajectory targets and control overrides to t/MotorControl.
• The Impact: This represents the highest-severity medical device hazard: unintended robotic motion during a procedure, suppression of safety cutoffs, or disruption of clinical workflows.
• The Implementation: A Python application (ThreatInjector.py) publishes high-frequency spoofed position commands to knock the robotic arm off its trajectory.

How RTI Security Extensions Neutralize Threats

When Module 4 runs in an unsecured state, both attacks succeed: the Exfiltrator eavesdrops on telemetry, and the Injector forces the robotic arm into erratic movements.

When you enable security (using the -s launch option), the system activates the security features of RTI Connext and demonstrates how these same threats are blocked and reported.

Module 4 demonstrates four core security concepts:

1. Certificate-Based Authentication

Legitimate endpoints (Robotic Arm, Arm Controller, Patient Monitor) carry X.509 identity certificates signed by a recognized Identity Certificate Authority (CA). When the rogue ThreatExfiltrator or ThreatInjector attempts to join the domain using unauthorized credentials (RogueCa), Connext rejects the mutual handshake immediately. Discovery is aborted before any topic or data type information is shared.

2. Access Control Enforcement

Authentication confirms identity, while Access Control enforces least-privilege permissions. Centralized, signed XML governance and permissions files specify exactly what each device can publish or subscribe to. For example, the PatientSensor is permitted only to publish vitals - it is blocked from publishing motor control commands, preventing compromised endpoints from pivoting across the system.

3. Discovery Encryption Using Pre-Shared Keys (PSK)

Without discovery encryption, unauthorized observers on the network could map out device names, topic names, and communications topology using network sniffers. Connext secures discovery traffic using rotatable PSKs, ensuring network observers see only encrypted traffic.

4. Data Encryption Using Public-Key Infrastructure (PKI)

Application topic payloads (t/PatientVitals, t/MotorControl) are encrypted end-to-end using AES-GCM (128-bit or 256-bit). Even if network traffic is mirrored on a compromised switch, the data remains unreadable without valid session keys.

Seeing the Defense in Action

Module 4 is integrated into the MedTech Reference Architecture’s automated launch harness (launch.py), allowing developers to run both scenarios and inspect the console logs.

Scenario A: Rogue Exfiltrator Blocked

When running ThreatExfiltrator against the secure operational domain, Connext immediately rejects the unauthorized participant during discovery:

[ThreatExfiltrator] [INFO] Participant created — ROGUE CA
[dp/PatientMonitor] [SECURITY THREAT] X509_verify_cert returned 0 with error 18: self-signed certificate
subject name: /C=US/ST=CA/O=Company 
Name/CN=RogueCa/emailAddress=rogueca@company_name.com issuer name: /C=US/ST=CA/O=Company Name/CN=RogueCa/emailAddress=rogueca@company_name.com 
[dp/PatientMonitor] [SECURITY THREAT] Failed to verify identity. Used authority: /C=US/ST=CA/O=Company 
Name/emailAddress=trustedidentityca@company_name.com/CN=TrustedIdentityCa 
[dp/PatientMonitor] [SECURITY THREAT] failed to verify certificate 
[dp/PatientMonitor] [SECURITY THREAT] failed to get certificate 
[dp/PatientMonitor] [SECURITY THREAT] failed to process remote handshake request 
[ThreatExfiltrator] [BLOCKED] No subscription match — access denied by security

Scenario B: Forged Permissions Injector Denied

When executing ThreatInjector, the rogue node cannot establish a secure endpoint match with the robotic arm:

[ThreatInjector] [INFO] Participant created — FORGED PERMS 
[dp/Arm] [SECURITY THREAT] failed to verify permissions document signature 
[dp/Arm] [SECURITY THREAT] failed to validate remote permissions 
[dp/Arm] [SECURITY THREAT] unauthorized remote participant [...] denied by local participant [...][ThreatInjector] [BLOCKED] No publication match — access denied by security

Who Should Explore This Module?

• Software Engineers and System Architects: This module provides ready-to-run code, launch scripts, and XML configuration files demonstrating how to secure a distributed medical system using Connext DDS without writing custom cryptographic code. Security policies are decoupled from application logic in signed XML files, making updates and compliance maintenance straightforward.
• Product Managers and Engineering Leaders: The reference architecture provides a concrete blueprint showing how Connext helps medical device manufacturers meet strict regulatory expectations upfront, which helps reduce both development risk and audit findings, while speeding up time-to-market.

Ready to Explore the Module?

Module 4: Mitigating Security Threats is now available in the RTI MedTech Reference Architecture portfolio on GitHub.

You can clone the repository, run the threat simulations locally, and inspect how RTI Security Extensions protect safety-critical data in motion:

• Explore the Code: Clone the RTI MedTech Reference Architecture GitHub Repository and navigate to modules/04-security-threat/.
• Review the Case + Code: Visit the RTI MedTech Reference Architecture Case + Code page to access technical briefs, video walk-throughs, and documentation.
• Connect with RTI Professional Services: Contact the RTI Professional Services team to learn how our architects can help you design, secure, and accelerate your next medical device project.

For More Information

To learn more about the use of RTI Connext in healthcare applications, we suggest the following:

• Read our RTI MedTech Reference Architecture capability brief
• Read our How Dataflow is Transforming Connected Medical Devices whitepaper
• Read our RTI Connext: Securing Connected Medical Devices capability brief
• Visit our Connecting Healthcare Applications page to view some of our customer success stories and learn about connecting healthcare with RTI Connext.

About the author:

Will Coleman is a Senior Application Engineer on the Professional Services team at RTI. Will collaborates with and guides RTI’s customers on using Connext in ways that best satisfy their unique requirements. He primarily works with teams in the medical and automotive spaces.