Connected medical devices: securing the whole ecosystem

Acknowledgement

This article was prompted by Dina Sifri of MedDev Solutions and her LinkedIn post, ‘Who decided where your penetration test stops?’. Her discussion of the FDA surgical robotics draft raised the boundary question explored here in the wider context of connected medical devices. Dina Sifri on LinkedIn.

Security beyond the device

A connected medical device may depend on firmware, a mobile app, a cloud service and the network between them. Each component can have its own development team and security test report. The important question is whether the evidence also covers what happens when those components interact.

FDA’s September 2026 draft guidance for robotically-assisted surgical devices makes that question particularly clear. For connected-device manufacturers, it offers a useful reason to revisit where their cybersecurity assessment and penetration testing stop.

The practical interpretation is that security scope should follow the dependencies and attack paths that can affect the device’s safety and effectiveness.

What the surgical robotics draft says

Issued on 25 September 2026, the draft recommends considering connected components, accessories, back-end services and communication networks within the cybersecurity assessment, including penetration testing. It gives the example of simulating communication with a compromised hospital network.

The document concerns robotically-assisted surgical devices and is marked “Not for Implementation”. Its recommendations should therefore be read in that context. [1]

How this relates to other connected medical devices

FDA’s February 2026 final cybersecurity guidance already recommends threat modelling across medical-device system elements and assuming a hostile hospital network. Its global system view includes external connections, cloud services and update infrastructure. [2]

Taken together, these documents support an ecosystem perspective. The robotics draft supplies a concrete application of a broader approach; it does not create a universal new requirement to test every connected system.

Map the dependencies that matter

For an engineering team, a useful starting point is to ask which external components can influence clinical behaviour, data integrity, availability or recovery.

Depending on the product, that may include:

A connection diagram becomes more useful when it shows what crosses each interface, who can initiate the exchange and which component decides whether to trust it. Include service and maintenance connections as well as normal operation.

Assess a component’s relevance through its influence on the medical function. A service holding only device data may still matter if it supplies configuration or distributes updates. The absence of patient data alone does not establish that a service has no safety relevance.

• Firmware in a measurement or control subsystem.
• A phone or gateway that relays measurements or commands.
• A cloud API that associates devices with users.
• An identity service that authorises access.
• A service tool that changes configuration.
• Infrastructure that distributes software updates.

Test the interfaces between components

Consider a hypothetical connected injection device. It records an injection, transfers the event through a phone and displays the history through a cloud service.

Separate tests of the device, app and cloud can establish useful evidence. A system assessment should also ask whether an attacker could exploit their interaction.

Could an old event be replayed and accepted as a new injection? Could a compromised account associate a device with the wrong user? Could delayed data appear current? Could a service credential grant broader access than intended?

The clinical significance depends on the intended use. An inaccurate personal diary and an inaccurate record used to guide treatment need different assessments.

These questions belong in the threat model and should inform the test scenarios. They also help explain why successful component tests may leave important system behaviour unexamined.

Demonstrate resilience to compromised dependencies

Manufacturers often have limited control over hospital networks, home routers and personal phones. Testing should account for that limitation.

A suitable test environment can simulate intercepted traffic, malformed messages, unavailable services or a compromised intermediary. The objective is to establish the device’s behaviour under the relevant conditions.

For example, a test might check that an invalid command is rejected, that an interruption does not corrupt an assay result, or that synchronisation after an outage does not create duplicate records.

Define the expected response before testing. Continued operation, a warning, restricted functionality or a controlled stop may each be appropriate in a particular design. The choice needs to follow the clinical function and associated risks.

An ecosystem assessment does not automatically require direct penetration testing of every hospital asset. Simulation, interface testing and other evidence can address dependencies outside the manufacturer’s control. Any direct testing of third-party infrastructure needs an agreed, authorised scope.

Assign ownership across device and platform teams

The product team may own the device, the platform team the cloud, and a supplier the firmware. A practical governance arrangement gives one person responsibility for coordinating the overall security assessment while retaining specialist owners for each component.

That coordinator should be able to show how the architecture, threat model, requirements and test evidence fit together. Interface risks need named owners too.

Supplier reports can contribute to the evidence. Review what was tested, against which version and configuration, and how closely that environment represents the integrated product. Identify any gaps requiring additional testing.

A supplier’s exclusion from its test scope should trigger a decision about how the manufacturer will address the omitted risk.

Define the scope before commissioning a penetration test

Before agreeing the statement of work, use the architecture and threat model to resolve five questions:

Match the depth of testing to the architecture, exposed interfaces and potential consequences. Document the reasoning so that the scope remains understandable when teams, suppliers or reviewers change.

• What system and versions will be tested? Identify device hardware, firmware, apps, services, interfaces and relevant configurations.
• Which attacker positions will be represented? Examples include a nearby wireless attacker, a hostile network, a compromised phone or a misused account.
• Which scenarios span multiple components? Include relevant registration, data transfer, remote configuration, service and update paths.
• What is excluded and how will it be assessed? Record the rationale and the evidence that addresses each relevant exclusion.
• How will findings be closed? Assign responsibility for risk assessment, remediation and verification of the resulting controls.

Keep the assessment current

Connectivity creates dependencies that can change after release. A new identity provider, API, phone operating system or update mechanism may alter an assumption that previously supported the security assessment.

Use change review to decide whether the threat model, security requirements or test evidence need updating. Repeat the relevant testing when the change warrants it.

For connected medical devices, the useful boundary question is therefore: have we covered the components and interactions through which a security compromise could affect this product? The answer should be visible in the assessment and supported by evidence.

The engineering examples and suggested working practices above are practical interpretations for connected medical devices.