Designing Network Resilience into Connected Medical Devices

Who should read this

Product, regulatory, and commercial leaders inside medical device OEMs who are determining the architecture of their current and next-generation connected devices.

Introduction

Connectivity is often treated as a deployment-stage concern in connected medical devices. The cellular module is selected, a SIM is sourced from an operator or MVNO, and the product enters the market. From that point on, the data path is often opaque to the manufacturer, until a failure forces it back into view.

That model is increasingly under pressure:

Procurement functions are applying greater scrutiny to resilience, cybersecurity, clinical risk and technical assurance.
Regulators expect documented risk controls for foreseeable failure modes.

OEMs that can evidence resilient connectivity in the specification, rather than account for it after the fact, are therefore better positioned for the next generation of connected health and medical care procurement projects.

The proposition is straightforward: resilient connectivity should be designed into medical devices, and CSL rSIM® offers a secure and lower-friction path to doing so.

The regulatory and competitive case for action

Many connected medical devices deployed today rely on a single network path.

While their deployment context varies (patient homes, residential and care settings, ambulatory and community care, and clinic or hospital environments where the device may share infrastructure with non-clinical traffic), the architectural risk is often the same.

If the path is patient home broadband or a shared site network, the OEM has built a clinical service on infrastructure it cannot specify, monitor, or maintain.
If it is a single radio or single-core roaming cellular network, a local or core network outage can interrupt the data path that the clinical service depends on.

Under ISO 14971, loss of connectivity should be evaluated where it could form part of a reasonably foreseeable sequence of events leading to a hazardous situation, such as delayed intervention, missing data, incorrect clinical decisions, or other patient harm. The clinical severity will vary by device type and intended use, but for many remote-monitoring and alerting devices, broadband, single-network or core-network failure is not an unforeseeable edge case. It is a foreseeable operating condition that requires documented evaluation and, where appropriate, risk controls. Additional guidance for developing, implementing, and maintaining a medical-device risk management system is provided in ISO/TR 24971:2020.

Post-market surveillance (PMS) is now a continuous obligation in both the EU and Great Britain for manufacturers. Under MDR Article 83, PMS must be planned, maintained and updated throughout the device lifetime. In Great Britain*, the Medical Devices (Post-market Surveillance Requirements) (Amendment) Regulations 2024 took effect on 16 June 2025, inserting a new Part 4A into the UK MDR 2002 and creating strengthened PMS, vigilance and reporting obligations under MHRA oversight.

Where PMS, service-monitoring, clinical-performance monitoring or incident detection relies on connected telemetry, repeated connectivity loss can create systemic gaps in the manufacturer’s post-market data. That is not a gap an OEM should have to account for retrospectively during notified-body or MHRA review, tender scrutiny, or post-incident investigations. For connected medical devices, the PMS plan should define how connectivity-related events, data gaps, service incidents and user complaints are captured, trended and fed back into the risk management processes.

Manufacturers that act first can convert connectivity resilience from a latent risk into a documented product differentiator. Those that delay will increasingly be required to account for that decision to procurement teams, regulators, and, in the worst case, post-incident investigators.

*Note: This briefing refers to Great Britain requirements, Northern Ireland market access should be assessed separately.

Hardware-level dual-SIM: the trade-offs to weigh-up

Hardware-level dual-SIM has been an established approach to network resilience in connected devices, and it remains a valid choice for many designs. A second cellular module, or a dual-SIM design on the board, can deliver multi-network and in some cases dual-core connectivity. For OEMs evaluating a new product platform, the question worth weighing is whether the development cost and timescale are justified relative to SIM-layer alternatives.

For many regulated medical devices, hardware-level connectivity changes are not a simple engineering refinement. A change of this kind typically involves:

Hardware and firmware development
Design-change assessment under the QMS
Technical documentation updates
Validation and verification activity
Notified-body review, depending on device class, certificate status, and notified-body arrangements

For legacy devices under MDR transitional provisions, manufacturers also need to assess whether the change could be significant in relation to design or intended purpose. For devices placed on the GB market, under applicable recognition or transitional arrangements, manufacturers should separately assess whether the changes affect certificate validity, technical documentation, UKCA/CE marking status or MHRA expectations.

Additionally, where the change affects the radio module, antenna design, RF path, enclosure, EMC performance or intended radio operation, the OEM may also need to revisit the Radio-Equipment, EMC and related conformity evidence, not only the MDR technical documentation.

IoMT: Regulatory Pathways & Evidence for NHS Adoption

How rSIM works

rSIM places the failover decision inside the SIM card itself. The device firmware, the cloud platform, and the mobile network are not involved in the switching decision. When the SIM detects that the active network has failed, it initiates re-registration on the alternative and redundant core path, which can avoid the need for modem-level failover logic or device firmware changes.

What it monitors, and why that matters: Conventional resilience approaches typically decide whether to switch on the basis of radio signal strength. The architectural weakness of that approach is the silent-failure case: a core-network or signalling-path outage where the device’s radio signal still appears healthy but data cannot actually pass. rSIM monitors actual data activity and throughput from the device, not just signal strength, so it detects connectivity failure even when the radio signal appears fine.

Two multi-network profiles each with diverse core-network pathways in one SIM: rSIM carries two core mobile network profiles in a single SIM (Primary and Fallback), which can be either two in-country mobile network operator profiles or two discrete pathway multi-network/roaming profiles.

No external dependency during an incident: Because the switching decision is taken on the SIM, rSIM does not wait for the network to tell it to switch. This matters most when the network itself is the problem: a core-network outage at the active operator is precisely when that operator is least able to issue a steering command.

GSMA IoT eSIM alignment: rSIM aligns with the broader GSMA SGP.32 direction for remote provisioning and lifecycle management of IoT eSIM profiles for future deployment flexibility.

The result is a failover mechanism that operates at the SIM signalling layer, independently of the device, the platform, and (critically) the network experiencing the outage.

An Introduction to rSIM

A SIM-layer approach to designing in resilience

rSIM moves the resilience problem one layer down the hardware and software stack, into the SIM itself. The SIM can be configured to autonomously fail over between separate mobile-network paths, with private routing options available across both paths. From the device’s perspective, the SIM looks and behaves like any other SIM.

From the OEM’s perspective, three things change:

One SIM module is required, not two. rSIM is available across standard removable SIM formats, including 2FF, 3FF and 4FF, as well as soldered MFF2 options, with eUICC capability where remote profile management is required. For OEMs working towards more embedded SIM architectures in future product generations, rSIM’s eUICC capability also aligns with the broader direction of travel towards remote provisioning and lifecycle-managed connectivity, including SGP.32 and in factory profile provisioning SGP.41.
No firmware change in most cases. Because the resilience logic resides within the SIM, the device firmware may not need awareness of the failover mechanism. In many deployments this can be achieved without changes to device firmware or cloud-platform logic and instead via configuration settings. The regulatory impact is therefore materially different from a hardware redesign, although OEMs should still assess the change through their QMS, supplier controls, cybersecurity review, validation plan, and risk-management process.
The cloud platform remains unchanged in normal operation. In a correctly configured deployment, telemetry continues to arrive through the same application-layer protocols and endpoints. Your device cloud, clinical integration and data pipeline should not normally need to be re-architected, although APN, routing, firewall, endpoint whitelisting and validation requirements still need to be checked as part of the change assessment.

rSIM, therefore, enables medical device OEMs to substantiate a resilience claim that conventional single-network or multi-network/single-roaming-core approaches cannot easily match, without the engineering and regulatory friction of a hardware redesign.

The Difference Between Single-Network, Roaming, Multi-Network, Multi-IMSI & Dual-Core SIMs

End-to-end security across both network paths

For connected medical devices, the connectivity decision is also a security decision. Cybersecurity is an explicit element of the safety and performance requirements under MDR (and equivalent UK provisions), and the security posture of the data path is part of the device’s risk-management file. In practice, OEMs should treat connectivity resilience and cybersecurity as linked lifecycle activities, supported by the MDR GSPRs (General Safety and Performance Requirements), MDCG 2019-16 and, where applicable, health-software security standards such as IEC 81001-5-1.

Connectivity resilience that downgrades security on the failover path is not really resilience; it is a compromise.

rSIM allows OEMs to specify private APN and routing arrangements** on both the primary and fallback paths. In a correctly configured deployment, telemetry travels via dedicated, non-public routes from the SIM through the operator core to the OEMs cloud or clinical platform, on either path.

For the OEM, this has three practical implications:

Symmetric security across paths. Failover does not move the device onto a less-trusted route. Both paths can be assured to the same standard, simplifying the cybersecurity review and the evidence package.
Smaller attack surface than public-internet alternatives. Properly configured private routing can keep clinical telemetry off the public internet between the device and the OEM cloud, reducing exposure to interception, denial-of-service, and hijacking.
Safer Remote Device Management. Private APNs and VPN enable devices to be securely remotely monitored and managed in terms of configuration settings and security-based firmware updates.
Coherent dual-path architecture for audit. A clearly specified end-to-end security architecture across both paths is easier to evidence to a notified body, MHRA reviewer, or NHS procurement assessor than an arrangement assembled ad hoc.

End-to-end security is not a separate workstream from connectivity resilience; the two are part of the same architectural decision and should be assessed together.

Note: Although medical devices regulated under MDR are currently exempt from the EU’s Cyber Resilience Act (Regulation (EU) 2024/2847), the European Commission’s December 2025 proposal to revise the MDR would, if adopted, close part of the cybersecurity reporting gap by introducing MDR-specific reporting obligations for connected devices. In particular, the proposal would require manufacturers to report actively exploited vulnerabilities and severe incidents affecting device security to CSIRTs and ENISA through Eudamed. The regulatory direction of travel is towards a higher, not lower, cybersecurity bar for connected medical devices.

** Private routing should be treated as one technical control within a broader cybersecurity and data protection architecture, alongside encryption, authentication, access control, logging, monitoring, vulnerability management, incident response and supplier assurance.

rSIM is already used in critical IoT environments such as telecare and alarm signalling, where loss of connectivity has direct safety, service-continuity, or life-critical consequences. Medical device OEMs evaluating rSIM are therefore applying a proven SIM-layer resilience architecture which they can assess and validate within their own medical device regulatory framework.

The commercial case for rSIM

The case for designing in resilient connectivity has three commercial dimensions, and they compound. These effects accumulate quietly across a device’s lifetime and are typically under-represented in pre-launch business cases:

Operational continuity. Connectivity failures in the field produce a chain of predictable effects:
- support time or service visits to investigate “the device isn’t working” complaints that turn out to be local or core network issues
- warranty claims attributable to outages outside the manufacturer’s control
- reputational impact when connectivity problems are attributed to the device itself
- erosion of recurring service revenue as patients or care providers lose confidence in a device that keeps dropping out

Risk-weighted exposure. The cost of a connectivity-related vigilance event (a field safety corrective action, an MHRA or notified-body interaction, or the reputational damage that follows a publicised incident in a clinical context) is not predictable in any individual case. It is, however, foreseeable in aggregate, and even a low-probability event of this kind can dominate the financial picture across a fleet.
Lifetime value protection. For a connected medical device generating recurring service revenue over a multi-year deployment, the incremental cost of designing in resilient connectivity is typically small relative to the lifetime value at stake. Connectivity-driven churn alone often dominates the equation before any vigilance consideration is added.

Each of these dimensions is sensitive to assumptions that vary by OEM and by device: service visits, warranty rate, service ARPU, incident probability, severity distribution and architecture residual-risk factor. The right way to use them is as inputs to a structured business case populated with the OEM’s own operational and vigilance data, not as industry benchmarks.

Design-in is not merely an additional connectivity cost; it is a risk-control decision with measurable operational, commercial and compliance value over the life of the device.

Market and procurement direction

Procurement teams in the NHS and across European health systems are increasingly scrutinising connected medical devices through the lens of cybersecurity, clinical risk, technical assurance, and operational resilience. In higher-risk connected care pathways, that scrutiny is increasingly becoming a conversation about managed connectivity, private routing, resilience evidence, and credible failover arrangements.

For quality and regulatory teams, this means rSIM should not be treated as an informal connectivity swap. It should be assessed deliberately: supplier qualification, cybersecurity review, APN and routing validation, risk-management updates, service diagnostics and PMS implications should all be documented. That documentation is part of the value: it turns connectivity resilience into evidence.

For healthcare organisations, the same issue also intersects with IEC 80001-1-style risk assessment for health IT networks, where safety, effectiveness and security must be considered before, during and after connecting medical devices into health IT infrastructure.

Deferring resilient connectivity to a future product cycle is becoming a more difficult position to defend.

How IoMT and AI Are Transforming Care Delivery

Recommended actions

OEM leaders responsible for connected medical device roadmaps should consider three actions:

Review your connectivity failure modes through your ISO 14971 risk-management process. Is broadband failure, single-network loss, silent disconnect, roaming failure or core-network outage documented where it could affect clinical performance, data integrity or service continuity?
Assess rSIM as the standard connectivity option for your next product revision. The design question is not just “which SIM do we buy?” It is whether your next device platform can evidence resilient, managed connectivity without a hardware redesign.
Pilot before platform-wide rollout. Validate failover behaviour, diagnostic visibility, support impact and incident reduction against your own device estate before scaling.

For regulatory and quality teams, the assessment should not stop at connectivity performance. The evidence package should show how the selected connectivity architecture supports the device’s risk-management file, PMS plan, cybersecurity risk assessment, supplier controls, validation strategy, service diagnostics and technical documentation. Where devices are deployed into healthcare IT environments, the OEM should also be prepared to support customer-side assurance of safety, effectiveness and security in line with connected health IT risk-management expectations.

CSL works with medical device OEMs on structured assessments of resilient connectivity at the design stage, including modem and form-factor compatibility, APN and routing options, risk-file wording, validation considerations, and support diagnostics. To explore this for your next or existing product platforms, please contact us to discuss your requirements.

Connectivity ceases to be an afterthought the moment connected devices become part of a clinical service.

The medical device OEMs that build that reality into their devices, rather than around them, will be better positioned for the next generation of connected medical healthcare.

CSL Healthcare & Telecare