Typical clinical uses
- Behind-the-ear and in-the-ear hearing aids
- Cochlear implants and bone-anchored hearing systems
- OTC hearing aids and self-fit devices
- Tele-audiology / remote programming platforms
- Companion apps for patient control and adherence
Cybersecurity for hearing aids, cochlear implants, and OTC hearing.
BLE-connected hearing aids and cochlear implants are increasingly programmable from patient-facing apps. We secure the BLE link, mobile companion, and fitting workflow.
Hearing aids and cochlear implants are some of the highest-volume BLE-paired medical devices on the market. Phone-pairing security is foundational, and the move to OTC and tele-audiology adds new authenticated remote-write paths that must be modeled and tested.
Typical clinical uses
Key data flows & integrations
Audio-streaming and programming services on hearing devices need authentication and authorization separation.
Audiologist fitting software is a privileged client and a target for supply-chain attacks.
Hearing aids and cochlear systems pair to a phone over BLE for fitting, streaming, and adjustment. Fitting software and the cloud back-end carry as much risk as the device itself.
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
Hearing aids and cochlear implants are some of the highest-volume BLE-paired medical devices in the world. The cybersecurity history is dominated by BLE stack vulnerabilities and companion-app exposures.
Historical incidents
Disclosed flaws in BLE and Bluetooth Classic stacks across multiple silicon vendors directly affect any hearing device using affected chips, including patient apps and audiologist programming dongles.
CISA ICSMA-20-063-02BrakTooth disclosure, Aug 2021
Public advisories have addressed PHI handling and account-control issues in hearing-aid companion apps, illustrating that the patient app is in-scope for premarket cyber even when it is not the audiologist programming path.
Audiologist fitting software is a privileged client used by clinics worldwide. Supply-chain attacks on similar privileged clients (e.g., 3CX, SolarWinds) define the threat model reviewers expect to see addressed.
Active threat scenarios
If audio-streaming and programming services share a transport without authorization separation, audio peers can issue programming commands.
Account takeover exposes audiology profiles and, in remote-programming designs, device parameters.
Compromise of the audiologist client - or its update channel - compromises every device it is used to program.
Cloned or counterfeit accessories with weak authentication are a documented attack pattern in BLE peripherals.
What FDA reviewers cite
Hearing aids and cochlear implants are some of the highest-volume BLE-paired medical devices in market - phone-pairing security is foundational.
Tele-audiology adds a new authenticated remote-write path that must be modeled and tested as an attack surface.
Cochlear implants in service for 15+ years require crypto-agility planning, including post-quantum readiness.
OTC categories change the consumer-vs-medical risk profile and the documentation FDA expects.
What FDA scrutinizes
Tele-audiology adds a new authenticated remote-write path that must be modeled and tested as an attack surface.
OTC categories change the consumer-vs-medical risk profile and the documentation FDA expects.
Cochlear implants in service for 15+ years require crypto-agility planning, including post-quantum readiness.
Standards & deliverables
Six deliverables FDA and notified bodies expect across MedTech, with the hearing-specific wrinkle on each row. Use it as a scoping checklist before you brief vendors or your QA team.
Machine-readable SBOM (CycloneDX/SPDX) plus VEX feed for every CVE that touches a listed component.
Continuous CVE / advisory monitoring against the SBOM, with a documented triage and disclosure path.
Black/grey-box testing across device, wireless interfaces, mobile apps, cloud APIs, and service tooling.
STRIDE-per-interface threat model with documented mitigations and residual-risk acceptance.
Signed firmware/software updates with rollback protection, integrity verification, and staged rollout.
Public CVD policy, intake channel, and SLAs for triage, fix, and customer communication.
If they're connected and software-controlled - which nearly all modern OTC hearing aids are - then yes. The OTC Hearing Aid Final Rule and the associated special controls reference applicable FDA cybersecurity guidance, so the premarket package (threat model, SBOM, security testing, labeling content) applies. We tailor the depth to the actual connectivity surface so OTC submissions don't get over-scoped.
We separate audio-streaming services (typically LE Audio, ASHA, or vendor profiles) from programming/configuration services in the threat model and test them as distinct interfaces. Every programming command - whether issued by the audiologist's fitting software or the patient companion app - is verified for authentication, authorization, and replay resistance. Audio-only services are reviewed for DoS and downgrade behavior so a hostile peer can't drop the device into an insecure mode.
Fitting software is a privileged client with the ability to change clinically meaningful parameters, so it's treated as a connected system component. We review its software supply chain, code signing, update path, credential handling, and the protocol it uses to talk to the device, and we pen-test the entire path including any cloud-side configuration storage. Findings here are some of the highest-impact in the segment because a compromised fitting workstation can affect many patients.
Yes. Cochlear implants and auditory brainstem implants (ABIs) get the same expectations as other Class III active implantables: a full premarket cyber package, postmarket vulnerability management, a documented secure update path (often constrained by inductive or low-bandwidth RF), a CVD program, and a 10-15 year crypto-agility plan. The IEC 14971 risk file ties the cyber controls to specific patient hazards.
Standard mobile premarket package: OWASP MASVS L2 baseline, MSTG-driven test cases, secure storage of pairing material, TLS pinning, jailbreak/root detection where clinically justified, and authorization checks against both the device and any cloud APIs. Streaming and call audio paths are reviewed for confidentiality and integrity, especially when the app is also acting as a remote microphone.
The IFU should include cybersecurity content consistent with FDA premarket guidance: pairing instructions and what 'good' looks like, OTA update behavior and user actions, expected support lifetime, and a coordinated vulnerability disclosure point of contact. Hospital and audiology procurement reviewers also expect MDS2 alignment with the SPDF so claims don't contradict each other.
Companion clinical apps (tinnitus masking, auditory training, screening) are scoped as part of the connected system whenever they affect device behavior or generate clinical data. We test their API surface, authorization model, and data flows, and we make sure the threat model covers third-party integrations (e.g., audiology EHRs, telehealth platforms) as untrusted boundaries.
Each accessory that pairs with the hearing aid is enumerated as a system component with its own pairing flow, firmware update path, and trust boundary. We test pairing for impersonation and downgrade, exercise OTA on the accessory firmware, and verify that compromise of an accessory cannot escalate into programming-level access on the device. Accessories are a recurring source of audit findings because they're often built by sub-vendors with weaker baselines.
Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, IEC 62304, IEC 60601-1 with applicable particulars, ISO 14971, OWASP MASVS for the mobile app, and Bluetooth SIG profile-specific security requirements. EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16, and we map the same artifacts across both regimes.
Continuous SBOM monitoring on device firmware, fitting software, mobile app, and accessory firmware; a CVD intake with published acknowledgment and remediation SLAs; a controlled patching process through the QMS; and a secure update mechanism design that respects the device's bandwidth and battery constraints. We deliver the postmarket plan as part of the premarket package so it's ready for clearance.
For a connected OTC or prescription hearing aid with companion app and accessories, end-to-end premarket cyber work generally runs 6-10 weeks. Cochlear and ABI engagements run 10-16 weeks given the implant complexity and Class III expectations. Threat modeling and SBOM front-load, pen testing runs in the middle weeks, and the consolidated package closes in the final weeks - all under a written deficiency commitment.
BLE/wireless audio protocol testing, fitting software review, and SBOM for hearing devices.
"Blue Goat Cyber's depth of expertise was impressive. We had no in-house cybersecurity experience, and their team guided us through every step of the FDA process. The penetration testing and SBOM testing were thorough and gave us complete confidence."
Cybersecurity for hearing aids, cochlear implants, and OTC hearing.
