BLE & RF Penetration Testing

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

This illustrative case study describes BLE and proprietary RF testing for a hypothetical Class II connected device, eight example findings, and the evidence a submission report should contain.

A web-only pen test against a connected medical device is a potential FDA deficiency. The February 2026 final premarket guidance and Section 524B require statutory cybersecurity processes and recommend 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 an illustrative composite, not a verified single-device engagement: a hypothetical Class II wearable uses BLE for telemetry and configuration and a sub-GHz RF link to a base station. The device configuration and findings below are hypothetical.

The illustrative device

• 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 hypothetical device, proposed wireless test surfaces include:

• 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.

An example lab setup:

• BLE: Ellisys Bluetooth Tracker, supported TI CC13xx/CC26xx hardware 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.

The findings below are illustrative composite scenarios, not verified results from a single device engagement. An actual report should include test evidence and traceability to the device risk-management file.

Eight illustrative findings

01 - Just Works BLE pairing on a configuration GATT characteristic

In this hypothetical scenario, the device uses 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: Use an authenticated association model supported by both endpoints, such as suitable out-of-band pairing, or independently authenticated application-layer communication. Enforce authorization for configuration writes on the device.

02 - Firmware OTA accepted unsigned images

In this hypothetical scenario, the OTA bootloader checks a CRC but not a cryptographic signature. A test would modify an image and check whether the bootloader rejects it; acceptance and execution require device-specific evidence.

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. Assess severity and submission implications against the demonstrated device-specific impact.

03 - Sub-GHz RF replay of telemetry packets

In this hypothetical scenario, the proprietary RF protocol uses a fixed 32-bit packet header with a sequence number that reset on power-cycle. A replay test would assess whether the base station accepts previously captured packets.

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

In this hypothetical scenario, a "service mode" characteristic permits 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

In this hypothetical scenario, the device advertises a manufacturer-data field containing the device serial in plaintext. Combined with the manufacturer ID, this could allow 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: Fuzz Harness Generation for Medical Device Protocols, What Is MedTech? MedTech vs Medical Device vs Life Sciences, and 8 FDA Cybersecurity Documentation Gaps to Review.

In this hypothetical scenario, the companion app accepts a legacy pairing fallback when LE Secure Connections failed. Test whether forced pairing failure triggers fallback; eavesdropping depends on the association method and the captured exchange.

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

This hypothetical scenario alleges an exposed BLE LTK. Recovering a stored key would require a demonstrated sandbox bypass, root access, exported data path, or other specific exposure; ordinary permissions alone do not establish this attack. BLE bonding keys ordinarily belong to the platform Bluetooth subsystem.

Fix: Use platform-managed BLE bonding keys; protect separately managed application credentials with supported platform key-storage APIs and test the actual exposure path.

08 - Jamming sensitivity not characterized

Not strictly an attack, but reviewers ask: how does the device behave when the RF link is denied? In this hypothetical scenario, the device buffers telemetry and delays a clinician-visible alert until 30 minutes of continuous loss; an actual delay must be measured and assessed against clinical needs.

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 FDA guidance recommends both addressed.

What the report looks like

An illustrative wireless pen test report structure would include:

• 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 testing gaps may prompt reviewer questions. Three examples:

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 a potential deficiency pattern in 2025-2026 submissions.

Where this fits in the cluster

• Medical Device Penetration Testing
• Wireless Penetration Testing
• The SPDF Playbook for Medical Device Premarket Submissions
• 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, 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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Learn more about our services at: https://bluegoatcyber.com/services/medical-device-penetration-testing

Related reading: Hardware Hacking Tools Used in Medical Device Testing.

FAQ

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

FDA guidance recommends that medical device testing 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?

Just Works lacks pairing-level man-in-the-middle protection and may be 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?

Not every finding requires a fix; document risk acceptance or remediation, and verify the effectiveness of implemented controls. Retesting and verifying that controls effectively address findings matters for a complete premarket submission.