How a Smart Speaker Is Made: Mic Arrays, Wake Word Chips and Firmware

A smart speaker is a small networked computer built around a microphone array. An application system on chip (SoC) runs the operating system, radios and music; a separate low power audio path listens for the wake word; and only after the wake word fires does audio leave the house for a cloud speech service. It is assembled on surface mount lines, tuned in acoustic chambers, radio tested and authorised, flashed with signed firmware, then updated over the air for years.

This post goes one level deeper than our explainers on how MEMS microphones and wake words evolved and the Zigbee, Thread and Matter smart home stack. It follows a speaker from silicon to a boxed product: the boards, far-field processing, the wake word engine, the mute button as each maker documents it, factory tests, signed firmware, setup, voice data, the FTC's 2023 case and the rules makers now face. Where makers keep numbers private, we say so rather than guess.

Key takeaways

• Inside: an application SoC with RAM and flash, a low power DSP for the wake word, two to eight MEMS microphones, a class D amplifier and drivers, a Wi-Fi and Bluetooth combo radio, and on many recent models a Thread or Zigbee radio.
• Far-field pickup is signal processing: beamforming steers toward the talker, acoustic echo cancellation subtracts the speaker's own music, and noise suppression cleans what is left.
• The wake word runs locally. Amazon says an Echo detects it "without hearing your conversations"; Google says Nest devices send audio only when someone interacts with the Assistant or a feature needs it; Apple says Siri Settings show whether a request is processed on device.
• Amazon's help pages say the microphone off button on Echo, Echo Dot and Echo Show disconnects the microphones and lights a red indicator. Whether a mute cuts power, clock or only a software flag is a design choice.
• On 31 May 2023 the FTC and Department of Justice filed a COPPA complaint against Amazon over children's Alexa recordings; the proposed order included a $25 million civil penalty.
• UK PSTI rules apply since 29 April 2024. ETSI EN 303 645 V3.1.3 dates from September 2024. EU CRA reporting duties apply from 11 September 2026 and main duties from 11 December 2027. The FCC adopted Cyber Trust Mark rules in March 2024 and says it is still selecting a Lead Administrator.

From silicon and plastic to a boxed speaker in one table

Makers do not publish per-station yields, acoustic pass limits or calibration tolerances, so the table names the check at each stage rather than inventing numbers. Read the "firmware and keys" column if you care about security: it shows where software and secrets enter the device.

What is inside a smart speaker?

A current smart speaker usually has three or four boards: a main board with the SoC, memory and radios; a top board with microphones, buttons and an LED ring; and a power board or external adapter. The drivers sit lower in an enclosure shaped as much by acoustics as by looks.

The application SoC

The SoC resembles a streaming stick's chip: a few Arm cores, a memory controller, audio interfaces and, on display models, a GPU. It boots from mask ROM, loads a bootloader, then starts embedded Linux or a real time operating system. The voice client, music, smart home logic and update agent run here, so most security updates land here.

The low power audio path

Listening all day on the main cores would waste power, so designs use a DSP core inside the SoC that runs while the application cores idle, or a separate chip between microphones and SoC. It runs the front end processing and a small neural network that scores each slice of audio, and wakes the main system when the score crosses a threshold.

The MEMS microphone array

Each microphone is a micro-electromechanical system: a thin silicon diaphragm over a perforated backplate, forming a capacitor that changes as sound moves the diaphragm. An ASIC in the same package converts that into an analogue output or a digital pulse density modulated (PDM) stream, as a MEMS microphone maker's tutorial application note explains. The sound inlet sits on the top or bottom of the package, hence "top port" and "bottom port" parts. Sensitivity is specified at a reference pressure of 1 pascal, which is 94 dB SPL at 1 kHz, and the same note says tight sensitivity matching helps beamforming and noise cancelling in multi-microphone arrays.

Amplifier, drivers and radios

A class D amplifier runs efficiently from a small adapter; many speakers use a smart amplifier that senses driver voltage and current to limit excursion and heat. The driver is also the microphones' biggest problem: its sound reaches them far louder than any voice.

Wi-Fi carries the voice connection, music and updates; Bluetooth Low Energy carries setup. An IEEE 802.15.4 radio lets the speaker run Thread or Zigbee devices, on Thread as a border router. Each radio runs its own firmware, a separate supply chain from the operating system. Flash holds the images, calibration data and the factory device identity, ideally with the private key wrapped by a hardware key or held in a secure element.

How do far-field microphone arrays work?

A smart speaker has to hear you from across a room, over its own music, a television and reflections from every wall. It runs four stages on the multichannel signal before the wake word engine sees it.

Beamforming: steering by delay

Sound travels at about 343 metres per second at room temperature, so a voice from one side reaches the nearer microphone first. Delay each channel so sound from the talker's direction lines up, add the channels, and the voice adds coherently while sound from elsewhere partly cancels. That is delay and sum beamforming. Adaptive beamformers go further and continuously adjust weights to place nulls on loud interferers such as a television.

Worked example 1: the delay between two microphones. Two microphones 4 cm apart, talker in line with them (the worst case, called end fire):

• Time difference = 0.04 m divided by 343 m/s = about 117 microseconds.
• At 16 kHz sampling, one sample lasts 62.5 microseconds.
• The maximum delay is 117 divided by 62.5, about 1.9 samples.

So beamformers use fractional delay filters, a higher internal rate, or the frequency domain, where a delay is a phase shift per bin. It also shows why microphones must be matched in phase.

Worked example 2: how close the microphones must be. An array steers unambiguously only where the spacing is under half a wavelength; above that it suffers spatial aliasing.

• Wavelength = speed of sound divided by frequency. At 4 kHz, 343 divided by 4,000 = 8.6 cm; half is 4.3 cm.
• At 8 kHz, the top of the band for 16 kHz audio, half a wavelength is about 2.1 cm.
• For 4 cm spacing, aliasing starts at 343 divided by (2 times 0.04) = about 4,290 Hz.

That is acceptable for speech, and explains why designers keep spacings small or stop steering above that frequency.

Worked example 3: what extra microphones buy. For noise that is uncorrelated between microphones, such as their own self noise, ideal delay and sum improves signal to noise ratio by 10 times log10 of the microphone count:

• Two microphones: about 3.0 dB.
• Four: about 6.0 dB.
• Seven: 10 times log10(7) = about 8.5 dB.

Rooms give less, because television noise and reverberation are partly correlated between close microphones. Distance matters too: in free field, a talker moving from 1 m to 4 m loses 20 times log10(4) = about 12 dB at the speaker, which is why the later stages matter as much as the array.

Acoustic echo cancellation

When music is playing, the microphones hear it far louder than your voice. Acoustic echo cancellation (AEC) works because the speaker knows what it is playing: an adaptive filter models the path from amplifier, through driver, enclosure and room, back to each microphone, and subtracts the predicted echo. It must track a changing room and struggles with non-linear distortion from a driver pushed hard, one reason smart amplifiers that keep the driver linear help voice pickup.

Noise suppression and dereverberation

Noise suppression then attenuates steady background such as fans and traffic, dereverberation reduces late reflections, and gain control sets the level the recogniser expects. Many current designs use small neural networks for these stages.

Placing and tuning microphones in the enclosure

• Distance and isolation. Microphones sit at the top, far from the drivers, isolated from enclosure vibration.
• Gaskets and ports. Each microphone hears the room through its own gasketed port, not the inside of the enclosure.
• Geometry. A ring of six or seven performs the same in every direction; a short line suits a product against a wall.
• Tuning. Engineers measure the finished enclosure in an anechoic or semi-anechoic chamber, then set echo canceller lengths, beamformer parameters, equaliser curves and wake word thresholds for that mechanical design. A cheaper gasket or new grille can mean retuning.

How does on-device wake word detection work?

A wake word engine is a small classifier running continuously on the cleaned audio. A typical design turns each 10 to 30 millisecond frame into features, usually energies in mel spaced frequency bands, and feeds a sliding window of them into a small neural network that outputs the probability that the wake word just ended. The threshold trades false accepts (waking on television dialogue) against false rejects (ignoring a real request), tuned per product and language.

The engine keeps a short ring buffer. When it fires, the speaker connects to the cloud and streams audio from just before the wake word. Amazon's Alexa privacy hub lists Alexa, Amazon, Computer, Echo and Ziggy as wake words, so the device carries a model or model set for each.

What is processed locally and what goes to the cloud

Makers describe the split in their own words:

• Amazon says on its Alexa privacy hub that only after an Echo detects the wake word is Alexa listening to requests, that it detects the wake word "without hearing your conversations", and that light indicators show when Alexa is listening and sending a request to the cloud.
• Google commits on its Nest privacy page that a device "will only send audio to Google" when it detects someone interacting with the Assistant, for example by saying "Hey Google", or a feature needs it, and that a visual indicator such as flashing dots shows when the microphone is on and sending audio.
• Apple says Siri Settings indicate whether what you say is processed on device and not sent to Apple servers; otherwise audio goes to Apple servers. It says personalised speech recognition, which is how audio from a phone can enable Recognize My Voice on HomePod, is performed on device.

What the mute switch actually cuts

"Mute" can mean very different things in hardware:

The strongest designs drive the mute light from the same hardware signal that cuts power or clock, so the light cannot say "muted" while the microphones work, even if the operating system is compromised.

What each maker publicly says:

• Amazon's help page says that to "disconnect the microphones" on an Echo, Echo Dot or Echo Show you press the microphone off button; a red light appears and Alexa will not respond until you press it again. Its privacy hub lists a microphones and camera enable or disable button.
• Google's Nest commitments say "you can always turn the microphone off" but do not describe the circuit.
• Apple's Siri statement covers where audio is processed and stored, not a hardware switch; check the HomePod user guide for your model.

If you build speakers, put mute in hardware on the power or clock path and wire the indicator to the same signal. If you buy one, read the maker's wording: "disconnect" and "turn off" state intent, while only design documentation or a teardown shows the circuit.

How is a smart speaker manufactured and tested?

The physical build follows other consumer electronics, covered in our posts on how a smartphone is made and how a smartwatch is made. What is distinctive is how much of the testing is acoustic.

Surface mount assembly

Paste printing, placement, reflow and optical and X-ray inspection are standard. Bottom port microphones need a hole in the board under the port, and reflow must respect the microphone maker's limits, because flux or debris in the port hurts performance.

Board test, flashing and provisioning

Boards go onto a fixture that contacts test points, checks rails, runs a memory test, writes the factory firmware and boots it. This is usually where identity is created: the board generates or receives a key pair, the maker's manufacturing certificate authority issues a certificate, and serial number and MAC addresses are written. On secure boot designs the hash of the maker's signing key is burned into one-time programmable fuses and enforcement is switched on, after which the SoC refuses unsigned bootloaders. JTAG and the serial console are locked or disabled before the unit leaves, which matches ETSI EN 303 645's provision that unused interfaces be disabled.

Acoustic chamber tests

Finished units go into a test box or small anechoic chamber:

• Driver test. A sweep is played while a reference microphone measures response, distortion and "rub and buzz", the rattles from a rubbing voice coil or loose part.
• Microphone test. Reference speakers play tones and the unit records from each of its microphones, checking sensitivity, response and phase match across the array.
• Leak test. Sound inside the enclosure should not appear strongly at a microphone meant to hear only the room. A failure points to a bad gasket.
• Echo check. With music playing, the residual after echo cancellation is measured.

Makers do not publish pass limits, but the tests follow directly from the signal processing above.

RF calibration and FCC equipment authorisation

Each radio is calibrated for transmit power and frequency error, and the values are stored for the radio firmware to read at boot.

In the US, a speaker with Wi-Fi, Bluetooth and often Thread or Zigbee radios needs an FCC grant of certification. The FCC's ID search page explains that an FCC ID combines a grantee code of three or five characters, assigned permanently to the company, with a product code chosen by the grantee; that it usually appears on a label or, on products with a display, electronically; and that the rules "require that most devices be authorized before they can legally be imported or sold in the United States". The search returns the grant and its exhibits, which commonly include test reports, external photos and the user manual.

What firmware ships on a smart speaker?

A smart speaker carries at least six separate pieces of firmware, often from different suppliers.

Two points follow. The operating system image is a software supply chain of hundreds of open source packages: kernel, C library, audio stack, TLS libraries, parsers and codecs. And radio and DSP firmware are binary blobs the maker can ship but often cannot rebuild, so their fixes must come from the chip vendor.

Signed over the air updates

A secure update pipeline has four properties:

1. Signed images. Releases are signed with a private key held in a hardware security module and verified on the device before install. The U-Boot documentation explains why hashing alone is not enough: hashes protect against corruption but do "not prevent the substitution of one image for another". Signing the hash, with the public key stored in non-volatile storage on the device, closes that gap.
2. Verified boot. Boot ROM checks the bootloader against the fused key hash, the bootloader checks the kernel, and the kernel checks the root filesystem.
3. A/B partitions. The update goes to the inactive slot; the device switches on reboot and falls back if the new slot fails.
4. Anti-rollback. A monotonic counter in fuses or protected storage records the minimum security version, so an older, vulnerable signed image cannot be reinstalled.

U-Boot's signed FIT images are a common way to implement the first two on Linux speakers; the walkthrough below shows the commands.

How long updates last

Google's Nest commitments say it provides automatic, critical security updates "for at least 5 years" for its connected home devices, and UK PSTI rules now require every maker selling in the UK to publish a minimum security update period with an end date. Check the published period before you buy, and whether it runs from launch or from purchase.

How does setup and pairing work?

A new speaker does not know your Wi-Fi network or your account. Setup solves both, usually through a phone app.

Phone app and Bluetooth Low Energy provisioning

1. The speaker boots into setup mode and advertises over Bluetooth Low Energy (some designs create a temporary Wi-Fi access point instead).
2. The signed-in phone app finds it and connects.
3. App and speaker establish an encrypted session. A good scheme adds an application level key exchange bound to a secret the user can prove they hold, such as a code printed on the device.
4. The app sends the Wi-Fi name and password over that session.
5. The speaker joins Wi-Fi, authenticates to the maker's cloud with its factory certificate, and the cloud links it to the app's account, often using a one-time token passed in step 4.

Espressif's ESP-IDF unified provisioning documentation shows the options plainly: SoftAP or Bluetooth LE transports and three schemes: Security 0 with no encryption; Security 1 with a Curve25519 key exchange and AES-256-CTR, with or without a proof of possession string; and Security 2 with SRP6a key derivation and AES-256-GCM. The lesson for any maker is that "no encryption" and "no proof of possession" are both available choices.

Matter commissioning

Speakers that act as Matter controllers (commissioners), and sometimes as Matter devices, follow the Connectivity Standards Alliance's commissioning flow. Google's Matter developer primer lists the steps:

1. Discovery and onboarding payload. The new device advertises and provides an onboarding payload, usually the QR code or numeric setup code on its label.
2. PASE. The commissioner uses the passcode for Passcode Authenticated Session Establishment, setting up keys for the rest of commissioning.
3. Device attestation. The commissioner reads the Device Attestation Certificate (DAC) and Product Attestation Intermediate (PAI) certificate, which carry vendor ID, product ID and attestation public key, then sends a challenge the device signs with its attestation private key. The chain ends at a Product Attestation Authority (PAA), which the Alliance says ensures each certificate is legitimate; the Alliance's Distributed Compliance Ledger is its signed, multi-node record of device provenance and certification status.
4. Operational credentials. The device creates a unique operational key pair and returns a certificate signing request; the home's administrative domain issues a Node Operational Certificate (NOC), which the commissioner installs with the root certificate.
5. Network configuration. For Wi-Fi and Thread devices, the commissioner sends network credentials.
6. CASE. From then on, nodes authenticate with Certificate Authenticated Session Establishment, and the setup code is no longer needed.

The DAC and its private key are provisioned at the factory board test step.

What credentials a speaker holds

A configured speaker holds its factory key pair and certificate, account and linked service tokens, Wi-Fi passwords, Bluetooth pairing keys, and Thread credentials and Matter operational certificates if it is a hub.

ETSI EN 303 645 provision 5.4-1 says "sensitive security parameters in persistent storage shall be stored securely", and provision 5.11-1 requires that users can erase all their user data simply. A factory reset should wipe everything above except the factory identity; do one before you sell or recycle a speaker.

What voice data is kept, and how do you review and delete it?

What happens to a recording after the request is answered depends on the maker and your settings. From each maker's own pages:

• Amazon. The Alexa privacy hub points to controls to review and manage your chats with Alexa and your smart home device history, and to see and update which skills you have granted access to specific data.
• Google. Google says that when audio recordings are stored with your Google account you "can access, review, and delete your recordings at any time", and that it may use the text of an Assistant interaction for ad personalisation but not "the audio recording itself".
• Apple. Apple says that unless you opt in to Improve Siri and Dictation, "your audio data is not stored by Apple"; that Siri transcripts and request data are not used for a marketing profile and are never sold; and that you can delete on-device transcripts in Settings, Siri, Siri and Dictation History.

What the FTC required in 2023

On 31 May 2023 the FTC announced that the Department of Justice, on its behalf, had filed a complaint and proposed order against Amazon. According to the FTC, Amazon kept children's Alexa voice recordings indefinitely unless a parent asked for deletion, and even then failed to delete transcripts from all its databases, which the complaint said violated the COPPA Rule and deceived users about deletion. The FTC said retained recordings helped improve the Alexa algorithm and that Amazon lacked an effective system to honour deletion requests. These are the government's allegations; the FTC notes a stipulated order has the force of law once a judge approves it.

The proposed order, filed in the Western District of Washington, required:

• A $25 million civil penalty.
• Deletion of inactive children's accounts and certain voice recordings and geolocation information.
• A ban on using geolocation, voice and children's voice information subject to deletion requests to create or improve any data product.
• Notice to users about the action and about retention and deletion practices.
• A ban on misrepresenting privacy policies for that data, and a privacy program for geolocation information.

The FTC's case page lists the stipulated order as entered by the court in July 2023. The same day, the FTC announced a separate action against Ring, Amazon's home camera subsidiary. The lesson for makers is structural: deletion has to reach every copy, including transcripts, derived features and training sets.

What do the US Cyber Trust Mark, UK PSTI, ETSI EN 303 645 and the EU CRA require?

A speaker sold in all three markets needs a published support period, unique credentials, a vulnerability reporting route, secure updates and evidence of how the maker handles vulnerabilities in shipped components. Check the CRA's annexes for whether your category needs third party assessment.

Dated timeline

Step by step: inspect, check and harden a smart speaker

These steps are for owners, home lab users and the engineers who build speakers. None modify a device you do not own or bypass any security.

Step 1: Find the FCC ID and read the filing

Find "FCC ID" on the label or in the app and search it on the FCC's ID search. The grant lists the radios and frequency ranges, for example whether there is an 802.15.4 radio.

Step 2: Update the firmware and record the version

Note the software version in the companion app, update, and record the new version. Amazon's help pages include an Alexa device software versions page to compare against.

Step 3: Set privacy controls

Choose recording retention, delete history you do not want kept, and turn off unused features such as voice purchasing.

Step 4: Put the speaker on its own network segment

Speakers need the internet and your phones, not your laptops or NAS. Put them on an IoT VLAN or guest network. Casting and discovery use multicast DNS, so if phones and speakers sit on different subnets you need an mDNS reflector. A minimal sketch for a Linux router with nftables, where br-iot is the IoT bridge, br-lan the main LAN and wan0 the uplink:

# Allow the IoT segment out to the internet; block it from starting connections to the main LAN
nft add table inet filter
nft add chain inet filter forward '{ type filter hook forward priority 0; policy drop; }'
nft add rule inet filter forward ct state established,related accept
nft add rule inet filter forward iifname "br-lan" oifname "br-iot" accept
nft add rule inet filter forward iifname "br-iot" oifname "wan0" accept
# New connections from br-iot to br-lan fall through to the drop policy

Adapt interface names, check that casting still works, and keep a console open while changing firewall rules so you cannot lock yourself out.

Step 5: See what the speaker announces and where it connects

From a Linux machine on the same segment, list multicast DNS services:

# List all DNS-SD services, resolve them, and exit after the cache is dumped
avahi-browse --all --resolve --terminate

On macOS, dns-sd -B _services._dns-sd._udp local. lists service types. To see which names the speaker looks up, capture on the router interface that carries its traffic:

# Replace 192.168.20.31 with the speaker's address and br-iot with your interface
sudo tcpdump -ni br-iot 'src host 192.168.20.31 and udp port 53'

Expect lookups for voice, update, time and music services, then TLS on port 443. The point is knowing which services the device needs before writing firewall rules.

Step 6 (for makers): sign a FIT image with U-Boot

These commands follow the U-Boot FIT signature documentation and assume a fit.its source describing your kernel, device tree and a configuration with a signature node naming the key dev.

# Generate a 2048 bit RSA key and self-signed certificate (in production, keep the key in an HSM)
mkdir -p keys
openssl genpkey -algorithm RSA -out keys/dev.key \
    -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt

# Build and sign the FIT image, write the public key into the U-Boot control device tree,
# and mark it required (-r) so U-Boot refuses unsigned configurations
mkimage -f fit.its -K control.dtb -k keys -r image.fit

The documentation shows the resulting signature node with required = "conf" and algo = "sha256,rsa2048". Enable CONFIG_FIT_SIGNATURE and CONFIG_RSA (or CONFIG_ECDSA) and leave the legacy image format disabled. Before shipping, boot the signed image on a development board with the same configuration, then boot a deliberately modified copy and confirm it is refused. The bootloader itself must be verified by the boot ROM against the fused key hash, or an attacker can replace U-Boot and skip the check.

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

The operating system image is mostly open source, so each release should ship with a software bill of materials (SBOM) and licence notices. Both common embedded Linux build systems do this:

# Yocto Project: create-spdx is inherited by default through INHERIT_DISTRO.
# Building an image writes IMAGE-MACHINE.spdx.json under tmp/deploy/images/MACHINE/
bitbake core-image-minimal
ls tmp/deploy/images/*/*.spdx.json

# Buildroot: collect licences, sources and the package manifest for the configured image
make legal-info
ls output/legal-info/

The Yocto Project documentation notes the class can be removed with INHERIT_DISTRO:remove = "create-spdx", so check nobody has. Store the SBOM with each signed image so you can say which firmware versions ship a library named in an advisory, and record vendor version strings for radio and DSP blobs.

Step 8: Reset before you pass a speaker on

Use the maker's documented factory reset, then remove the device from your account. A speaker that is merely unplugged still holds Wi-Fi passwords, account tokens and Bluetooth pairings, which is why ETSI EN 303 645 has a data erasure provision.

Common mistakes

• Trusting a software driven indicator. If software drives the mute light, a software fault can make it wrong. Drive it from the hardware signal that cuts the microphones.
• Leaving factory debug open. A root serial console or unlocked JTAG on shipping units undoes signed updates. Lock them at the final software step and test production units.
• Signing updates but not the boot chain. A signed root filesystem checked by an unsigned bootloader is bypassed by replacing the bootloader.
• No anti-rollback. Without a minimum version, an old signed image with a known flaw stays a valid update forever.
• Setup with no proof of possession. BLE provisioning that anyone nearby can complete lets a neighbour claim the device.
• Forgetting radio firmware. Wi-Fi, Bluetooth and Thread firmware have their own advisories; track their versions.
• No firmware SBOM. Without a record of which open source versions went into each release, every advisory becomes manual archaeology.
• Partial deletion. The FTC's 2023 case turned on transcripts not deleted everywhere. Design deletion to reach derived data and training sets.
• No published support period. UK PSTI and ETSI EN 303 645 require it, and the Cyber Trust Mark registry is designed to show it.

FAQ

Is my smart speaker always listening?

The microphones are on and the wake word engine runs continuously on the device, but Amazon and Google say audio goes to the cloud only after the wake word or when a feature needs it, and Apple says Siri Settings show whether a request is processed on device or sent to its servers.

Does the mute button on a smart speaker really turn off the microphone?

It depends on the design. Amazon's help page says the Echo microphone off button disconnects the microphones and shows a red light. A strong design cuts power or clock in hardware and drives the indicator from the same signal; a weak one only sets a software flag.

What chip detects the wake word?

Usually a low power DSP core inside the main SoC, or a separate audio processor between the microphones and the SoC. It runs a small neural network on audio features and wakes the main processor when it detects the word.

How does a smart speaker hear me over loud music?

Acoustic echo cancellation. The speaker knows what it is playing, models how that sound reaches each microphone and subtracts it. Beamforming then focuses on your direction and noise suppression removes steady background.

Can I delete my smart speaker voice recordings?

Yes, with controls that vary by maker. Amazon's privacy hub points to controls for your Alexa history, Google lets you review and delete recordings stored with your account, and Apple says it does not store Siri audio unless you opt in to Improve Siri and Dictation.

What did the FTC do about Alexa voice recordings?

On 31 May 2023 the FTC and DOJ filed a COPPA complaint and proposed order against Amazon over children's Alexa recordings, with a $25 million civil penalty and deletion requirements. The order was entered in July 2023.

What is the FCC ID on a smart speaker?

It identifies the speaker's FCC grant of certification, combining a grantee code and a product code. Searching it shows the certified radios and the documents filed with the grant.

How long do smart speakers get security updates?

Each maker sets its own period. Google commits to automatic critical security updates for at least five years for its connected home devices, and UK PSTI rules require every maker selling in the UK to publish a minimum update period with an end date.

Where Safeguard fits, honestly

Safeguard does not analyse speaker hardware, scan firmware images, test acoustics, manage devices or generate hardware bills of materials, and its models are single purpose security models for software supply chain work. The fit is narrower and still real: a speaker maker ships a lot of software it builds itself. The companion app, the cloud services behind setup, accounts and updates, the container images those services run in, and the open source packages in the firmware build are all software supply chain. Safeguard can scan repositories, container images and SBOM files, such as the SPDX documents a Yocto Project build emits, match components against vulnerability databases, rank findings with reachability analysis, enforce policies and gates, and open fix pull requests when a fixed version exists. It does not help with radio or DSP blobs you cannot rebuild, the boot ROM, or factory key ceremonies.

Even after the hardware is finished, the software around a smart speaker keeps changing: every firmware release rebuilds hundreds of open source packages, and the companion app and cloud services pull new dependencies every week. The steps below apply to those open source components and container images, not to the binary blobs a chip vendor supplies.

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 in a repository; 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 your approval and pushes nothing. The same flow fits a speaker's companion app or the setup and account services behind it, which are ordinary application repositories.

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 then scans from the terminal. That suits a firmware team whose embedded Linux builds run on its own build hosts and who want the scan to run where the build runs, for example against the SBOM the build already emits.

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. If your team already asks Claude about its projects, the same conversation can look up which projects carry a vulnerable component when an advisory names a TLS library or audio codec your firmware or companion app depends on.

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.

For more on the devices around your speaker, see our posts on how a home router is made and IoT device security fundamentals.

Quick check

Sources

• Amazon, Turn Your Echo Device's Microphones On or Off
• Amazon, Alexa Privacy Hub
• Google Safety Center, Google Nest Security and Privacy Commitments
• Apple, Siri, Dictation and Privacy
• FTC, FTC and DOJ Charge Amazon with Violating Children's Privacy Law by Keeping Kids' Alexa Voice Recordings Forever and Undermining Parents' Deletion Requests (31 May 2023)
• FTC, Amazon.com (Alexa), U.S. v., case page
• FCC, FCC ID Search
• FCC, U.S. Cyber Trust Mark
• NIST, IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products (September 2022)
• NIST, IR 8425 full text (PDF)
• GOV.UK, The UK Product Security and Telecommunications Infrastructure (Product Security) regime
• ETSI, EN 303 645 deliverables directory
• ETSI, EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements
• European Commission, Cyber Resilience Act
• EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act)
• Connectivity Standards Alliance, Matter
• Connectivity Standards Alliance, Product Attestation Authorities
• Connectivity Standards Alliance, Distributed Compliance Ledger
• Google Home Developers, Matter primer: Commissioning
• STMicroelectronics, AN4426 Tutorial for MEMS microphones
• U-Boot documentation, FIT Signature Verification
• Espressif, ESP-IDF Programming Guide, Unified Provisioning
• Yocto Project documentation, Creating a Software Bill of Materials
• The Buildroot user manual

Last reviewed: 24 October 2026.