BLE & RF Pen Testing for Connected Devices.
Targeted wireless interface testing for BLE, Wi-Fi, NFC, and proprietary RF protocols. The attack surface generic pen testers can't reach. Reviewer-ready evidence for FDA premarket and EU MDR submissions.
The short answer
What is BLE and RF penetration testing for medical devices?
BLE and RF penetration testing checks a device's wireless interfaces, such as Bluetooth Low Energy, Wi-Fi, Zigbee, NFC and proprietary radio, for weaknesses an attacker in range could use. Typical checks include pairing and bonding, authentication of commands, encryption, replay attacks and fuzzing of the radio protocol. Findings are rated for patient-harm risk and traced to your threat model for the FDA report.
275+ FDA submissions supported, zero cybersecurity rejections.
- BLE & GATT
- Wi-Fi & EAP
- Proprietary RF / SDR
- NFC & RFID
- Free 30-min scoping call
- Fixed-fee quote in 24 hours
- Senior wireless tester, not a generalist
- SDR + protocol fuzzing in-house
- Re-test included
Fixed-fee engagement
BLE and RF penetration testing: deliverables, inputs, and exclusions
Included work is defined in the signed proposal. These scope options are not automatic inclusions in every engagement.
Fixed-fee deliverables
- Agreed BLE pairing/GATT, Wi-Fi, NFC/RFID, or proprietary RF capture, replay, and protocol-abuse tests.
- A Penetration Test Plan, Test Cases, and Test Report for the agreed attack surface and product versions.
- Documented findings, reproduction evidence, and remediation recommendations. Clean test cases and agreed retest evidence. Device tests trace to documented threats. They distinguish security impact from manufacturer-supplied patient-harm context.
Required inputs
- Device samples, radio/protocol specifications, pairing modes, firmware versions, antenna/test setup, and permission for the agreed RF activities.
- Written authorization, rules of engagement, in-scope targets and versions, test windows, and an escalation contact.
- Test accounts, environment access, architecture and data-flow information, and known access restrictions. Device work also needs intended use, available threat model, and ISO 14971 hazard context.
Exclusions and separate work
- Unlisted targets, production disruption, destructive hardware work, and third-party systems without authorization are excluded. Additional interfaces require agreement.
- SBOM generation, SAST, threat-model creation, and architecture views are separate unless explicitly bundled. A targeted test is not whole-device coverage.
- General software verification and validation, clinical performance testing, and full QMS implementation or certification are outside Blue Goat's product cybersecurity scope.
- The manufacturer retains engineering changes, clinical-risk evaluation, risk acceptance, release approval, and regulatory submission decisions. No regulatory outcome is promised.
Pricing and scope changes
A written fixed-fee quote after scoping. The proposal names deliverables, versions, assumptions, required inputs, exclusions, and agreed dates. Additional work requires a separately agreed scope change. Missing inputs, access restrictions, manufacturer fixes, and review feedback can affect delivery.
FDA guidance: Cybersecurity Testing, Section C
Cybersecurity testing beyond standard software V&V
The FDA recommends cybersecurity testing in a security context, beyond standard software verification and validation. Security testing documentation and associated reports or assessments should be included in the premarket submission. Penetration testing is one part of this evidence, not a substitute for every testing activity.
The manufacturer retains design verification and validation procedures under ISO 13485 Subclauses 7.3.6 and 7.3.7, design input and output review, fixes, risk acceptance, and release decisions. Blue Goat provides scoped cybersecurity testing and evidence, not general software V&V or software validation services.
Security requirements and boundaries
The FDA recommends evidence that each security design input was implemented successfully, plus boundary analysis and the rationale for boundary assumptions. Our agreed test cases connect applicable security requirements, threats, expected secure behavior, and actual results. Exclusions and untested requirements remain visible.
Threat-mitigation effectiveness
Testing evidence should address risk controls represented in the Global System, Multi-Patient Harm, Updatability and Patchability, and Security Use Case security architecture views. The threat model and Threat Table are separate deliverables, linked to controls and test evidence. Review security-policy enforcement and, as appropriate, maximum-traffic performance, stability, and reliability. The proposal identifies included checks and other manufacturer evidence needed.
Vulnerability testing and analysis
Section C references ANSI/ISA 62443-4-1 and recommends considering the following testing and analysis evidence:
- Abuse or misuse cases, malformed and unexpected inputs, robustness, and fuzz testing.
- Attack surface analysis and vulnerability chaining.
- Closed-box known-vulnerability scanning.
- Software composition analysis of binary executable files.
- Static and dynamic code analysis, including hardcoded, default, easily guessed, or easily compromised credentials.
This is a guidance evidence checklist, not a promise that every method is included in standalone penetration testing. SAST, binary software composition analysis, SBOM work, and threat-model creation or rework are separate unless explicitly bundled. Other methods depend on agreed access, interfaces, risks, and scope. Automated scan output alone is not a penetration test.
Penetration-test evidence
Adversarial tests focus on discovering and exploiting product vulnerabilities to identify and characterize security-related issues. The FDA recommends providing penetration-test reports that include:
- Independence and technical expertise of testers.
- Scope of testing.
- Duration of testing.
- Testing methods employed.
- Test results, findings, and observations.
Our Test Plan, Test Cases, and Test Report connect scope, methods, requirements, threats, findings, clean results, limitations, and retests. Documented evidence does not establish regulatory acceptance or replace manufacturer review.
Source: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 3, 2026, Section C. Guidance recommendations are distinct from Section 524B statutory duties.
Why Generic Pen Testers Skip the Wireless Interface
Most penetration testing firms run nmap, nessus, and a Burp scan. None of those touch the actual radio. FDA's Feb 2026 guidance expects every interface to be exercised, and the wireless interface is where patient data leaves the device.
No SDR or RF Tooling
Without HackRF, Ubertooth, or a logic analyzer on hand, the tester literally cannot observe the protocol they're supposed to attack.
BLE GATT Treated as a Black Box
Generic firms enumerate services then stop. Real testing exercises every characteristic permission, pairing mode, and bonding edge case.
No Threat-Model Linkage
Findings arrive as a CSV of protocol oddities with no mapping to your AAMI TIR57 risk file, so reviewers can't trace the controls.
What We Actually Test
Scope is à la carte: pick the radios in your device. We bring the lab, the SDRs, and the protocol expertise.
Bluetooth Low Energy (BLE)
- Pairing mode review (Just Works, Passkey, OOB, Numeric Comparison)
- Bonding key storage and re-pairing abuse
- GATT service and characteristic permission audit
- MITM via active relay (Btlejack, GATTacker)
- Connection parameter abuse and DoS
- Privacy / address randomization validation
Wi-Fi & 802.11
- WPA2/WPA3 handshake capture and offline analysis
- EAP method enumeration (PEAP, TLS, TTLS) and rogue AP
- Association flooding, deauth, and Evil Twin scenarios
- Captive portal and provisioning flow review
- Hidden SSID and management frame abuse
Proprietary & Sub-GHz RF
- SDR capture (HackRF / LimeSDR / RTL-SDR) and demodulation
- Protocol reverse engineering from physical layer up
- Replay, jamming, and selective-jam scenarios
- Cryptographic primitive review (rolling code, AES-CCM)
- Fuzzing of identified protocol fields
NFC, RFID, & Cellular
- NFC tag clone, replay, and relay (Proxmark3)
- ISO 14443 / 15693 protocol abuse
- Cellular modem AT-command surface review
- SIM / eSIM provisioning flow inspection
Engagement Methodology
Four phases. Two to four weeks. Reviewer-ready evidence at the end.
- 01
Scoping & Threat Model Intake
We review your AAMI TIR57 threat model, architecture diagrams, and intended-use radios. We agree on test environment (lab device vs. on-site), credentials, and out-of-scope frequencies.
- 02
Lab Setup & Baseline Capture
We build a controlled RF environment using shielded enclosures where required, baseline normal protocol behavior, and confirm coverage of every radio in scope.
- 03
Active Testing & Exploitation
Manual protocol attacks across pairing, association, and data flows. SDR-based fuzzing of proprietary layers. Each finding reproduced with packet captures saved as evidence.
- 04
Reporting & Re-test for FDA Premarket Submissions
Findings mapped to your threat model, risk file, and the Feb 2026 FDA guidance. Re-test of remediated findings included until you pass.
Reviewer-ready deliverables in one engagement
Every engagement ships with documented artifacts, traceable, complete, and aligned with current guidance.
- BLE pairing, bonding, and GATT attribute testing
- Wi-Fi association, EAP, and rogue-AP scenarios
- Proprietary RF protocol fuzzing (sub-GHz, 2.4 GHz)
- NFC/RFID replay, relay, and clone attempts
- SDR-based capture, demod, and replay
- Findings mapped to threat model + AAMI TIR57 risk file
Pricing Guidance
Fixed-fee. We quote within 24 hours of a scoping call. Ranges below assume a single device under test in our lab.
Single Radio
Fixed fee after scoping
BLE-only wearable, single-protocol device, or a tightly-scoped retest of a previously assessed radio.
- 1 radio interface in depth
- Threat-model-aligned report
- One round of re-test
- AAMI TIR57 + FDA mapping
Multi-Radio
Fixed fee after scoping
Most connected devices: BLE + Wi-Fi, or BLE + proprietary RF, with a moderate GATT surface and OTA path.
- 2-3 radio interfaces
- GATT permission + pairing-mode matrix
- SDR capture and protocol RE
- Two rounds of re-test
Complex / Proprietary
Fixed fee after scoping
Devices with proprietary sub-GHz protocols, mesh networks, or multiple paired peripherals (e.g., surgical platforms, infusion ecosystems).
- Full protocol reverse engineering
- Custom fuzzer development
- Mesh / multi-peripheral scenarios
- Dedicated senior wireless lead
What drives the price
- Number of distinct radios in scope (BLE, Wi-Fi, RF, NFC, cellular)
- Whether the protocol is standards-based or proprietary
- Test environment (our lab, your lab, on-site at hospital)
- Need for shielded enclosure / FCC-controlled test conditions
- Depth of GATT surface (number of services and characteristics)
- Inclusion of OTA update path testing
Ranges are guidance only. Actual quotes are fixed-fee after a 30-minute scoping call.
BLE & RF Pen Testing FAQs
Cybersecurity alerts and guides
Goat's Weekly alerts
Medical device advisories and safety communications, with links to original sources. An alert is a reason to assess applicability, not proof that your device is affected.
Threat modeling, eSTAR 7.1, and SBOM evidence
Connect threats to controls and test evidence. Compare the CISA 2026 SBOM fields with the NTIA 2021 baseline the FDA still cites, plus its support fields. Guidance recommendations remain separate from statutory duties.
BLE & RF Penetration Testing - scoped, fixed-fee, built for FDA premarket submissions.
Targeted wireless interface testing for BLE, Wi-Fi, NFC, and proprietary RF protocols. The attack surface generic pen testers can't reach. Reviewer-ready evidence for FDA premarket and EU MDR submissions.