How a Hearing Aid Is Made: DSP Chips, Batteries, Firmware and Bluetooth

A modern hearing aid is a very small, very low power computer. Two microphones feed a digital signal processing (DSP) chip that splits sound into frequency channels, applies gain fitted to the wearer's hearing, cancels feedback and reduces noise, then drives a miniature receiver (the industry's word for the loudspeaker). A zinc-air or lithium-ion cell powers it, and a 2.4 GHz radio links it to the other ear, to phones and, increasingly, to Bluetooth LE Audio and Auracast broadcasts.

This post follows a hearing aid from raw materials to a device fitted on an ear. It goes one level deeper than our builds of smartwatches and lithium-ion batteries: what is inside each style, how custom shells are printed, what the DSP actually computes (with numbers), how cells are chosen and charged, the four ways hearing aids stream audio, what the US over the counter rule changed, how firmware is updated and what the FDA expects from connected devices, and how to review what a companion app collects. Hearing aid makers keep most production details private, so where a figure is not published we say so, and where we use example numbers we label them as examples. Nothing here is medical advice; it describes devices and regulation.

Key takeaways

• A digital hearing aid is two microphones, a DSP system on chip, a balanced armature receiver and a cell; many add a telecoil and a 2.4 GHz radio.
• Styles (BTE, RIC, ITE, ITC, CIC) trade size against room for a big cell, a telecoil and an antenna.
• Custom shells go from ear impression or scan to a digital model to a printed shell; the model file also fixes the vent, which sets feedback margin.
• Fitting turns an audiogram into per channel gain with a prescription formula such as NAL-NL2, for wide dynamic range compression instruments.
• The FDA's OTC rule, published 17 August 2022 and effective 17 October 2022, caps OTC output at 111 dB SPL (117 dB SPL with input controlled compression), latency at 15 ms and self generated noise at 32 dBA, and puts labelling duties on app based "tools, tests, or software."
• Streaming routes are proprietary 2.4 GHz links, Made for iPhone hearing devices, Android ASHA (G.722 over Bluetooth LE) and LE Audio with the Hearing Access Profile and Auracast.
• Section 524B of the FD&C Act, added 29 December 2022, requires an SBOM and a postmarket patch plan for "cyber devices." FDA's premarket cybersecurity guidance was revised in February 2026.
• Review a companion app's permissions and data sharing before install and after updates.

From raw materials to a fitted hearing aid in one table

Hearing aid makers do not publish yields or pass limits. The table names the stage, where firmware and keys enter, and the typical check. The last two rows happen in a clinic or, for OTC devices, at home.

What is inside a modern hearing aid?

The NIDCD describes three basic parts: a microphone, an amplifier that "increases the power of the signals," and a speaker. Digital aids, in the NIDCD's words, "convert sound waves into numerical codes" first, which lets them amplify some frequencies more than others and favour sound from one direction.

Microphones

Most current aids carry two microphones a few millimetres apart. Combining them with a small delay forms a directional pattern in software (see below), so the pair is matched in sensitivity and phase at the factory. Port meshes keep out moisture, wax and wind, shape the response, and are serviceable parts.

The DSP system on chip

The core is a mixed signal chip: converters for the microphones, DSP cores with fixed function filter bank accelerators, a control processor, a class D style output stage for the receiver, power management and, on connected aids, a 2.4 GHz radio. The power budget is extreme, since the device runs all day from a cell of one to two volts. Memory holds the firmware, the fitting parameters, listening programs and data logs.

The receiver

Hearing aids generally use balanced armature receivers, in which an armature between magnets drives a diaphragm. They are small and efficient, and larger sizes give more output. In a BTE the receiver sits in the case and sound travels down a tube; in a RIC it sits in the canal on a thin wire, which shortens the acoustic path and lets the clinician swap receivers of different power.

Telecoil

The NIDCD describes a telecoil as "a small magnetic coil" that lets the user receive sound through the hearing aid's circuitry instead of its microphone. It picks up the magnetic field from compatible telephones and from induction loops in venues. The NIDCD notes canal aids have less space for components such as a telecoil, which is one reason style choice is a feature choice.

Battery and charging

Aids use either a replaceable zinc-air button cell or a sealed lithium-ion cell charged through contacts or a coil. The cell is often the largest part and sets the housing size; chemistry is covered below.

Antennas and the ear to ear link

The antenna has to fit in a few millimetres against tissue that absorbs 2.4 GHz energy, so designers fold it into the housing, battery door or flex circuit. The two aids also talk to each other for coordinated volume and program changes and, on many models, to share audio; makers use their own 2.4 GHz protocol or a short range magnetic link, rarely documented in detail.

How the styles differ

The NIDCD describes three basic styles and their use. The table adds the engineering consequence of each.

The NIDCD adds that canal aids "usually are not recommended" for young children or for people with severe to profound loss because their size limits power and volume. For the OTC category, the FDA's design rules also cap insertion depth, as we explain below.

How are custom shells made compared with standard housings?

There are two routes to the part you see.

Standard housings

BTE and RIC housings are moulded in standard sizes like any small consumer product, and the individual fit comes from the earpiece: a stock dome or a custom earmold. Standard housings suit high volume tooling, consistent sealing and easy servicing, and they suit OTC devices, which the wearer has to fit without a clinician.

Custom shells

ITE, ITC and CIC aids, and custom earmolds for BTE and RIC aids, are made per ear. A 2025 paper presented at the 3DBODY.TECH conference summarises the conventional route as "making physical ear impressions, shipping physical impressions to manufacturers, 3D scanning the ear impressions, digital sculpting, and shell fabrication and electronic assembly." In more detail:

1. Capture the ear. A clinician takes a silicone impression of the ear canal and outer ear, or captures a 3D scan of the ear directly.
2. Digitise. A physical impression is laser scanned into a 3D mesh. A direct scan skips this step.
3. Model. A technician uses modelling software to trim the mesh, set the canal length, add the vent channel, place the faceplate, and position the receiver, microphones and battery so they fit inside the wall thickness.
4. Fabricate. The shell is produced from the model, today usually by 3D printing in a resin suitable for skin contact, often many shells per build. Makers rarely publish the exact printing process or material, so treat any specific claim about them with care.
5. Post process. Printed parts are cleaned, finished and inspected, and may be coated.
6. Build and seal. The electronics module is placed, the faceplate is bonded, and the shell is ground and polished.

The digital model is the real product: it can be reprinted if a shell cracks, it fixes the vent size (see the feedback example), and it is patient data.

The same paper shows where the process may go next. Its authors describe "real-time mobile 3D scanning, cloud-based hearing aid shell modeling, and local office 3D printing," with an estimated ten minutes from scan to shell model in preliminary studies. That is a research result, not an industry standard, but it illustrates a shift worth noting: the ear scan, the shell model and the print job become files that move through cloud services, which brings them inside the same software and data protection questions as the companion app.

The OTC rule sets three relevant design requirements. The device must keep its innermost part "at least 10 millimeters (mm) from the tympanic membrane," the eartip material must be atraumatic, and the design must let consumers achieve a "safe, customized, acoustically favorable, and comfortable physical fit." That is why most OTC aids use domes and stock tips instead of deep custom shells.

What does the DSP do, and how is a device fitted to an audiogram?

The signal chain

A typical chain: the two microphones are digitised (makers rarely publish sample rates); directional processing combines them so front sound adds and rear sound partly cancels; a filter bank splits the signal into channels, from a handful to dozens; noise reduction lowers gain in channels that look like steady noise; wide dynamic range compression (WDRC) sets level dependent gain per channel; an adaptive feedback canceller subtracts the predicted leak from receiver to microphone; a limiter caps output; and the result drives the receiver.

All of it has to be fast. For OTC aids, 21 CFR 800.30 says "Latency shall not exceed 15 ms," measured to within 1.5 ms, and prescription aids must state latency in their labelling under 21 CFR 801.422. In an open fit, direct sound through the vent mixes with the processed sound. With a 5 ms delay, equal level copies would cancel first at 1 / (2 × 0.005) = 100 Hz and then every 200 Hz; at 15 ms the notches fall every 67 Hz. Real levels rarely match across the band, so the effect is partial, but it is why hearing aid DSP uses short filter banks and low latency paths.

Worked example 1: wide dynamic range compression

Suppose the fitting asks for 30 dB of gain at 2 kHz for soft speech, with a compression kneepoint at 50 dB SPL input and a 2:1 ratio above it. These are example values chosen to show the arithmetic, not a prescription.

A 50 dB range of input (40 to 90) becomes a 30 dB range of output (70 to 100). That squeeze is the point: soft sounds are lifted into the range the wearer can hear while loud sounds are not pushed past comfort. Attack and release times decide how quickly gain changes when a door slams; prescription aids must state them in labelling if they use automatic gain control, according to 21 CFR 801.422.

Worked example 2: checking the OTC output limit

The OTC rule defines output limit as the maximum output in an acoustic coupler with a 90 dB SPL pure tone input and gain at full on, which is the OSPL90 figure the brochure must list. Suppose an OTC design measures, at full volume:

With compression off, the 2.5 kHz peak is 3 dB over the 111 dB SPL limit and the device fails. With input controlled compression active the limit is 117 dB SPL, so it passes with 3 dB to spare. The rule also caps total harmonic distortion plus noise at 5 percent and self generated noise at 32 dBA, and requires bandwidth from 250 Hz or below to 5 kHz or above. Limiter settings and compression state are firmware parameters, which is one reason the integrity of fitting data and updates matters.

Worked example 3: feedback margin and the vent

Feedback happens when sound from the receiver leaks back to the microphone and the loop gain reaches 0 dB. Suppose the leak path from receiver to microphone attenuates sound by 40 dB at 3 kHz through a 2 mm vent (an example value; real paths are measured per fitting). Any gain above about 40 dB at 3 kHz risks oscillation, and in practice designers keep several decibels of margin. If the prescription calls for 38 dB at 3 kHz, the margin is only 2 dB and a hat or a phone near the ear can tip it into whistling.

If the feedback canceller tracks the path well enough to add, say, 10 dB of stable gain, the margin becomes 12 dB. Otherwise the choices are a narrower vent (more occlusion) or less gain at 3 kHz (less audibility). That is why the vent in the shell file and the feedback calibration in the fitting software are linked.

Directional microphones and noise reduction

For directionality, delay the rear microphone's signal by the sound's travel time across the spacing and subtract it: rear sound cancels and front sound survives. Adaptive versions steer the null towards the loudest noise. The NIDCD notes researchers have studied the ear of the fly Ormia ochracea as a model for miniature directional microphones. Noise reduction exploits the fact that speech is strongly modulated at syllable rates while fan or road noise is steady; makers describe their own algorithms only in general terms.

Fitting a device to an audiogram

An audiogram records hearing thresholds in dB HL across standard frequencies. Fitting software turns it into target gains for soft, medium and loud inputs using a prescription formula. NAL describes NAL-NL2 as its second generation procedure for wide dynamic range compression instruments, aiming "at making speech intelligible and overall loudness comfortable," and offers it for integration into fitting software on Windows or mobile apps. Clinicians may then verify with real ear measurement, a probe microphone in the canal.

Clinic fitting usually runs inside an industry framework. HIMSA publishes the Noah software, with an audiogram module and a list of Noah compatible fitting products, and describes Noahlink Wireless as "a programming interface based on the Bluetooth Low Energy (BLE) standard" for wireless programming of BLE hearing instruments, with more than 100,000 units sold as of January 2026. The clinic PC, its fitting modules and a Bluetooth dongle are therefore part of the device's software supply chain.

OTC devices replace the clinic with "tools, tests, or software" that, under 21 CFR 800.30, let a lay user control the device and customise it to their hearing needs, typically an app with an in situ hearing test played through the aid itself.

Open source hearing aid platforms

Two open projects show the processing in code. openMHA, from the University of Oldenburg and partners, is "an open-source software platform for real-time audio signal processing, licensed under AGPL-3.0." The Tympan project publishes an Arduino and Teensy library for its "Open Source Hearing Aid" under the MIT licence. Neither is a commercial hearing aid, but both show how filter banks, compression and feedback management are structured, and that hearing code has dependencies, licences and versions like any other software.

How do zinc-air and rechargeable lithium-ion cells compare?

Zinc-air button cells

Zinc-air cells use oxygen from the air as a reactant, so they ship with a plastic tab over small air access holes. One maker's data sheet for the size 675 cell (IEC designation PR44) gives a nominal voltage of 1.4 volts and tells the user to "Remove and discard plastic tab covering air holes" to activate it. Once air is in, the cell keeps reacting and slowly drying out whether or not the aid is switched on, so a fresh cell left with the tab off loses capacity. Common hearing aid sizes are 10, 312, 13 and 675, smallest to largest, and the larger sizes go in larger aids with more power. Energy per volume is high for the size, which is why zinc-air dominated for decades.

Sealed lithium-ion cells

Rechargeable aids use a small lithium-ion cell sealed inside the housing, with a protection circuit and charge control on the board. The wearer drops the aids into a charger each night, which charges them through contacts or inductively. Advantages are convenience and no tiny cells to handle; trade-offs are that the cell ages, so capacity falls over years, and replacing it usually means a service visit.

Worked example 5: run time

These are example values, not a product's specifications.

Streaming is the expensive part, which is why codec and connection interval choices matter, and why prescription aids list "battery current drain" in their technical data under 21 CFR 801.422. OTC labelling must state the battery type and number, whether they are included, and expected battery life.

How rechargeable aids are certified

The cell and the finished device go through separate gates. Lithium-ion cells are type tested for safety to standards such as IEC 62133-2 and for transport to the UN Manual of Tests and Criteria section 38.3, the same gates we describe in how lithium-ion batteries are made. The IEC lists IEC 62133-2 as a safety standard for lithium systems, first published on 7 February 2017. The finished hearing aid, if wireless, falls under 21 CFR 874.3305. Its special controls require performance data showing "electromagnetic compatibility (EMC), electrical safety, and thermal safety," validation of safe exposure to non ionizing radiation, and validation of the wireless functions. The radio also needs equipment authorisation in each market.

How do hearing aids stream audio?

There are four families. Most current aids support more than one.

1. Proprietary 2.4 GHz links

Makers also run their own low power 2.4 GHz protocols for the ear to ear link and for accessories such as TV streamers, remote microphones and phone clips that relay Classic Bluetooth. Their security properties depend on each maker's design and are rarely published.

2. Made for iPhone hearing devices

Apple's support article describes Made for iPhone (MFi) hearing aids that let users "listen and talk" on an iPhone, iPad, Mac or Apple Vision Pro. Pairing starts in Settings, Accessibility, Hearing Devices, with "Pair MFi Hearing Device," and a new hearing device replaces any previously paired one. Apple lists typical ways to enter pairing mode: opening and closing the battery door, cycling the power switch, or lifting rechargeable aids out of the charger. Once connected, the Apple device can control microphone level and audio presets, and iPhone and iPad can turn on Live Listen. Apple publishes a list of MFi hearing devices with system requirements.

3. Android ASHA

Android's Audio Streaming for Hearing Aid (ASHA) specification uses "connection-oriented L2CAP channels (CoC) over Bluetooth Low Energy." The peripheral exposes a GATT service with characteristics including ReadOnlyProperties, AudioControlPoint, AudioStatusPoint, Volume and LE_PSM_OUT, the channel the phone uses to connect audio. The codec is G.722 at 16 kHz, 64 kbit/s. The spec says CoC links "must require encryption," devices must support an MTU and MPS of at least 167 bytes, 2M PHY is strongly recommended, and "The BLE long range PHY must not be used."

Worked example 6: why 167 bytes?

ASHA says an audio frame should match the connection interval in time, giving the example that "if the connection interval is 20 ms and sample rate is 16 kHz, then the audio frame must contain 320 samples." At G.722's 64 kbit/s, 20 ms of audio is 64,000 × 0.020 = 1,280 bits, or 160 bytes. The spec adds a sequence byte before each frame, so a frame is 161 bytes, which fits inside the 167 byte minimum MTU with room for the L2CAP framing. A device that negotiated a smaller MTU would have to fragment every frame, costing power and time.

4. Bluetooth LE Audio, the Hearing Access Profile and Auracast

The Bluetooth SIG says LE Audio "adds support for hearing aids" and introduces Auracast broadcast audio, with the LC3 codec, which the SIG says delivers better quality than the SBC codec "even at a 50% lower bit rate." The SIG's Hearing Access Profile (HAP) 1.0 defines requirements for interoperability "within the hearing aid ecosystem," covering audio streaming and remote control of the hearing aid over LE Audio, and the SIG says the Hearing Access Service "is used to identify hearing aids and to control hearing aid presets."

Android's developer documentation says Android 13 (API level 33) includes built-in LE Audio support, with LC3 as the default codec, and that HAP "offers users greater accessibility and usage than previous ASHA protocols," including using the hearing aid microphone during calls.

Auracast lets one source broadcast to "an unlimited number of audio sink devices." The SIG positions it as the next generation of assistive listening for venues, contrasting it with induction loops that have suffered from cost and quality limits. On 22 October 2026 the SIG reported that all five of the largest hearing aid makers, which it says account for about 90 percent of the global market, now offer hearing aids that support Auracast broadcast audio.

Streaming routes compared

Encryption and pairing

All of the standard routes rely on Bluetooth LE bonding and link layer encryption. ASHA states that CoC uses "the standard Bluetooth mechanisms for link layer encryption." Our GATT, pairing and bonding explainer covers what each pairing method protects against. The practical point for hearing aids is that they have no screen or keyboard, so there is no passkey to compare. Makers instead rely on proximity and on a short pairing window, which Apple's article describes as opening after the battery door closes, the power switch is cycled or rechargeable aids leave the charger.

What did the FDA's OTC hearing aid rule change?

Timeline

What it created

The rule created a category of OTC hearing aids defined in 21 CFR 800.30 as air conduction aids that need no surgery, are "intended for use by a person age 18 or older" with "perceived mild to moderate hearing impairment," and are available without "the supervision, prescription, or other order, involvement, or intervention of a licensed person." Aids that do not meet those conditions are prescription hearing aids.

What it requires in labelling

Outside the package: warnings against use under 18, symptoms of perceived mild to moderate loss, the availability of professional services, "red flag" conditions, contact details, the return policy, the marks "OTC" and "hearing aid," battery information, and whether a phone or other control platform is needed and how it connects. Inside: a brochure with warnings in a fixed order, eartip insertion instructions that respect the depth limit, instructions for the tools, tests or software, and the technical specifications (OSPL90, full on gain, distortion, self generated noise, latency and bandwidth). The brochure must also be downloadable "without site or customer registration."

What it requires for user adjustable software

This is the part that touches software teams. If the OTC software is distributed separately from the hearing aid, for example as an app, 21 CFR 800.30(c)(5) moves the labelling into the app. Before first use or before taking payment, the app must show compatibility and minimum operating requirements, any later fees including subscriptions or add on features, and the key outside package warnings. Before first use it must show the under 18 warning until the user acknowledges it. All of it must stay accessible afterwards, and if any of it changes, the changed labelling must be shown again until dismissed. So an app update that changes subscription terms, supported phones or warnings is also a labelling change.

The design rules add a user adjustable volume control, the insertion depth limit and the requirement that tools, tests or software let a lay user customise the device. Performance rules set the output, distortion, noise, latency and bandwidth limits from worked example 2.

How is hearing aid firmware updated, and what does the FDA expect for connected devices?

Update paths

Makers use one or more of three routes: the clinic's fitting software, connected by cable or a BLE programming interface, which checks the version during a fitting; the companion app, which downloads a package and sends it to each aid over Bluetooth LE, usually one ear at a time; and on some designs a charger or streaming accessory.

Whatever the route, the properties to look for match any small connected device: the bootloader verifies a signature against a key in protected memory before running new firmware, refuses unauthorised downgrades, leaves the aid on its old image if a transfer fails, and both ears end up on compatible versions. Makers rarely publish their update design, so ask for it during procurement. Our guide to designing medical device software updates has the full checklist.

Section 524B and cyber devices

Section 524B of the FD&C Act, codified at 21 U.S.C. 360n-2, applies to a "cyber device," defined as a device that includes software, has "the ability to connect to the internet," and has characteristics that "could be vulnerable to cybersecurity threats." A sponsor submitting a premarket submission for such a device must:

• submit a plan to "monitor, identify, and address" postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure;
• maintain processes that provide reasonable assurance the device and related systems are cybersecure, and make postmarket updates and patches available, on a reasonably justified regular cycle for known unacceptable vulnerabilities and "as soon as possible out of cycle" for critical ones;
• provide "a software bill of materials, including commercial, open-source, and off-the-shelf software components."

Whether a given aid is a cyber device depends on how it connects; an aid paired to an app that talks to the maker's cloud is the kind of system the definition describes, and "related systems" reaches the app and back end. 21 CFR 874.3305 exempts wireless air conduction hearing aids from 510(k) premarket notification, subject to the limits in 874.9, and 524B attaches to premarket submissions, so check the device's actual regulatory pathway.

FDA's premarket cybersecurity guidance

FDA's guidance page says the current version, dated February 2026, supersedes the final guidance issued on 27 June 2025 and also covers FDA's recommendations for section 524B cyber devices, spanning cybersecurity design, labelling and premarket documentation. Our post on cybersecurity labelling for medical devices explains what users should be told.

The software in a hearing aid system

What data do hearing aid companion apps collect?

It varies by product, so read the maker's privacy notice and the store disclosures. Common categories:

• Hearing test results from in app tests, used to set gain.
• Device settings and programs, including fitting parameters copied from a clinic.
• Usage logs such as hours worn, time per listening environment, volume changes and streaming time, which clinicians use to adjust fittings.
• Remote care data such as session records and messages, where a clinician can adjust the aids remotely.
• Bluetooth and location adjacent data. Scanning for Bluetooth devices can reveal location, which is why phone platforms gate it behind permissions.
• Account, crash and analytics data, depending on the app's software development kits.

Who holds the data matters: a clinic and a direct to consumer app maker may be under different privacy rules, so check the notice for who holds what.

How to review an app's permissions and data sharing

1. Before install, read the store's privacy disclosures (Google Play's data safety section, Apple's App Privacy details) and the maker's privacy notice. Check for data shared with third parties and whether you can delete data.
2. At install, grant Bluetooth permissions. Android's documentation says apps targeting Android 12 (API level 31) or higher can mark BLUETOOTH_SCAN neverForLocation to assert they never derive location from scans; such an app should not need location access.
3. After install, review permissions in system settings. Turn off microphone, contacts or location access the app does not need.
4. For remote care, ask the clinic which platform holds the session data and for how long.
5. On iOS, Apple's App Privacy Report (iOS 15.2 or later) shows how often apps access data such as location, camera and microphone, and their network activity.
6. When you stop using the aids, delete the account and data, and reset the aids before passing them on.

Step by step: inspect, update and verify a connected hearing aid

These steps are for owners, carers and IT teams in clinics or care homes, and none of them change the fitting. A factory reset removes pairings and may remove the fitting, so check with the clinician first.

1. Record what you have

Note the model, the serial number (OTC aids must carry it on the device), the firmware version shown in the app or fitting software, and the app version. Keep the brochure, which for OTC aids lists the technical specifications.

2. Check the phone's view of the aids

On Android with USB debugging enabled, list bonded devices and hearing aid profile state from a computer:

# Confirm exactly one device is attached before running anything
adb devices -l

# Bonded Bluetooth devices and profile state (read only)
adb shell dumpsys bluetooth_manager | grep -iE "bonded|hearing|asha|le audio|hap" | head -40

3. Review the companion app's permissions

# Replace the package name with the hearing aid app's package
PKG=com.example.hearingapp
adb shell dumpsys package "$PKG" | grep -E "permission|granted=true" | head -60

Revoke anything the app does not need:

adb shell pm revoke "$PKG" android.permission.ACCESS_FINE_LOCATION

If the app stops finding the aids after a revoke, it may genuinely need the permission on that Android version; restore it in system settings.

4. Update in the right order

Update the phone operating system, then the app, then both aids' firmware. Keep the aids charged and close to the phone, do not interrupt the transfer, and confirm both ears report the same version afterwards.

5. For maker and app teams: produce an SBOM per release

If you build the companion app, the update service or firmware on an open source stack, produce an SBOM for every release you ship and keep it with the release artefacts. Section 524B asks for one in premarket submissions for cyber devices.

# Companion app or back end repository
safeguard scan --dir .

# A container image for the update or remote care service
safeguard scan --image registry.example.com/hearing/update-service:2026.10.1

# An SBOM emitted by a firmware build (CycloneDX or SPDX)
safeguard scan --sbom build/firmware-sbom.cdx.json

# Results are written as JSON under ./output
ls output/

6. In CI, keep the SBOM with every release

Keep each SBOM with the build it describes so you can later answer "which releases carry this component" without rebuilding. This step keeps it with the workflow run; for long term retention, attach it to the release as well:

      - name: Keep the firmware SBOM with this build
        uses: actions/upload-artifact@v4
        with:
          name: firmware-sbom-${{ github.ref_name }}
          path: build/firmware-sbom.cdx.json

To stop known vulnerable versions shipping in the first place, add a gate. The Gold scan GitHub Action described below can fail a build on a known exploited vulnerability, on any known vulnerability, or never; take its input names and version tag from its README rather than from a blog post.

Common mistakes

• Treating the battery door as a power switch only. Apple lists opening and closing it as a typical way to enter pairing mode, so the aid may briefly be discoverable.
• Updating one ear. Mismatched firmware between ears can break binaural features. Update both and confirm the versions match.
• Assuming an earbud hearing feature and an OTC aid are regulated the same way. Check the product's own labelling for its regulatory status.
• Ignoring the app as part of the device. Under 21 CFR 800.30(c)(5), separately distributed OTC software carries labelling duties, and under section 524B the "related systems" wording reaches apps and back ends.
• Granting location and contacts by habit. An app that declares neverForLocation on Android 12 or later should not need location.
• Passing on used aids without a reset. Pairings, app accounts and sometimes usage logs stay with the device. OTC rules also require used or rebuilt aids to be declared as such and reprocessed.
• Shipping firmware without a release SBOM. When a Bluetooth stack or crypto library advisory lands, finding affected releases takes days instead of minutes.
• Assuming the vent is cosmetic. Vent size sets feedback margin and maximum stable gain.

FAQ

What are the main parts of a hearing aid?

A microphone (usually two), a DSP chip that does the amplification and processing, a receiver that plays sound into the ear, and a battery. Many also have a telecoil and a 2.4 GHz radio with an antenna.

What is the difference between a receiver in canal and a behind the ear hearing aid?

Both keep the electronics behind the ear. A BTE keeps the receiver in the case and sends sound down a tube; a RIC puts the receiver in the canal on a thin wire.

How are custom hearing aid shells made?

From an ear impression or a 3D ear scan. The impression is scanned, the shell is modelled in software with the vent and parts placed, then fabricated (today usually 3D printed), finished and fitted with the electronics.

Are rechargeable hearing aids better than ones with batteries?

Neither is better in general. Rechargeables avoid handling tiny cells, but their sealed cell ages and usually needs a service to replace; zinc-air cells are swapped every few days and sold everywhere.

Can hearing aids connect to Android phones?

Yes: through ASHA on supported aids, through LE Audio with the Hearing Access Profile on Android 13 and later, or through the maker's accessories. Check the maker's compatibility list for your phone.

What is Auracast and do hearing aids support it?

Auracast is LE Audio's broadcast feature: a venue or TV can stream to any number of compatible receivers. On 22 October 2026 the SIG reported that all five of the largest hearing aid makers offer aids that support it; check your model.

What is the maximum volume of an OTC hearing aid?

Under 21 CFR 800.30 an OTC aid must not exceed 111 dB SPL output at any frequency, or 117 dB SPL if input controlled compression is active, measured in a coupler with a 90 dB SPL input and gain at full on.

Do hearing aids need an SBOM?

Section 524B of the FD&C Act requires a software bill of materials in premarket submissions for devices that meet its "cyber device" definition. Whether a given hearing aid qualifies depends on its connectivity and regulatory pathway.

Where Safeguard fits, honestly

Safeguard does not analyse hearing aid hardware, acoustics, cells, radios or firmware binaries, does not generate hardware bills of materials, and does not manage devices. Its fit is in the software around the aid: companion apps, fitting modules, update services and remote care back ends, plus SBOMs that firmware teams on open source stacks emit per release. Safeguard scans repositories, container images and SBOM files, matches components against vulnerability databases, ranks findings with reachability analysis where it applies, and can open fix pull requests, which ship switched off by default. When an advisory names a Bluetooth host stack, crypto library or web framework, a team with SBOMs in Safeguard can see which apps, services and releases carry the affected version.

Software supply chain hygiene still matters for hearing aids because every firmware package and every app update ships open source components, and section 524B now asks for an SBOM and a patch plan for cyber devices. The section below applies to code your team builds and ships; firmware delivered as a chip vendor's binary still needs that vendor's fix.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow fits a hearing aid companion app or remote care back end.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That suits a firmware team scanning the SBOM on the host where its embedded build emits it.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use, so a device team can ask which projects carry a component named in a Bluetooth stack or crypto library advisory.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• NIDCD, Hearing Aids
• eCFR, 21 CFR 800.30 Over-the-counter hearing aid controls
• eCFR, 21 CFR 801.422 Prescription hearing aid labeling
• eCFR, 21 CFR 874.3305 Wireless air-conduction hearing aid
• Federal Register, Establishing Over-the-Counter Hearing Aids, final rule (17 August 2022)
• GovInfo, final rule text, 87 FR 50698
• Cornell LII, 21 U.S.C. 360n-2 Ensuring cybersecurity of devices (section 524B)
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
• Android Open Source Project, Hearing aid audio support using Bluetooth LE (ASHA)
• Android Developers, Bluetooth Low Energy Audio overview
• Apple Support, Use Made for iPhone hearing devices
• Bluetooth SIG, LE Audio
• Bluetooth SIG, LE Audio specifications
• Bluetooth SIG, Hearing Access Profile 1.0
• Bluetooth SIG, Hearing Access Service 1.0
• Bluetooth SIG, Auracast broadcast audio
• Bluetooth SIG, A new milestone for Auracast broadcast audio, and what it means for hearing aid users (22 October 2026)
• NAL, NAL-NL2
• HIMSA, Noahlink Wireless
• openMHA project
• openMHA source repository
• Tympan, Tympan_Library
• Yee et al., Mobile 3D Scanning Facilitated Custom-Fit Hearing Aid Shell Manufacturing Process, 3DBODY.TECH 2025
• Zinc air hearing aid cell size 675 (IEC PR44) data sheet
• IEC, IEC 62133-2:2017
• GovInfo, Public Law 115-52, FDA Reauthorization Act of 2017
• Android Developers, Bluetooth permissions
• Apple Support, About App Privacy Report
• Google Play Help, Data safety section

Last reviewed: 24 October 2026.