Cellular Connectivity Device Security

Part of our Medical device vulnerability, threat, and attack-technique catalogue. For the full overview, start with The Top 50 Cybersecurity Issues with Medical Devices.

Reviewed September 17, 2026

A remote patient monitor, insulin pump, or cardiac device that reports over a cellular network is only as secure as the weakest link between its modem and the manufacturer's cloud, and that link often runs through infrastructure the manufacturer does not control. Cellular networks were not designed with medical-grade integrity guarantees in mind, and legacy 2G and 3G protocols carry documented interception and impersonation weaknesses that persist as fallback options on many modules deployed today. When a device delivers therapy, sends alarms, or receives remote software updates over cellular, a downgrade attack, a rogue base station, or an insecure provisioning process is not a hypothetical, it is a direct path to patient safety and regulatory risk. Getting the architecture right up front is far cheaper than responding to an FDA deficiency letter or a field incident later.

Why This Matters

Cellular connectivity is the default choice for devices that cannot rely on a patient's home Wi-Fi, including remote cardiac monitors, connected insulin delivery systems, and fleet-managed diagnostic equipment serviced in the field. Unlike Wi-Fi, the manufacturer usually has no visibility into or control over the intermediate network, from the local cell tower to the carrier's core, which means the device's own security controls have to carry more of the burden.

This matters for three reasons. First, clinical impact: a device that loses connectivity to a spoofed or degraded cellular signal may miss alarms or delay therapy adjustments, with direct consequences for patient safety. Second, data exposure: cellular data can be intercepted or manipulated when a device is tricked into using weaker legacy protocols, exposing patient telemetry or device commands. Third, regulatory scrutiny: the FDA's current premarket cybersecurity guidance requires manufacturers to document connectivity paths, including cellular, as part of the security architecture and risk assessment. Manufacturers who treat the cellular module as a plug-and-play black box, without documenting its trust boundary and failure modes, typically face additional information requests or discover the gap only after a field issue.

Why Does 2G/3G Legacy Fallback Create Downgrade Risk?

Legacy fallback creates downgrade risk because many cellular modules will silently connect to 2G or 3G networks when a stronger LTE or 5G signal is unavailable, and those older generations have weaker or absent mutual authentication between device and network. GSM's original ciphering, A5/1 and its variants, has known cryptanalytic weaknesses, and some carriers still operate 2G infrastructure for legacy device support or emergency fallback.

The practical risk is that an attacker with a rogue base station can force a nearby device onto 2G, then intercept or manipulate its traffic, without the device or user noticing a difference beyond a signal indicator. For a medical device, this can mean exposed telemetry or interrupted communications at exactly the moment reliable connectivity matters most.

[KEY REQUIREMENT] If 2G or 3G fallback cannot be disabled entirely due to coverage requirements, the decision must be documented with a rationale, scoped to specific regions if possible, and paired with monitoring for unexpected downgrade events in the field.

What Are IMSI Catchers and Why Do They Matter for Medical Devices?

An IMSI catcher is a device that impersonates a legitimate cell tower to capture a device's International Mobile Subscriber Identity and, on older network generations, intercept or manipulate its traffic. They matter for medical devices because a device forced to connect to a rogue tower can have its location tracked, its traffic observed, or its connection disrupted, all without any indication visible to a clinician or patient.

Modern LTE and 5G networks include stronger mutual authentication that reduces, but does not eliminate, IMSI catcher effectiveness, since some downgrade and identity-exposure techniques still work against devices that support legacy fallback. Devices that never fall back to 2G/3G and that protect traffic end to end with TLS are substantially more resistant, because even a successful IMSI catcher session yields little beyond encrypted, authenticated traffic.

Manufacturers should assume that some fraction of deployed devices will, at some point, encounter a rogue or misconfigured cell tower, whether from an attacker, a testing lab, or interference, and design so that event does not compromise patient data or device integrity.

How Should Manufacturers Handle eSIM and Carrier Provisioning?

eSIM and carrier provisioning should be handled with the same lifecycle discipline as certificate management: secure issuance during manufacturing, controlled rotation, and a clear revocation path if a device is lost, stolen, or decommissioned. Unlike a physical SIM, an eSIM profile is provisioned remotely, which is convenient for fleet management but creates a new attack surface if the provisioning channel itself is not authenticated and encrypted.

A common failure mode is treating the carrier's provisioning API credentials as a low-priority secret, when in practice compromise of those credentials could let an attacker reprovision or deactivate devices at scale. Manufacturers should scope provisioning credentials tightly, rotate them on a defined schedule, and log provisioning events for audit and anomaly detection.

[KEY REQUIREMENT] eSIM provisioning credentials and APIs must be treated as privileged secrets with access logging, rotation, and revocation procedures documented in the same way as device-level cryptographic key management.

LTE and 5G in Medical Devices: What Actually Changes?

See also: NeuroTech Cybersecurity Risks, QNX Vulnerabilities in Medical Devices, and Medical Device Interoperability: Cybersecurity Risks Explained.

LTE and 5G improve on GSM-era security with stronger mutual authentication and better protection against basic impersonation, but they do not eliminate the need for application-layer protections. 5G in particular adds encrypted identifier exchange in some deployment modes, reducing exposure to IMSI-catcher-style tracking, though real-world carrier configurations vary and not all of these protections are universally deployed.

The practical change for manufacturers is less about a single "more secure" checkbox and more about module selection and configuration. LTE-M and NB-IoT variants, common in low-power medical telemetry devices, inherit LTE's authentication model but may have different power and bandwidth tradeoffs that affect how often a device can check in or receive updates.

Manufacturers should not assume "we use LTE" alone satisfies a security requirement; the module's fallback configuration and the application-layer controls built on top of it determine the actual risk posture.

Is Data at Rest on the Modem a Real Risk?

Yes, data cached or logged on the cellular modem is a real and often overlooked risk, because modems maintain their own storage, logs, and sometimes cached credentials that are rarely audited with the same rigor as the main application processor. Diagnostic logs, cached authentication tokens, or buffered telemetry sitting unencrypted on the modem can be extracted if the device or module is physically compromised.

This matters most for devices that are serviced in the field, decommissioned, or resold, where a modem's flash storage may retain data long after the device leaves clinical use. Manufacturers should inventory what the modem stores, encrypt sensitive data at rest where the module supports it, and include modem storage in the device's decommissioning and data-sanitization procedure.

How Should Remote Updates Be Delivered Over Cellular for Home-Use Devices?

Remote updates over cellular for home-use devices should be delivered as signed, integrity-verified packages with resilience built in for unreliable and low-bandwidth connections. Home-use devices cannot depend on stable connectivity the way a hospital network device might, so the update process needs to tolerate interruptions without leaving the device in an inconsistent or unsafe state.

Practical design points include chunked or resumable downloads so a dropped connection does not force a full restart, cryptographic signature verification before an update is applied, and a rollback path if an update fails validation or causes a fault after installation. Update servers should also authenticate the device before serving a package, so a compromised or spoofed device identity cannot be used to pull sensitive update content or trigger unnecessary downloads that drain battery or data allowances.

[KEY REQUIREMENT] Update packages delivered over cellular must be signed and verified on-device before installation, with a documented rollback and safe-state behavior if verification fails mid-update.

How Blue Goat Cyber Approaches This

Blue Goat Cyber helps manufacturers map the full cellular trust boundary, from modem to carrier to backend, before it becomes a late-stage architecture problem. That includes evaluating fallback configuration, eSIM provisioning security, modem data handling, and update delivery design against the threats most relevant to the device's intended use, whether hospital-serviced equipment or a home-use remote monitor.

For teams validating these designs, our medical device penetration testing services test cellular-connected devices against realistic downgrade, interception, and provisioning abuse scenarios, and our medical device threat modeling work produces the documented trust boundary analysis the FDA expects to see tied to your cellular architecture decisions.

Frequently Asked Questions

Should medical devices disable 2G entirely?

Disabling 2G is the safer default wherever coverage requirements allow it, since 2G carries documented weak-authentication and interception risks. If 2G must remain available for coverage reasons, document the rationale, limit it to specific regions if possible, and monitor for unexpected downgrade events.

What is an IMSI catcher and can it affect a medical device?

An IMSI catcher impersonates a legitimate cell tower to capture device identifiers and, on older network generations, intercept traffic. It can affect medical devices that support legacy fallback, though devices using end-to-end TLS and avoiding 2G/3G are much more resistant to meaningful data exposure.

Is eSIM more secure than a physical SIM for medical devices?

eSIM can be more secure because it supports remote, auditable provisioning and revocation, but only if the provisioning channel and credentials are protected as carefully as any other cryptographic secret. A poorly secured provisioning API can offset the benefits of eSIM's flexibility.

How is this different from the site's Bluetooth and NFC/RFID coverage?

This article covers wide-area cellular connectivity specifically. For short-range wireless risks in medical devices, see our coverage of Bluetooth in medical devices and NFC and RFID security in medical devices.

CTA

If your device relies on cellular connectivity for therapy, monitoring, or updates, Blue Goat Cyber can help you threat model the cellular path and build the documentation the FDA expects to see. Book a discovery session to scope the work.