BLE & RF Penetration Testing: A Medical Device Case Study

Part of our Medical device penetration testing series. For the full overview, start with FDA Penetration Testing Requirements for Medical Devices.

Wireless interfaces are where most medical device pen tests get the thinnest. This case study walks through how we test BLE and proprietary RF on a representative Class II connected device, the eight findings we surface most often, and what an FDA reviewer expects to see in the report.

A web-only pen test against a connected medical device is a near-automatic FDA deficiency. The February 2026 final premarket guidance and Section 524B both expect testing scoped to the threat model and exercised across every declared interface. For most modern devices, that means BLE, sub-GHz proprietary RF, occasionally NFC, and sometimes cellular - in addition to the cloud, mobile app, and any wired service interface.

This is a sanitized case study based on representative engagements: a Class II connected wearable with a BLE companion-app channel for telemetry and configuration, plus a sub-GHz proprietary RF link to a base station. Device specifics have been generalized; the methodology and findings are the patterns we see most.

Key Takeaways

• FDA requires testing all declared medical device interfaces.
• BLE and sub-GHz RF are critical attack surfaces.
• Unsigned firmware updates are high-severity findings.
• Secure pairing and authentication are essential for wireless.
• Penetration test reports must align with the threat model.
• Document findings with patient safety impact and remediation.

Table of Contents

• Key Takeaways
• The device under test
• Scope and methodology
• Eight findings we surface most often
• What the report looks like
• Why this matters for the submission
• Where this fits in the cluster
• Want this kind of test on your device?

The device under test

• Class II wearable with continuous physiological monitoring.
• BLE 5.2 connection to a mobile companion app for telemetry, configuration, and firmware update.
• Sub-GHz proprietary RF (FSK, ~900 MHz) to a home base station for clinician-facing dashboards.
• No direct cellular; data egress via the base station's LTE modem.
• Firmware updates delivered via BLE from the companion app.

Threat-model relevant trust boundaries: phone-to-device (BLE), device-to-base-station (RF), companion-app-to-cloud (TLS), base-station-to-cloud (TLS).

Scope and methodology

We test against the threat model, not against a generic checklist. For this device, the in-scope wireless attack surfaces were:

• BLE pairing, bonding, GATT services and characteristics, OTA firmware path, encryption / MITM resistance.
• Sub-GHz RF protocol reverse-engineering, replay, spoofing, jamming sensitivity at the application layer.
• Firmware integrity and rollback across both wireless channels.

The lab setup:

• BLE: Ellisys Bluetooth Tracker, nRF52840 dongles with Sniffle, Wireshark with the nRF and Btsnoop dissectors, a rooted Android test phone for active fuzzing via BTLEJuice and custom GATT clients.
• Sub-GHz RF: HackRF One and an SDR-RTL companion for capture, Universal Radio Hacker for protocol reverse-engineering, a YARD Stick One for active transmit, and a Faraday tent for FCC-safe transmission tests.
• Static / dynamic: firmware extracted from the OTA stream, analyzed with Ghidra and binwalk; runtime instrumentation on the companion app with Frida.

This is not a checklist. Every finding below was validated end-to-end, with a documented proof-of-concept and a risk-rated impact statement mapped to the device's ISO 14971 risk file.

Eight findings we surface most often

01 - Just Works BLE pairing on a configuration GATT characteristic

The device used Just Works pairing because the wearable has no display. An attacker within BLE range could pair without user interaction and write to a GATT characteristic that adjusted alerting thresholds.

Fix: Move to LE Secure Connections with numeric comparison via the companion app (the app supplies the I/O capability the device lacks). Require app-side authentication before any write to configuration characteristics, regardless of pairing mode.

02 - Firmware OTA accepted unsigned images

The OTA bootloader verified a CRC but not a cryptographic signature. We replayed a captured firmware image with a one-byte modification; the device installed it and rebooted into the modified firmware.

Fix: Sign firmware images with an ECDSA P-256 key, verify in the bootloader before commit, and store the public key in a write-protected region. Add anti-rollback via a monotonic version counter. This is the single highest-severity finding type we see and is a frequent FDA deficiency trigger.

03 - Sub-GHz RF replay of telemetry packets

The proprietary RF protocol used a fixed 32-bit packet header with a sequence number that reset on power-cycle. Captured packets replayed cleanly to the base station.

Fix: Add per-packet authentication using a session key derived during enrollment. A rolling nonce alone is not enough if the device can be power-cycled.

04 - GATT characteristic exposes service-mode access without authentication

A "service mode" characteristic permitted reading raw sensor calibration and a vendor-defined debug log. No authentication. Useful to a clinician at a bench; equally useful to an attacker mapping the device.

Fix: Gate service-mode characteristics behind a hardware-attested challenge from the companion app, or require physical action (long-press) on the device to enable.

05 - BLE advertising packets leak device serial number

The device advertised a manufacturer-data field containing the device serial in plaintext. Combined with the manufacturer ID, this allowed fleet-wide enumeration of devices in a clinical setting from a hallway.

Fix: Use a rotating identifier in advertising packets; resolve to the persistent serial only after authenticated pairing.

06 - MITM-via-companion-app downgrade

See also: FDA IDE Cybersecurity Requirements: 2026 Submission Guide, MQTT Vulnerabilities in Connected Medical Devices: FDA Risks, Controls, and Deficiency Patterns, and SBOM Diffing and CVE Correlation: The Postmarket Workflow the FDA Expects.

The companion app accepted a legacy pairing fallback when LE Secure Connections failed. A test rig forcing pairing failure triggered the fallback path, enabling a passive eavesdropping window.

Fix: Disable legacy pairing fallback. If it must exist for compatibility, alert the user prominently.

07 - Companion app stores BLE long-term key in unprotected storage

The Android companion app stored the BLE LTK in shared preferences without Keystore protection. A malicious app with overbroad permissions could recover the LTK and impersonate the bonded phone.

Fix: Bind the LTK to the Android Keystore (or iOS Secure Enclave); enforce minimum OS version and root/jailbreak detection per the device's threat model.

08 - Jamming sensitivity not characterized

Not strictly an attack, but reviewers ask: how does the device behave when the RF link is denied? The device under test silently buffered telemetry and did not surface a clinician-visible alert until 30 minutes of continuous loss.

Fix: Document the failure mode in labeling. Add a configurable alerting threshold for sustained connectivity loss. This is a safety-by-design finding more than a security finding, but reviewers want to see both addressed.

What the report looks like

An FDA-grade wireless pen test report for this device included:

• Executive summary with overall risk posture and headline findings.
• Scope statement matching the threat model interfaces.
• Methodology with tooling, test environment, and rules of engagement.
• Per-finding writeups: description, reproduction steps, impact on patient safety, ISO 14971 traceability, CVSS v4.0 score, recommended remediation.
• Verification matrix: which threat model entries were exercised, with pass / fail per entry.
• Retest plan: the unlimited-retest scope our premarket service includes covers verification of every remediation.

Reviewers do not want a Nessus dump. They want a narrative tied to the threat model with evidence per finding.

Why this matters for the submission

Wireless findings are where most submissions fail their first cybersecurity AI letter. Three reasons:

01 - The pen test report covers wired and web interfaces well but treats BLE / RF as a paragraph. 02 - The threat model declares wireless trust boundaries but the test report does not exercise them. 03 - The remediation evidence is missing - a fix is documented but no retest confirms the control.

A premarket package that closes all three of those, mapped cleanly into the eSTAR cybersecurity section, clears the most common deficiency pattern in 2025-2026 submissions.

Where this fits in the cluster

• Medical Device Penetration Testing
• Wireless Penetration Testing
• The SPDF Playbook for FDA-Ready Medical Devices
• 12 Critical Findings from Medical Device Penetration Tests
• eSTAR Cybersecurity Readiness Checklist

Want this kind of test on your device?

We do BLE, sub-GHz RF, NFC, cellular, and wired-interface penetration testing in-house, with medical-device context and FDA-formatted reports. Book a free 30-minute discovery session and we will scope a fixed-fee engagement in 24 hours.

How Blue Goat approaches this

Our approach to BLE and RF penetration testing for medical devices focuses on uncovering vulnerabilities that impact patient safety and data integrity while meeting regulatory expectations. We go beyond surface-level scanning, employing specialized tools and proprietary techniques to emulate real-world attack scenarios against wireless interfaces. Our team, comprised of professionals with certifications such as CISSP and OSCP, and ex-military red team experience, meticulously documents every step, from scope definition to exploit validation. We provide actionable recommendations tailored to your device's unique risk profile, ensuring traceability to relevant standards. Our reports are designed for clarity and directly address the requirements of the FDA. We stand by our work: if the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our services at: https://www.bluegoatcyber.com/services/medical-device-penetration-testing

FAQ

What wireless interfaces does the FDA expect medical device testing to cover?

The FDA expects medical device testing to cover all declared wireless interfaces, which commonly include BLE, proprietary RF, NFC, and cellular, in addition to cloud, mobile app, and wired interfaces.

How does the FDA view 'Just Works' BLE pairing for medical devices?

The FDA views 'Just Works' BLE pairing as insufficient for medical devices that handle sensitive data or critical functions, especially if it allows unauthenticated configuration changes. Secure authentication methods are preferred.

What is the most critical wireless finding in medical device pen tests?

The most critical wireless findings often involve unsigned firmware images accepted via over-the-air updates, which can lead to unauthorized software installation and are a frequent FDA deficiency trigger.

Why is RF jamming sensitivity important for medical device reports?

RF jamming sensitivity is important for medical device reports because the FDA evaluates device behavior during communication loss. Manufacturers must characterize and document how the device responds to denial-of-service scenarios.

What should an FDA-grade wireless pen test report include?

An FDA-grade wireless pen test report should include an executive summary, scope, detailed methodology, per-finding write-ups with patient safety impact and ISO 14971 traceability, a verification matrix, and a retest plan.

Does the FDA require retesting of all remediated findings?

Yes, the FDA expects remediation evidence for all identified vulnerabilities. Retesting and verifying that controls effectively address findings matters for a complete premarket submission.

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.