How Wireless Earbuds Are Made: LE Audio Chips, Batteries and Firmware

A true wireless earbud is a tiny Bluetooth computer: an audio system on chip (SoC) with a radio and DSP, two to four MEMS microphones, a driver and a lithium-ion cell of a few tens of milliamp hours. The case adds a microcontroller, a bigger cell, a lid sensor and charging contacts. Both run signed firmware updated through the phone.

This post goes one level deeper than our explainers on Bluetooth versions from Classic to LE Audio, GATT, pairing and bonding and how a smartwatch is made. It follows a pair of earbuds from silicon and lithium to a sealed box: the parts, how two buds share one phone, noise cancellation with real numbers, cell certification, factory tests, firmware and updates, pairing keys and privacy, and the overlap with hearing aids. Makers keep most production limits private, so where a number is not published we say so instead of guessing.

Key takeaways

• Each bud holds a Bluetooth audio SoC with DSP cores, MEMS microphones, a driver, a small lithium-ion cell, an in-ear sensor, touch sensing and an antenna. The case has its own microcontroller, cell, charger, Hall sensor and contacts.
• With Classic audio, the phone streams to one bud, which relays or shares the audio with the other using vendor methods. LE Audio adds isochronous channels so the phone can send a separate, synchronised stream to each bud.
• The Bluetooth SIG says the Core Specification gained LE Isochronous Channels in December 2019 and the LC3 codec was released in September 2020. Android 13, released on 15 August 2022, added built-in LE Audio support with LC3 as the default codec.
• Noise cancellation races the speed of sound: sound crosses 1.5 cm in about 44 microseconds, so anti-noise runs in low latency hardware. Small timing errors decide how much noise is left, which is why cancellation is strongest at low frequencies.
• Cells are safety tested to IEC 62133-2 and, for US shipping, must be of a type proven to meet UN Manual of Tests and Criteria sub-section 38.3 under 49 CFR 173.185.
• The sealed-in battery usually sets the product's lifespan.
• Pairing creates the long term keys; Fast Pair style prompts add a model ID, an anti-spoofing key and account keys. Resolvable private addresses stop strangers tracking buds by address.
• The FDA's over the counter hearing aid rule took effect on 17 October 2022, and some earbuds now offer hearing aid features under it.

From silicon and lithium to boxed earbuds in one table

Makers do not publish yields or pass limits, so the table names the check at each stage. The "firmware and keys" column shows where software and secrets enter the product.

The keys that bind the buds to your phone do not exist when the box is sealed. They are created at first pairing and deleted by a factory reset.

What is inside a true wireless earbud and its case?

The Bluetooth audio SoC and its DSP

One package usually holds a 2.4 GHz radio, a link layer controller, application cores, one or more DSP cores, audio converters, power management and a battery charger, with flash on the die, stacked in the package or alongside. The controller keeps strict radio timing. The application core runs the Bluetooth host stack, sensors, touch and the update agent. The DSP runs codecs, equalisation, voice processing and the adaptive parts of noise cancellation. Many audio SoCs also carry a dedicated low latency filter path for noise cancellation, because, as the worked example below shows, block based DSP code is far too slow for that loop. Some makers use a system in package module that bundles the SoC, memory and antenna matching to save space and simplify radio certification.

MEMS microphones

A noise cancelling bud typically has an outer feedforward microphone that hears ambient noise first, an inner feedback microphone near the driver that hears what is left in the ear canal, and one or two voice microphones aimed at the mouth. A MEMS microphone is a silicon diaphragm and backplate forming a capacitor plus a converter chip; most output a megahertz rate pulse density modulated (PDM) stream that the SoC filters down. Every port needs a mesh against water, wax and wind, and the meshes shape the response, so they are part of the acoustic design. Some buds add a voice accelerometer that senses skull vibration when the wearer speaks.

The driver: dynamic or balanced armature

True wireless buds mostly use a single dynamic driver because space is scarce. A small mesh covered vent stops the sealed ear from sounding boomy, and the ear tip completes the acoustic system, which is why poor fit ruins both bass and noise cancellation.

The cell and the case

The bud's cell is a small lithium-ion coin or pin cell of tens of milliamp hours, with a protection circuit that cuts off on over charge, over discharge, over current and short circuit. The case carries a larger cell of a few hundred milliamp hours and a charger. Its microcontroller manages charging, the light and button, and talks to the buds. A Hall effect sensor detects the lid magnet: opening the lid wakes the buds, which often triggers the phone's pairing pop up. Magnets pull the buds onto spring or pogo contacts that carry power and, on many designs, a slow data link for battery state and commands such as factory reset. Some cases add wireless charging or their own radio so the case can be located.

Antenna and sensors

The antenna is a board trace, a ceramic part or a pattern on the inside of the shell. The head absorbs 2.4 GHz energy, so the design problem is reaching the other ear and a phone in a pocket. Other sensors include an optical or capacitive in ear detector, touch or pressure controls, and an accelerometer for taps, head tracking or voice detection.

How do two earbuds share one Bluetooth connection?

Classic Bluetooth audio, through the A2DP profile, assumed one phone sending one stereo stream to one device. Two separate buds needed workarounds.

Relay and vendor sharing

The first approach was relay: the phone connects to a primary bud, which keeps its channel and forwards the other to the secondary bud. It works with any phone, but the primary drains faster, the forwarding link must pass through the head and the hop adds latency. Chip makers then developed ways for the secondary bud to listen directly to the phone's packets using link information the primary shares, asking its partner for any it missed. The phone still sees one device. These methods are proprietary and differ between chip families, and most buds can swap which side is primary when one battery runs low.

LE Audio: isochronous channels and multi-stream

LE Audio puts the solution in the standard. The SIG's LE Audio specifications page says the Core Specification "was enhanced in December 2019" with LE Isochronous Channels, and the SIG's Core 5.2 feature overview is dated 6 January 2020. Isochronous channels carry time bound data: a packet that misses its deadline is dropped rather than delayed, and receivers render audio at a shared synchronisation point. Connected isochronous streams link a phone to specific devices, so a phone can open one stream to each bud, timed to play together. Broadcast isochronous streams go from one transmitter to any number of receivers without a connection, the basis of Auracast.

The SIG says Multi-Stream Audio enables "multiple, independent, synchronized audio streams" and names true wireless earbuds as a main beneficiary, with better stereo imaging and smoother switching between sources. Neither bud forwards audio, so battery drain evens out.

Above the Core sit the Generic Audio Framework specifications. The SIG lists the Basic Audio Profile (BAP), Published Audio Capabilities Service (PACS), Audio Stream Control Service (ASCS) and Broadcast Audio Scan Service (BASS) for streams; the Common Audio Profile (CAP); the Coordinated Set Identification Profile and Service (CSIP and CSIS), which tell a phone that two buds are one set; the Telephony and Media Audio Profile (TMAP); and the Hearing Access Profile and Service (HAP and HAS).

LC3: the codec

The SIG describes Low Complexity Communication Codec 1.0 as "an efficient codec for audio applications, including hearing aid applications, speech, and music," supporting 7.5 ms and 10 ms frames. Its LE Audio page reports listening tests in which LC3 beat Classic Audio's SBC codec "even at a 50% lower bit rate," savings makers can spend on battery life or a smaller cell.

The frame arithmetic is simple. At 48 kHz and 10 ms, a frame holds 480 samples per channel; at 96 kbit/s that frame is 960 bits, or 120 bytes. At 16 kHz voice and 32 kbit/s, a 10 ms frame is 40 bytes. The frame length is also a latency floor: the encoder cannot send a frame until it has 10 ms of audio.

Android's developer guide says Android 13 (API level 33) includes built-in LE Audio support, that LC3 "is the default audio codec" replacing SBC for media and mSBC for voice, and that most LE Audio headsets will be dual mode, keeping Classic audio, until LE Audio phones are widespread.

Auracast broadcast

Auracast is the SIG's name for consumer broadcast audio. The SIG says one transmitter can share audio with unlimited devices without pairing, joined by picking from a list, scanning a QR code or tapping. Uses include sharing music, hearing a silent gym or airport television and assistive listening in venues. Android's guide asks transmitters not to stream silence between public announcements, because it wastes listeners' battery and blocks their own audio.

A dated timeline

Classic Audio versus LE Audio for earbuds

How do active noise cancellation, transparency and voice pickup work?

Feedforward, feedback and hybrid noise cancellation

Active noise cancellation (ANC) plays the inverse of the noise so the two nearly cancel at the eardrum. Feedforward uses the outer microphone to predict the noise after it passes the bud and plays the inverse; it covers a wide band but cannot see its own errors. Feedback uses the inner microphone and drives what is left towards zero; it corrects for fit but is limited by loop stability and must subtract the music so it does not cancel it. Hybrid designs use both, and adaptive ANC retunes the filters as fit and noise change. The ear tip seal does most of the work at high frequencies; ANC does most of it at low frequencies.

Worked example 1: the latency budget

Sound travels at about 343 metres per second. If the feedforward microphone sits 15 mm from the driver's port, the noise takes 0.015 / 343, about 44 microseconds, to arrive. An LC3 frame is 10,000 microseconds, more than 200 times longer. So ANC filters run in dedicated low latency hardware at high internal sample rates, fed straight from the PDM microphones, not in codec frames.

Worked example 2: how much noise a timing error leaves

If the anti-noise is right in level but off in phase by φ, the residual is 2 × sin(φ/2). A timing error τ gives φ = 360 × f × τ degrees at frequency f. For τ = 20 microseconds:

Cancellation is 20 × log10 of the residual with the sign flipped. The same 20 microseconds that is harmless at 100 Hz leaves most of the noise at 3 kHz. Level errors matter too: a 1 dB gain error (a factor of 1.122) with perfect timing leaves 0.122, about 18 dB of cancellation. That is why engine drone nearly vanishes while voices only drop, and why a loose tip, which shifts both gain and phase, ruins the effect.

Transparency mode

Transparency plays the outside world back into the ear. The outer microphones capture sound, the DSP equalises it to undo the seal and the bud's shape, and the result is mixed with media. It needs the same low latency path as ANC, because a delayed copy of a voice that also leaks past the tip sounds hollow. Some makers add compression for sudden loud sounds; hearing features build on this path with frequency dependent gain.

Voice pickup: beamforming and bone conduction

Two voice microphones along the stem hear the wearer's voice at slightly different times. Delay one and add it to the other, and sound from the mouth adds up while sound from other directions partly cancels.

Worked example 3: with microphones 15 mm apart along the line to the mouth, the largest delay is 0.015 / 343, about 44 microseconds. At a 16 kHz voice sample rate one sample is 62.5 microseconds, so the steering delay is less than a sample, and beamformers use fractional delay filters or work at a higher rate before decimation. Spatial aliasing starts where spacing exceeds half a wavelength, at 343 / (2 × 0.015), about 11.4 kHz, above the voice band.

Wind is turbulence at each port and differs between microphones, so a beamformer cannot cancel it like a distant talker. Designs counter it with meshes, port placement, switching to the least affected microphone and voice accelerometers. The accelerometer is immune to wind but carries mostly low frequencies, so it detects when the wearer speaks and fills the lower band rather than replacing the microphones.

How are the tiny cells made and certified?

Making a small lithium-ion cell

Our post on how lithium-ion batteries are made covers chemistry and cell making. Earbud cells use the same layers as a phone cell: a cathode on aluminium foil, a graphite anode on copper foil, a separator and liquid electrolyte, stacked or wound, put in a steel can, filled and sealed by crimping or laser welding. They are then formed, charged slowly the first time so a stable layer grows on the anode, and aged so high self discharge cells can be rejected. With so little margin, a burr or a speck of metal can cause an internal short, which is why earbud cells are sourced as qualified parts.

IEC 62133-2: safety tests

The IEC webstore says IEC 62133-2:2017 specifies "requirements and tests for the safe operation of portable sealed secondary lithium cells and batteries" under intended use and reasonably foreseeable misuse. Edition 1.0 was published on 7 February 2017, replacing IEC 62133:2012 for lithium systems, and a consolidated version with Amendment 1 of 2021 is sold as IEC 62133-2:2017+AMD1:2021. The text is sold, so read the standard or a laboratory's report for the exact clauses.

UN 38.3: transport tests

Section 173.185 of Title 49 of the US Code of Federal Regulations says each lithium cell or battery "must be of the type proven to meet the criteria" in part III, sub-section 38.3 of the UN Manual of Tests and Criteria, and that batteries are subject to those tests even if their cells were tested. The UN tests simulate transport conditions such as altitude, temperature changes, vibration, shock, external short circuit, impact and charging abuse. Earbuds ship with cells installed in equipment, which has its own packaging and marking rules in the same section.

Why the battery sets the earbud's lifespan

Lithium-ion cells lose capacity with cycling and with time spent full and warm, and earbuds are recharged every time they go back in the case. Worked example 4 uses illustrative numbers, not any product's specifications: a 50 mAh bud cell and 8 mA average playback current.

• New runtime: 50 / 8 = 6.25 hours.
• At 80 percent capacity: 40 / 8 = 5 hours.
• Three hours a day is 0.48 equivalent full cycles a day, about 175 a year.
• If a datasheet rated the cell to keep 80 percent after 500 cycles, the buds would reach that in about 500 / 175 = 2.9 years, sooner if stored hot and full.

A 500 mAh case cell at 70 percent charging efficiency delivers about 350 mAh, or 3.5 recharges of two 50 mAh buds. Because the cells are glued or welded into sealed shells for water resistance and space, worn cells usually end the product even though the electronics are fine. Optimised charging, which holds the cell below full until you usually need it, slows the wear. Check the maker's support pages for battery service.

How are earbuds assembled and tested?

Surface mount assembly on rigid flex boards

Earbud boards are dense and often fold. Rigid flex boards join rigid sections that carry chips with flexible polyimide sections that wrap around the cell and driver. Assembly follows the process in our printed circuit board post: paste printing, pick and place, reflow, then optical and X-ray inspection of the fine pitch ball grid arrays. Flex sections ride on carriers to stay flat.

Board test, flashing and RF calibration

A fixture powers each board, checks rails and current, and writes the first firmware through a test interface. This is where the bootloader, application, Bluetooth device address and serial number go in and where, on chips that support it, secure boot is enabled by writing a hash of the maker's public key into fuses and locking the debug port. A station that leaves debug open or ships a development key undoes every later protection. Each radio's crystal is then trimmed and its power and sensitivity checked in a shielded box, with values stored in flash or one time programmable memory. Over the air tests on finished buds follow, because the shell, cell and head change how the antenna behaves.

Acoustic and seal tests

Finished buds go on an ear simulator with a reference microphone. Sweeps check frequency response against a tolerance mask, then distortion and rub and buzz. A reference speaker tests the microphones, and played noise measures ANC depth. Leak tests confirm vents and volumes are sealed as designed, and pressure decay testers check water resistance without wetting each unit.

FCC equipment authorisation and Bluetooth qualification

In the United States, a Bluetooth earbud needs FCC equipment authorisation by certification before it is marketed. Under 47 CFR 2.907, certification is approved by the Commission or issued by a Telecommunication Certification Body "based on representations and test data submitted by the applicant," and covers later units identical to the tested sample apart from permitted changes. Under 47 CFR 2.925 the label carries the identifier preceded by "FCC ID," and the information may be provided electronically, which is why some earbuds show it in the app or on the case. Searching the FCC ID in the FCC's public equipment authorisation records shows the grant and the exhibits the maker filed, which often include photos. Separately, the Bluetooth SIG runs a qualification process, a public list of qualified products and an enforcement program for the Bluetooth name; a qualification listing shows which specifications a product claims.

What firmware runs in the buds and the case?

In the buds

The SoC carries several images: a boot ROM in silicon that verifies the next stage on chips with secure boot; a bootloader that selects, verifies and installs images; and the application, with a real time operating system, the Bluetooth host and LE Audio services, controller firmware for the link layer, DSP firmware for codecs, ANC, voice and hearing features, sensor logic and the update agent. Data areas hold tuning tables, calibration values and the pairing key store.

Each image contains open source and third party parts: a Bluetooth host that may be the chip maker's own, licensed, or based on an open source project such as Zephyr's; a crypto library; often an open source kernel; licensed codecs. Listing them with versions is a software bill of materials, and our post on whether a Wi-Fi or Bluetooth module blob belongs in your SBOM covers the binary parts.

In the case

The case MCU runs charging, lid, button and light logic and the protocol it speaks over the contacts, plus a Bluetooth stack on cases with a radio. It is usually updated through the buds: the phone sends the case image to a bud, which passes it on while docked.

Over the air updates through the phone app

The flow is similar across makers, though the protocols differ:

1. The app checks the maker's server for a newer package for the model.
2. It downloads the package, holding signed images for buds and case, over HTTPS.
3. It sends the images to the buds over Bluetooth in resumable chunks.
4. Each bud writes the image to a spare flash slot, not over the running one.
5. With both buds docked, they reboot; the bootloader verifies the signature and swaps or copies the image into place.
6. The new firmware tests itself and confirms; if it does not, the bootloader reverts.
7. The buds update the case and report versions to the app.

Most makers do not publish their signing schemes, so here is an open design. MCUboot, a secure bootloader used with Zephyr, documents the pattern. Its imgtool supports RSA 2048, RSA 3072, ECDSA P-256 and Ed25519 keys, creates them with keygen, exports the public key for the bootloader build with getpub, which needs no private key material, and adds the header and trailer the bootloader checks with sign. Its design document describes primary and secondary slots, upgrades by swap or overwrite chosen at build time, and downgrade prevention that requires a new image to carry a higher version or security counter.

Two points matter in any earbud scheme. Signature checks must happen in the bootloader against a key an attacker cannot replace; an app side check only stops corrupted downloads. And the bootloader should refuse older images with known flaws unless an authenticated downgrade is allowed.

How does pairing work?

Secure Simple Pairing and LE Secure Connections

Classic devices pair with Secure Simple Pairing; LE devices use LE pairing, ideally in LE Secure Connections mode. Both run an elliptic curve Diffie Hellman exchange and derive a long term key. With no screen or keypad, earbuds nearly always use the Just Works model, which gives no protection against an active attacker at the pairing moment. The window is short and needs someone nearby, but it is why pairing at home is safer than in a crowded place. Dual mode buds need bonds on both transports, ideally from one pairing so the phone shows a single device. Each side stores the bond: the long term key, the peer's identity address and, on LE, the key used to resolve private addresses. Buds keep bonds for a handful of phones and drop the oldest when full.

Fast Pair style phone prompts

Google's Fast Pair specification is public, so it serves as the example. It says the service uses Bluetooth LE to pair devices like headphones "with minimal user interaction." In pairing mode the headset, the Provider, advertises service UUID 0xFE2C with a 24 bit model ID at intervals no larger than 100 ms, and its LE address "shall not be rotated," so phones find it fast and can show the product's name and picture. In Key-based Pairing the Provider proves it holds an anti-spoofing private key registered for its model, while the phone, the Seeker, uses a fresh key pair for each attempt. After pairing the Seeker writes an account key to the Provider, tied to the user's Google account, and later pairings can prove possession of that account key instead.

Cross-device key sync

Outside pairing mode the Provider advertises account data, which the spec says "allows Seekers nearby to recognize when a provider belongs to their account" and pair without forcing the buds back into pairing mode. Other ecosystems tie similar features to their own accounts, and the details are not standardised, so check your phone maker's documentation. The convenience rests on a secret shared across your account: protect the account with strong authentication, and remember that a factory reset is what clears account keys from the buds.

Resolvable private addresses

A fixed radio address would let anyone with receivers along your route track you. The SIG explains that LE Privacy replaces the advertised address "with a random value that changes at timing intervals determined by the manufacturer," so observations look like different devices, while bonded devices share a key the SIG's post calls the Identity Resolution Key (IRK) to resolve the address back. The SIG notes these features date from Core 4.0, with changes in 4.2. Fast Pair shows the trade-off: in pairing mode the address is deliberately fixed, so buds are trackable for those minutes.

Where do earbuds overlap with hearing aids?

The FDA's over the counter category

On 17 August 2022 the FDA published a final rule (87 FR 50698), effective 17 October 2022, creating a category for over the counter hearing aids, repealing the old conditions for sale and updating labelling. The definition, now in 21 CFR 800.30, covers an air conduction hearing aid that needs no surgery and is "intended for use by a person age 18 or older" with perceived mild to moderate hearing impairment, sold without the involvement of a licensed person. It may use wireless technology and include self assessment tests. The building blocks match a noise cancelling earbud: outer microphones, a low latency DSP path, a driver and a fit test. The differences are regulation, output limits, labelling and clinical validation.

Hearing features in earbuds

Apple's support documentation says AirPods Pro 2 and AirPods Pro 3 "provide a clinical-grade Hearing Aid feature for perceived mild to moderate hearing loss," plus a Media Assist feature, and that setup needs the latest firmware. A firmware update that adds a regulated feature raises the stakes for update integrity. On the Bluetooth side, LE Audio includes HAP and HAS, and Auracast can carry venue audio straight to hearing devices.

What health data earbuds collect

It depends on the product, so read the maker's privacy documentation. Categories include hearing test results used to tune hearing features, listening level and exposure history, in ear detection and usage times, motion for head tracking or fitness, and on some models heart rate or temperature. Ask where it is stored, who can see it, and whether you can export and delete it.

Step by step: inspect, update and verify earbuds

These steps use BlueZ on Linux for inspection and open source tools for makers. On phones, use the maker's app and Bluetooth settings.

Step 1: Find the FCC ID and record the firmware version

Find "FCC ID" on the case, under the hinge, on the box or in the app, and search it in the FCC's equipment authorisation records. In the app, note the firmware version of each bud and the case, then update with the buds docked and charging, and turn on automatic updates if offered.

Step 2: Inspect the bond on Linux

# List paired devices
bluetoothctl devices Paired

# Show name, address type, services, bonded and trusted state
bluetoothctl info AA:BB:CC:DD:EE:FF

# Show the controller's own settings, including privacy
btmgmt info

LE Audio buds list the Published Audio Capabilities and Audio Stream Control services; Classic audio shows the A2DP and hands free profiles.

Step 3: Watch pairing happen

# Capture HCI traffic while pairing (needs root)
sudo btmon -w earbuds-pairing.btsnoop

The pairing request and response show IO capabilities and whether Secure Connections was used.

Step 4: Check whether the advertised address rotates

# Scan for LE advertisements for 20 seconds
timeout 20 bluetoothctl scan le

Run it a few hours apart with the buds out of the case and not in pairing mode. An address that never changes means no rotating private address on that transport.

Step 5: Remove a pairing safely

Warning: removing a device deletes its stored keys on this computer, and the buds must pair again. Check the address first.

# Confirm the exact device before removing it
bluetoothctl info AA:BB:CC:DD:EE:FF | head -5

# Remove only that device
bluetoothctl remove AA:BB:CC:DD:EE:FF

Step 6 (for makers): sign an image with MCUboot's imgtool

# Create a password protected signing key once and keep it offline
./scripts/imgtool.py keygen -k release-key.pem -t ecdsa-p256 -p

# Export only the public key for the bootloader build
./scripts/imgtool.py getpub -k release-key.pem > release_pub_key.c

# Sign with a version and a security counter
./scripts/imgtool.py sign --key release-key.pem \
  --header-size 0x200 --align 4 --slot-size 0x60000 \
  --version 2.1.0 --security-counter 7 \
  zephyr.bin zephyr.signed.bin

Header size, alignment and slot size must match your flash layout. Keep the private key in a hardware security module or offline, and sign in a release job.

Step 7 (for makers): test an update over Bluetooth

Zephyr's MCUmgr subsystem speaks the Simple Management Protocol over Bluetooth LE and serial, and Zephyr's documentation lists client tools from outside the project, such as mcumgr-client, smpmgr and AuTerm. On development units, upload the signed image to the secondary slot, list images to check the hash and version, mark it for a test boot, reset, and have the application confirm it; an unconfirmed image reverts on the next reset. Production buds should accept images only through the signed update path, with management services disabled or authenticated.

Step 8 (for makers): produce an SBOM for every firmware release

# Zephyr: set CONFIG_BUILD_OUTPUT_META=y in prj.conf first
west build -d build -b <board> app
# Emit SPDX documents (SPDX 2.3 by default) for that build
west spdx -d build

Zephyr's documentation says west spdx records the source files in the build with their licences and hashes. Store the SBOM with the signed image and version string, so an advisory naming a Bluetooth stack, crypto library or kernel version maps to your releases in minutes.

Step 9: Factory reset before you pass earbuds on

Warning: a factory reset deletes every pairing and account key on the buds. Check in the app that the serial numbers match the buds in your hand, then follow the maker's steps, usually holding the case button with the lid open, and remove the buds from your phone and your account's device list.

Common mistakes

• Treating the app's checksum as firmware security. Authenticity must be checked by the bootloader on the bud.
• Shipping development keys or open debug ports from the last factory station.
• Forgetting the case. Its MCU has its own firmware, update path and sometimes radio; it belongs in the threat model and the SBOM.
• Rotating the address but leaking identity elsewhere, such as a fixed name with a serial number or unchanging vendor advertising data.
• Assuming every phone supports LE Audio. That is why most LE Audio buds keep Classic audio.
• Pairing in crowded places, where Just Works offers no protection against an active attacker nearby.
• Passing buds on without a factory reset, leaving bonds and account keys behind.
• Storing buds full and hot, which ages the cell faster than any firmware choice.

FAQ

What chip is inside wireless earbuds?

A Bluetooth audio system on chip combining a 2.4 GHz radio, link layer controller, application cores, DSP cores for codecs and noise cancellation, audio converters, power management and a charger. The case has a separate small microcontroller.

How do both earbuds connect to one phone?

With Classic audio, the phone connects to one bud, which relays or shares the stream with the other. With LE Audio, the phone sends separate, synchronised isochronous streams to each bud.

What is LE Audio and do my earbuds support it?

LE Audio is Bluetooth audio over Low Energy, with the LC3 codec, multi-stream audio, hearing aid support and Auracast broadcast. Both buds and phone need it; on Android, built-in support arrived in Android 13. Check both makers' specifications.

What is Auracast?

The Bluetooth SIG's name for LE Audio broadcast. One transmitter sends audio to any number of receivers without pairing, joined from a list, a QR code or a tap.

How does noise cancelling work in earbuds?

Microphones measure noise and a fast filter plays an inverse wave so the two cancel at the ear. It works best at low frequencies; the ear tip seal blocks higher ones.

Why do earbud batteries die after a few years?

The cells lose capacity with every cycle and with time spent full and warm, earbuds are recharged constantly, and the cells are sealed inside.

Can wireless earbuds be tracked?

LE Privacy rotates the advertised address so strangers cannot follow one address, while your bonded phone resolves it. In pairing mode the address is often fixed, and other unchanging data can still identify a device.

How do earbud firmware updates work?

The app downloads a signed package and sends it to the buds over Bluetooth into a spare flash slot; the bootloader verifies it before swapping it in, and the buds then update the case.

Are earbuds hearing aids now?

Some earbuds include hearing aid features under the FDA's over the counter category, for people aged 18 or older with perceived mild to moderate hearing loss. The rule took effect on 17 October 2022.

What is an FCC ID on earbuds?

The identifier from the product's FCC equipment authorisation. Searching it in the FCC's records shows the grant and the exhibits the maker filed.

Where Safeguard fits, honestly

Safeguard does not analyse earbud hardware, cells, acoustics, radios or firmware binaries, and it does not manage devices. The fit is narrower. Companion apps, update servers and account services are ordinary software projects with open source dependencies, and firmware teams on open source stacks can emit an SBOM 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 (switched off by default). When an advisory names a Bluetooth stack, crypto library or kernel version, a team with SBOMs can see which apps and releases carry it.

Software supply chain hygiene still matters for earbuds because every update package carries open source components, from the Bluetooth stack and crypto library in the firmware to the networking and parsing libraries in the companion app. The section below applies to code your team builds and ships; firmware delivered as a chip maker'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: it installs the CLI, opens the interactive terminal and asks it 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 an earbud companion app or update service.

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 whose embedded builds run on its own hosts and who want to scan the SBOM where the 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. A team that already asks Claude about its projects can use the same conversation to find 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

• Bluetooth SIG, LE Audio
• Bluetooth SIG, LE Audio specifications
• Bluetooth SIG, Low Complexity Communication Codec 1.0
• Bluetooth SIG, Core Specification
• Bluetooth SIG, Bluetooth Core 5.2 feature overview (6 January 2020)
• Bluetooth SIG, Auracast broadcast audio
• Bluetooth SIG, Bluetooth technology protecting your privacy
• Bluetooth SIG, Qualify your product
• Android Developers, Bluetooth Low Energy Audio overview
• Android Developers Blog, Android 13 is in AOSP (15 August 2022)
• Google, Fast Pair specification: Introduction
• Google, Fast Pair specification: GATT characteristics
• Google, Fast Pair specification: Provider advertising signal
• IEC, IEC 62133-2:2017
• eCFR, 49 CFR 173.185 Lithium cells and batteries
• eCFR, 47 CFR 2.907 Certification
• eCFR, 47 CFR 2.925 Identification of equipment
• eCFR, 21 CFR 800.30 Over-the-counter hearing aid controls
• Federal Register, Establishing Over-the-Counter Hearing Aids (17 August 2022)
• GovInfo, Federal Register final rule text, 87 FR 50698
• Apple Support, Set up and use the Hearing Aid feature on your AirPods Pro 2 or AirPods Pro 3
• MCUboot, Bootloader design
• MCUboot, Image tool
• Zephyr Project, MCUmgr
• Zephyr Project, Software bill of materials: west spdx

Last reviewed: 24 October 2026.