BLE Security in Medical Devices: What to Get Right

Reviewed September 17, 2026

BLE shows up in continuous glucose monitors, insulin pumps, hearing aids, patient monitors, and clinician programmers because it is low power and widely supported, not because it is inherently secure. That distinction matters because the same protocol that lets a device run for months on a coin cell can also expose therapy settings, telemetry, or firmware update channels if pairing and access control are left at default settings. A CGM broadcasting glucose values without link-layer encryption, or a programmer that accepts any device advertising a matching name, are configuration failures, not protocol failures. Manufacturers preparing an FDA submission need to show they evaluated BLE's specific pairing, bonding, and GATT permission model against realistic attacker capability, not assert that using BLE satisfies a security requirement on its own.

Why This Matters

The FDA's "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" final guidance, dated February 3, 2026, expects manufacturers to identify the specific communication interfaces on a device and analyze the attack surface each one introduces. BLE is treated as a distinct interface with its own pairing, bonding, and characteristic-level access control model, and a generic wireless security narrative does not satisfy that expectation. Reviewers look for evidence that the manufacturer considered how an attacker within radio range, not just an attacker with network access, could interact with the device.

This matters because BLE's convenience, no cables, long battery life, broad phone compatibility, creates an attack surface that classic wired interfaces do not have. A device with a vulnerable BLE implementation can be attacked without ever touching the patient's network, simply by being physically nearby. AAMI SW96, FDA Recognized Consensus Standard 13-131, and IEC 81001-5-1 both expect wireless-specific risk analysis as part of the broader security risk management process, and BLE pairing and GATT design decisions are exactly the kind of detail that analysis has to cover.

What Is BLE and How Does It Differ From Bluetooth Classic?

BLE, or Bluetooth Low Energy, is a wireless protocol that shares the 2.4 GHz ISM band with Bluetooth Classic but uses a different stack designed for intermittent, low-power communication rather than continuous streaming. Bluetooth Classic maintains a persistent connection suited to audio and file transfer, which draws significantly more power. BLE instead uses short connection events and a client-server data model, which is why it dominates in battery-powered medical devices that need to report periodically rather than stream continuously.

The two protocols are not interoperable at the radio or stack level, despite sharing a brand and frequency band. A device supporting BLE will not connect to a Bluetooth Classic-only peer, and security mechanisms, including pairing methods and key exchange, are defined separately for each.

What Is the BLE Stack and GATT Model?

The BLE stack organizes communication into layers, with the Generic Attribute Profile, GATT, defining how data is structured and exchanged between a central device, such as a phone or programmer, and a peripheral, such as a sensor or pump. GATT organizes data into services and characteristics, each with its own read, write, and notify permissions. A characteristic can be configured to require no security, unauthenticated pairing, or authenticated pairing with encryption before it can be accessed.

[KEY REQUIREMENT] Every GATT characteristic that exposes therapy settings, calibration data, or firmware control must require authenticated encryption at the attribute permission level, not rely solely on the fact that the device paired successfully at connection time.

Why Do Medical Devices Use BLE?

Medical devices use BLE because it delivers months or years of battery life while still supporting periodic data exchange with a phone, gateway, or clinician programmer. Continuous glucose monitors and patient wearables use it to push readings to a companion app without daily charging. Insulin pumps and hearing aids use it for configuration and firmware updates from a paired device, and patient monitors and programmers use it to pull telemetry or push therapy adjustments in clinical settings. These use cases share a common risk profile: the data or commands passing over BLE often have direct clinical consequence if intercepted or forged.

How Do BLE Pairing and Bonding Methods Compare?

BLE pairing methods differ in how they establish a shared key and how resistant they are to interception or impersonation, and the difference between Legacy pairing and LE Secure Connections is the most consequential choice a manufacturer makes.

Legacy pairing, used before Bluetooth 4.2's LE Secure Connections, derives keys using a method vulnerable to passive eavesdropping if an attacker captures the pairing exchange. LE Secure Connections uses Elliptic Curve Diffie-Hellman, ECDH, key exchange instead, so a passive observer of the pairing process cannot derive the resulting long-term key even if they capture every packet. This is the single most important upgrade a legacy BLE implementation can make.

What Are the Concrete BLE Attack Classes?

BLE attacks target specific weaknesses in pairing, addressing, and the GATT access model, and most fall into a small number of well-documented classes. Passive sniffing of Legacy pairing exchanges lets an attacker with commodity sniffer hardware recover the long-term key without ever interacting with either device. A man-in-the-middle attack against Just Works pairing succeeds because Just Works provides no way for either party to confirm they are talking to the intended peer, so an attacker can relay or alter traffic during the pairing exchange itself.

Spoofing and impersonation attacks exploit devices that authenticate only by advertised name or service UUID, letting an attacker's device masquerade as a legitimate sensor or programmer. KNOB and BLURtooth-class attacks manipulate key negotiation or cross-transport key derivation to force weaker encryption or reuse keys across Bluetooth Classic and BLE. GATT characteristic enumeration lets an attacker discover every exposed service on a device, and unauthenticated read or write access on any of those characteristics can leak telemetry or alter configuration without ever completing a real pairing. Replay attacks resend previously captured legitimate commands when a device does not track sequence numbers or freshness. Denial of service and battery drain attacks repeatedly trigger connection attempts or advertising responses to exhaust a battery-powered device faster than intended. Finally, tracking risk differs sharply between devices that broadcast a static MAC address, which lets an observer log a patient's device location over time, and devices using resolvable private addresses that rotate on a schedule known only to bonded peers.

What Does Good BLE Security Look Like?

See also: Embedded Cybersecurity Challenges MedTech, Radiology Information System: What It Is and How It Works, and NFC and Medical Device Cybersecurity.

Good BLE security combines LE Secure Connections with the strongest pairing method the device's I/O supports, Numeric Comparison or OOB where a display or secondary channel exists, and treats the link layer as one layer of defense rather than the only one. Application-layer authentication and encryption, independent of the BLE link, should protect any command or data that has clinical consequence, so that a link-layer pairing weakness discovered later does not expose the therapy path directly.

[KEY REQUIREMENT] Devices should use per-device keys rather than a shared key baked into firmware across a product line, since a single extracted key from one compromised unit should never grant access to every other unit in the field.

Additional practices that separate a defensible implementation from a vulnerable one include enforcing attribute permissions that require authenticated encryption on any sensitive characteristic, managing bonding records so a lost or decommissioned device's keys can be revoked, authenticating firmware updates delivered over BLE so a bonded connection alone is not sufficient to push new code, and limiting the pairing window so a device only accepts new bonds during a deliberate, physically proximate action rather than indefinitely.

How Should BLE Security Be Tested?

BLE security should be tested with a combination of radio-level sniffing, protocol-level enumeration, and active manipulation, not just a code review of the stack configuration. Sniffer hardware captures the pairing exchange and connection traffic to verify whether Legacy pairing or LE Secure Connections is actually in use in the field, since firmware documentation and field behavior do not always match. GATT enumeration tools map every service and characteristic to confirm which ones require authentication and which do not. Fuzzing the BLE stack, sending malformed or out-of-sequence packets, tests whether the implementation handles unexpected input without crashing or entering an insecure state, and replay testing confirms whether previously captured commands can be resent successfully.

What Should the Threat Model and FDA Submission Document?

The threat model and FDA submission should document the specific BLE pairing method used, the rationale for that choice given the device's I/O capabilities, and the mitigations in place for each attack class relevant to the device's GATT design. Under the FDA's February 3, 2026 premarket cybersecurity guidance, reviewers expect this analysis to name BLE explicitly rather than fold it into a general wireless security statement. The submission should show which characteristics carry sensitive data or commands, what permission level protects each one, and how bonding and key management are handled across the device's lifecycle, including decommissioning.

How Blue Goat Cyber Approaches This

Blue Goat Cyber evaluates BLE implementations through architecture review, protocol-level testing, and penetration testing rather than a documentation-only assessment. We capture and analyze the actual pairing exchange in the field, enumerate GATT services and characteristics for unauthenticated access, and test companion mobile applications for the same trust assumptions that show up in firmware. In BLE engagements we most commonly find Just Works pairing left enabled in production, static keys reused across units, and GATT characteristics that expose configuration without authentication, each of which we map to a specific threat and mitigation in the submission package. Our team includes CISSP and OSCP-certified engineers with backgrounds in red team operations. Manufacturers preparing a BLE-enabled device for submission can start with our medical device penetration testing services.

Frequently Asked Questions

Is BLE inherently secure for medical devices?

No, BLE is a transport protocol whose security depends entirely on how pairing, bonding, and GATT permissions are configured. A device using BLE with Just Works pairing and unauthenticated characteristics is not secure simply because it uses BLE. Manufacturers have to make explicit configuration choices and document why they are appropriate for the device's risk profile.

What is the difference between Legacy pairing and LE Secure Connections?

Legacy pairing, used in earlier Bluetooth versions, derives its shared key in a way that a passive eavesdropper can recover if they capture the pairing exchange. LE Secure Connections, introduced in Bluetooth 4.2, uses Elliptic Curve Diffie-Hellman key exchange, so a passive observer cannot derive the resulting key even with a full capture of the exchange. Devices should use LE Secure Connections wherever the hardware supports it.

Why is Just Works pairing considered risky?

Just Works pairing provides no mechanism for either device to verify the identity of the other during the pairing exchange, which means it offers no resistance to a man-in-the-middle attack. It remains common because it requires no display or input on the peripheral device. Where a device has no I/O capability at all, application-layer authentication should compensate for what link-layer pairing cannot provide.

What is GATT characteristic enumeration and why does it matter?

GATT characteristic enumeration is the process of discovering every service and characteristic a BLE device exposes, along with the permission level protecting each one. It matters because unauthenticated read or write access on a single overlooked characteristic can expose telemetry or allow configuration changes without ever completing a real pairing. It is one of the most consistently productive tests in a BLE security assessment.

Do resolvable private addresses solve BLE tracking risk?

Resolvable private addresses reduce tracking risk by rotating the address a device broadcasts on a schedule known only to bonded peers, rather than exposing a static MAC address indefinitely. They do not eliminate tracking risk on their own if a companion app logs a persistent identifier elsewhere or if the rotation interval is too long. The address scheme has to be evaluated alongside the rest of the device's identifier handling.

What does the FDA expect documented about BLE specifically?

The FDA's February 3, 2026 premarket cybersecurity guidance expects the threat model to name BLE explicitly, describe the pairing method chosen and why, and map specific attack classes relevant to the device's GATT design to documented mitigations. A generic statement that the device uses encrypted wireless communication does not meet this expectation.

CTA

If your BLE implementation has not been tested at the protocol level, radio-based attacks against pairing and GATT access can be missed by a code review alone. Blue Goat Cyber can assess your BLE stack, pairing configuration, and companion app before your next FDA submission. Contact us to scope a wireless security assessment.

Continue the BLE security series

Dive deeper with these companion articles:

• BLE Vulnerabilities in Medical Devices
• SweynTooth BLE Vulnerability in Medical Devices
• Bluetooth in Medical Devices: Security Risks and Controls
• Implantable Device Cybersecurity: Risks, Controls, Evidence
• Securing IoT-Enabled Medical Devices: 5 Essential Tips