Hearing Devices cybersecurity.

• 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

• Device ↔ phone (BLE, MFi / ASHA / LE Audio)
• Phone ↔ cloud audiology platform (TLS, OAuth)
• Cloud ↔ audiologist remote-programming session (authenticated)
• Cloud ↔ EHR (HL7, FHIR where applicable)
• Manufacturing programmer ↔ device (key provisioning)

Do OTC hearing aids need a cyber package?

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.

How do you test the BLE programming interface vs. the audio path?

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.

What about the audiologist fitting software?

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.

Are cochlear and brain-stem implants treated like other implantables?

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.

How do you handle the patient companion mobile app?

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.

What's expected for OTC hearing aid labeling and IFU cyber content?

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.

How do you address tinnitus, hearing-screening, and rehab apps that integrate with the hearing aid?

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.

How do you handle accessory ecosystems (TV streamers, remote mics, chargers)?

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.

What standards stack applies to advanced/connected hearing devices?

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.

What postmarket plan applies under section 524B?

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.

How long does a hearing-device premarket cyber engagement typically take?

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 clearance guarantee.