Bluetooth in Medical Devices: Security Risks and Controls

Part of our Bluetooth Low Energy security series for medical devices. For the full overview, start with BLE Security in Medical Devices: What to Get Right.

Reviewed September 17, 2026

Bluetooth is the default radio for anything that has to talk to a phone, which is why it appears in glucose monitors, hearing aids, wearable sensors, insulin delivery systems, and home monitoring devices. It is also the interface manufacturers most often assume is secure because the specification includes encryption.

The specification does include encryption. It also includes a pairing method that authenticates nothing, supports legacy modes with known weaknesses, and leaves most of the meaningful security decisions to the implementer. Understanding where the protocol stops and your responsibility starts is what separates a device that passes radio testing from one that does not.

Why Bluetooth Deserves Specific Attention in a Submission

Wireless interfaces are where a remote attacker meets your device without touching it. The February 3, 2026 premarket cybersecurity guidance expects manufacturers to identify their attack surface and to test it, and a radio that accepts connections from anything in range is the most accessible part of that surface for a device used at home.

The known weaknesses are in the standard, which means they affect implementations broadly rather than one vendor. The KNOB attack, disclosed in 2019, showed that an attacker could force negotiation of a very short encryption key length, undermining the link encryption. BLURtooth, disclosed in 2020, targeted cross-transport key derivation between Bluetooth Classic and BLE. BLESA, also disclosed in 2020, targeted the reconnection process, where authentication is weaker than at initial pairing. SweynTooth, disclosed in 2020, was a family of implementation flaws in multiple BLE chipset software development kits that caused crashes, deadlocks, and in some cases security bypasses, and the FDA issued a safety communication about it in March 2020 because affected chipsets appeared in medical devices.

That safety communication is the reason a reviewer takes BLE seriously. The agency has already told manufacturers publicly that a chipset-level radio flaw can reach patients, which makes an untested radio interface a visible gap rather than an acceptable omission.

How BLE Pairing Actually Decides Your Security

Pairing establishes the keys that protect the link. The association model used during pairing decides whether an attacker in the middle can insert themselves.

Just Works is the source of most real problems. It is chosen because the device has no display and no input, which is true of many sensors and wearables, and it produces an encrypted link with no assurance about who is on the other end. An attacker within range can complete pairing and the device cannot tell the difference.

[KEY REQUIREMENT] If your device must use Just Works because it has no user interface, your submission needs to say so and describe the application-layer authentication that compensates for it. A pairing method chosen by hardware constraint is defensible; an unacknowledged one is not.

The second decision is whether you use LE Legacy Pairing or LE Secure Connections. Legacy pairing, used before Bluetooth 4.2, has a key exchange that does not resist passive interception in the same way. LE Secure Connections uses elliptic curve Diffie-Hellman and is the baseline any new design should target.

The Attack Classes You Should Be Testing Against

Denial of service deserves a note because it is often dismissed as a nuisance. For a device that delivers therapy or alarms on a clinical condition, an attacker who can keep the radio unavailable has created a patient safety condition. The threat model should treat radio availability as a safety property when the clinical function depends on it.

Privacy tracking matters too. A device that advertises a static address broadcasts a persistent identifier, which for a medical device can reveal that a person is using a particular therapy. Resolvable private addresses exist precisely for this, and using them is a straightforward configuration decision.

What Belongs in Your Submission

Reviewers are looking for the radio to be treated as a first-class interface rather than an implementation detail.

See also: Medical Device Wi-Fi Security Guide, NeuroTech Cybersecurity Risks, and PATCH Act: Legacy Device Cyber Gaps.

The SBOM entry is the one teams forget. The Bluetooth stack usually comes from the chipset vendor, it has its own version history and its own advisories, and the SweynTooth family showed exactly why you need to know which version you shipped. When a new stack advisory appears, the SBOM is what lets you answer whether you are affected.

Testing a Bluetooth Interface Properly

Testing the mobile app that talks to your device is not testing the radio. The app uses your intended interface in the intended way; an attacker does not. Radio testing means operating at the protocol level with equipment that can observe and inject traffic, attempt unauthorized connections, force renegotiation, and send malformed packets.

A reasonable scope covers pairing and re-pairing behavior, what the device exposes before authentication, whether GATT characteristics enforce authorization, whether the device accepts connections it should refuse, behavior under connection flooding, and response to malformed input. It should also verify that the security requirements you wrote for the radio were actually implemented, which is a different question from whether an attacker succeeded on the day of testing.

How Blue Goat Cyber Approaches This

We test Bluetooth interfaces over the air, with radio equipment rather than through the vendor app, because the app cannot reproduce what an attacker in range will do. That covers pairing negotiation, reconnection behavior, GATT authorization, downgrade resistance, and the device's behavior when the radio is attacked rather than used.

Our medical device penetration testing includes the wireless layer as standard for connected devices, and our threat modeling work puts the radio in the architecture views as the trust boundary it is.

Frequently Asked Questions

Is Bluetooth Low Energy secure enough for medical devices?

It can be, when the device uses LE Secure Connections with an authenticated pairing method and adds application-layer authentication on top. BLE becomes a problem when a device relies on protocol defaults, particularly Just Works pairing on hardware with no user interface, and treats the presence of link encryption as sufficient evidence of security.

What is Just Works pairing and why is it a problem?

Just Works is the BLE association model used when neither device can display or enter a passkey. It produces an encrypted link but authenticates nothing, so an attacker in radio range can pair with the device and the device cannot distinguish them from the legitimate peer. It is sometimes unavoidable on hardware without a user interface, which is why compensating authentication at the application layer matters.

Did the FDA issue guidance about Bluetooth vulnerabilities?

The FDA issued a safety communication in March 2020 regarding the SweynTooth family of Bluetooth Low Energy vulnerabilities, which affected software development kits from multiple chipset manufacturers used in medical devices. The communication advised manufacturers to evaluate affected devices and work with chipset vendors on patches, and it is a useful reference for why radio stack versions belong in your SBOM.

Do we need to test the radio if we already tested the mobile app?

Yes. Application testing exercises the interface through the intended client, which behaves correctly by design. Radio testing exercises the interface the way an attacker would, using equipment that can attempt unauthorized connections, force renegotiation, and send malformed packets. They answer different questions and a submission generally needs both.

How should devices handle reconnection security?

By authenticating on every reconnection rather than trusting a previously bonded identity without verification. The BLESA research demonstrated that reconnection is frequently weaker than initial pairing, because implementations treat an existing bond as sufficient proof of identity. Verifying the peer on each reconnect closes the gap.

What about Bluetooth Classic in medical devices?

Bluetooth Classic still appears in devices that need higher throughput, such as audio applications in hearing devices. It carries its own history, including the KNOB key negotiation weakness, and devices supporting both transports need to consider cross-transport key derivation issues of the kind BLURtooth exploited. Dual-mode devices should document both stacks.

Have a Device With a Radio in It?

If your device pairs with a phone or a hub, the radio is the part of your attack surface an attacker reaches first and the part most often left untested. We test it the way they would. Book a strategy session.

---

Blue Goat Cyber specializes in medical device cybersecurity, from threat modeling and penetration testing through premarket submission support. Our team works exclusively with device manufacturers preparing FDA submissions. Learn more about Christian Espinosa, our founder and CEO.