Microphones From Condenser to MEMS: Wake Words and Mic Privacy

Microphones went from carbon buttons to condenser capsules (Wente's 1917 paper), electret capsules (Sessler and West, 1962) and finally MEMS chips etched into silicon, which now sit in arrays of two or more in phones, laptops and smart speakers. Those arrays feed wake word detectors that run on small, low power processors and only send audio to the cloud after a trigger. Your protection comes in layers: per app permissions, on screen indicators on iOS, Android, macOS, Windows and the web, device wide mic toggles, and on some Apple hardware a microphone cutoff that software cannot override.

That is the short answer. The longer one matters because the microphone is the one sensor that is almost always on in some form, and the security story around it has three separate threads that rarely get told together. The first is the hardware itself, which changed shape and then changed again when it became a chip. The second is the software layer: who decides when audio leaves the device, and how you find out. The third is a decade of academic research showing that a microphone can be made to "hear" things no person in the room heard, using ultrasound or light. This post walks through all three, with dates and behaviour taken from standards documents, the operating system vendors' own documentation and the researchers' own abstracts.

If you have read our posts on Bluetooth versions and security history or USB and Thunderbolt evolution, this one fits beside them: a lot of microphones reach your computer over exactly those buses.

Key takeaways

• Four transducer families matter today: dynamic (induction in a moving coil), condenser (capacitance change with an external bias), electret (a condenser with a permanent charge) and MEMS (a condenser, or newer piezoelectric design, etched in silicon, often with a digital output).
• The USB Audio Device Class has four major releases, dated in the specification's own revision history: 1.0 (March 1998), 2.0 (May 2006), 3.0 (September 2016) and 4.0 (April 2023). The USB-IF posted an updated 4.0 package with errata and ECNs through 9 October 2026, and the 4.0 text says it supersedes 3.0 and is not backward compatible with earlier versions except through a defined compatibility mechanism.
• Wake words are detected on device. Apple's 2017 description of "Hey Siri" uses a small detector on the iPhone's Always On Processor, then a larger second pass, then a server side check. Amazon says Echo devices send no audio to the cloud unless they detect the wake word or a button press. Google says Nest devices send audio only when they detect an Assistant interaction or a feature that needs it.
• Every major platform now shows when the microphone is in use. iOS shows an orange indicator, macOS a Recording Indicator in Control Center, Android 12 and later a status bar icon and Quick Settings dialog, and Windows a microphone icon in the taskbar notification area. The W3C Media Capture spec requires browsers to signal mic use and keep any off to on change visible, ideally for at least 3 seconds.
• Apple's hardware microphone disconnect cuts the mic when a Mac laptop lid closes (Apple silicon and T2 laptops) or when an MFi case closes on iPads from 2020 onward. Apple says no software, even with kernel privileges, can turn the mic on in that state.
• DolphinAttack (ACM CCS 2017) showed commands modulated onto ultrasound could be demodulated by microphone circuit nonlinearity and acted on by assistants. Light Commands (USENIX Security 2020) showed MEMS microphones respond to modulated light, at distances up to 110 meters in the researchers' tests.
• The practical mitigations are the boring ones: a PIN or second factor for voice purchases and unlocks, the mute switch, assistants away from windows, periodic permission reviews, and apps that request the mic only when a user starts a voice feature.

The dated timeline

The rows below come from primary sources where we could fetch them. Where only a secondary source carried a date, the source column says so.

A note on two dates. Many histories say Wente invented the condenser microphone in 1916; his paper in Physical Review is dated July 1917, so the work predates publication. Apple's hardware disconnect page carries a 2021 publication date, but the feature itself shipped earlier on T2 Mac laptops; Apple's page does not give a launch year, so we do not either.

How do dynamic, condenser, electret and MEMS microphones differ?

Every microphone turns tiny pressure changes in air into an electrical signal. The difference is the physics in the middle.

Dynamic (moving coil). A diaphragm is attached to a coil of wire that sits in a magnetic field. Sound moves the diaphragm, the coil moves, and electromagnetic induction produces a voltage. No external power is needed. Dynamic microphones are rugged and tolerate loud sources, which is why they still dominate stage vocals and many podcasting setups. They are large and comparatively insensitive, so they never fit inside a phone.

Condenser (capacitor). A thin, conductive diaphragm sits close to a fixed back plate. Together they form a capacitor. When sound moves the diaphragm, the gap changes, the capacitance changes, and with a fixed charge on the plates, the voltage changes. The charge has to come from somewhere, traditionally an external polarizing voltage (studio "phantom power" is the familiar form). Wente's 1917 paper described this design as a measurement instrument with uniform sensitivity, which is still why condensers are the reference for accurate recording.

Electret. Sessler and West's 1962 insight was to replace the external polarizing voltage with a permanently charged material, an electret, on the diaphragm or back plate. The capsule still behaves like a condenser, but it no longer needs a high polarizing voltage, only a small supply for its built in preamplifier. Electret capsules were cheap, small and good enough, and for roughly four decades they were the microphone in telephones, laptops, headsets and early mobile phones.

MEMS. A micro electro mechanical systems microphone etches the diaphragm and back plate directly into a silicon wafer. Most MEMS microphones are still condensers in principle. The package usually pairs the sensing element with a separate or integrated application specific chip that biases the element and amplifies its output. Digital MEMS microphones put the analog to digital conversion on that chip too, so the output is already a digital stream. Since the 2010s, piezoelectric MEMS microphones have also appeared, which sense strain in a piezoelectric film rather than a change in capacitance.

The transducer comparison table

The "security relevance" row is the reason this history belongs on a security blog. The closer the microphone gets to being a digital component, the more it shares with every other digital component: a driver, a firmware adjacent signal chain, and a software stack that decides what happens with its output.

Why did MEMS microphones take over phones and laptops?

Several engineering pressures pushed in the same direction at once.

Size and placement. Phones and laptops kept getting thinner while adding more microphones. A silicon die in a small package fits next to a speaker grille, in a hinge, or at the top edge of a display bezel where an electret capsule was awkward.

Manufacturing. MEMS packages can be placed by the same automated pick and place machines that mount every other surface mount part, and they are designed to survive the reflow soldering that assembles the rest of the board. Electret capsules were more often attached as a separate step. When a phone has four or five microphones, that difference adds up.

Consistency. Silicon processes produce parts that are closely matched from unit to unit. That matters a great deal for arrays, because beamforming and noise suppression assume the microphones behave alike. A mismatched pair produces a smeared beam.

Digital output. A digital MEMS microphone sends a bit stream that is less vulnerable to electrical noise picked up on the trace from the microphone to the processor. In a device crowded with radios and switching power supplies, that is a real advantage.

Power. Low power, always on listening was a design goal of the last decade. Apple's "Hey Siri" write up describes a microphone signal routed to a small, low power processor so the main processor can sleep. That architecture works best with microphones designed for very low standby current.

We could not find a primary source that dates the first MEMS microphone in a mass market phone, so we will not give one. The direction is clear from any phone teardown of the last decade: the electret capsule is gone, and two to five MEMS parts have taken its place.

What is beamforming and why do devices have several mics?

Beamforming is the trick of combining several microphones so that the array listens more strongly in one direction than in others.

Sound arrives at each microphone at a slightly different time depending on where it came from. If you delay each microphone's signal so that sound from a chosen direction lines up exactly, and then add them, sound from that direction adds up and sound from other directions partly cancels. That is the simplest form, called delay and sum. More advanced adaptive beamformers continuously recompute the weights to steer a null at a noise source such as a fan or television.

Multiple microphones serve several jobs:

• Far field pickup. Smart speakers use a ring of microphones so they can hear a voice from across a room and work out which direction it came from.
• Noise suppression on calls. Phones and laptops compare a microphone near your mouth with one farther away to separate your voice from the background.
• Echo cancellation. Devices that play audio and listen at the same time need to subtract their own speaker output from what the microphones hear.
• Active noise cancellation in earbuds. An outward facing mic hears ambient noise, an inward facing one checks what reaches the ear.

The array also turns out to matter for security. The Light Commands researchers point out that a single beam of light usually lands on one microphone while the others hear nothing. A device that checks whether all its microphones agree can treat that mismatch as a sign of injection rather than speech. We return to that under mitigations.

What is USB Audio Class and which versions exist?

USB Audio Class (the USB-IF calls it the Audio Device Class Definition, ADC) is the standard that lets a USB microphone, headset or audio interface work without a vendor driver. It defines the descriptors that tell the host what the device contains (terminals, mixers, feature units for volume and mute, clock sources) and how audio streams move over isochronous endpoints. USB defines Audio as base class 01h, used at the interface level, in its class code table.

According to the 4.0 specification, the class covers everything used to "manipulate audio, voice, and sound-related functionality," including gain and tone control. It does not cover transport controls, and volume or play and pause buttons are conveyed through the separate Human Interface Device class.

The USB Audio Class version table

A few details from the 4.0 changes list are worth knowing if you build audio hardware. Release 4.0 removes the Dolby Processing Unit, encoder and decoder support, and the S/PDIF style copy protection control that 2.0 carried. It adds Power Domains, which let a headset power down its microphone path separately from its headphone path. It also adds Channel IDs so a channel can be traced through the whole audio function.

Why does a class driver matter for privacy? Because the operating system, not a vendor driver, owns the device. When a USB headset uses the standard class, its microphone shows up in the same OS permission system as the built in microphone, and the same indicators fire when an app opens it. A vendor specific device that ships its own driver and service may not always appear the same way, which is one reason Microsoft warns that some desktop apps can access the mic outside its controls (more below).

How do wake words work, and what is processed on device?

A wake word system has one job: decide, continuously and cheaply, whether the last second or so of audio contained a specific phrase. Everything else (speech recognition, language understanding, answering) can wait until it says yes.

Apple's 2017 article on "Hey Siri" is the most detailed vendor description we found, and it is worth summarizing because the pattern is common:

1. The microphone signal goes to the iPhone's Always On Processor, which Apple describes as "a small, low-power auxiliary processor" (the motion coprocessor), on iPhone 6S and later.
2. A small deep neural network acoustic model runs there and scores each frame against the trigger phrase.
3. If that first pass fires, the main processor wakes and runs a larger second pass model.
4. A speaker recognition step compares the utterance with examples the owner recorded at setup.
5. Only if those stages pass does the audio go to Apple's server, where the main recognizer can still cancel the activation if it hears something else, Apple's example being "Hey Seriously."

Apple also describes a two threshold scheme. A lower "second chance" threshold does not trigger on its own but makes the system more receptive to a repeat attempt shortly after, which trades a few extra false activations for fewer frustrated users. On Apple Watch, a single pass detector runs only after a wrist raise turns the screen on, because the battery is so small.

Amazon and Google describe the same boundary in their own privacy material, without the model details:

• Amazon: Alexa devices "are designed to detect only your chosen wake word" by identifying acoustic patterns. Amazon's help page says no audio is stored or sent to the cloud unless the device detects the wake word or Alexa is activated with a button. When it is sending, an Echo's light ring turns blue (or a blue bar appears on Echo Show), and you can enable an audible tone each time audio goes to the cloud. Follow Up Mode, which Amazon says is turned on for compatible devices when you join Alexa+, lets follow up requests skip the wake word for a short time.
• Google: Google's Nest privacy commitments say a device sends audio to Google only when it detects someone interacting with the Assistant, for example by saying "Hey Google," or when a feature that needs audio is on, such as sound alerts on a Nest Cam. Google adds a nuance worth knowing: when a request can be fulfilled faster on the device, the recording may be sent to Google only after the visual indicator turns off, so the light shows when the microphone is active, not necessarily when data is transmitted.

What on device detection does and does not guarantee

On device detection means the continuous stream of room audio is not being shipped to a server. It does not mean nothing ever leaves the device by mistake. Every wake word detector trades false accepts against false rejects, and Apple's article is frank that tuning the threshold moves you along that curve. A false accept sends a few seconds of whatever was being said to the cloud as if it were a request.

Retention is a separate question from detection. In May 2023 the FTC and the Department of Justice charged that Amazon had kept children's Alexa voice recordings indefinitely unless a parent asked for deletion, and had not fully deleted transcripts after such requests. The proposed order included a 25 million dollar civil penalty and limits on using that voice data to build or improve products, subject to court approval. The lesson is general: whatever the wake word design, check what the service keeps and use the deletion controls. Amazon's help page points to the Alexa Privacy settings for reviewing and deleting recordings and transcripts, and also notes that deletion "can take some time to complete."

What mic indicators and permissions exist per OS?

Each platform has three layers: a permission that gates access per app, an indicator that shows when the mic is in use, and on some platforms a switch that cuts all apps off at once.

iOS and iPadOS

Apple's iPhone User Guide says apps must request permission before using the microphone "and explain why they're asking." You review and change access in Settings, Privacy and Security, Microphone. An orange indicator appears when an app uses the microphone without the camera, and a green one when the camera is in use (with or without the microphone). Control Center also shows a message naming the app that recently used either.

macOS

On a Mac, the same per app list lives in System Settings, Privacy and Security, Microphone. Apple's Mac User Guide says the Recording Indicator in Control Center shows when the microphone "is in use or has been used recently." Administrators can manage these settings with configuration profiles; Apple points system administrators to its Platform Deployment guide.

Android

The Android Open Source Project documentation describes the indicators in detail for Android 12 and later:

• A status bar icon appears when an app has ongoing microphone, camera or location access. It starts as an icon and then shrinks to a dot that stays until the app is dismissed or closed.
• Tapping the indicator in Quick Settings opens a dialog that lists the apps using the microphone, camera or location.
• Microphone use counts as active while the system marks it as running or for 5 seconds after a one off access. The dialog also shows recent access within the prior 15 seconds.
• Under the hood, apps' accesses are recorded as app ops (startOp, stopOp, noteOp), and the System UI listens for them. Telephony has to report its own usage because phone calls use a separate microphone stack.

Android 12 also added a Privacy Dashboard with a timeline of microphone access, and on supported devices a microphone toggle in Quick Settings. Android's developer documentation says that when the toggle is off, apps receive silent audio, and that the system turns microphone access back on when you place an emergency call.

Windows

Microsoft's support page says a microphone icon appears in the notification area of the taskbar when an app is using the microphone. Controls sit under Start, Settings, Privacy and security, Microphone in Windows 11: a device level "Microphone access" switch, "Let apps access your microphone" with per app toggles for Microsoft Store apps, and "Let desktop apps access your microphone," which covers desktop apps as a group.

Two caveats from the same page matter for anyone who relies on these switches. Desktop apps "cannot be individually toggled." And desktop apps "may not always appear in the list" or might "still be able to access your camera or microphone even when these settings are turned off." The desktop app setting has existed since Windows 10 version 1903. Microsoft also notes that features using the mic through a Windows component show up under that component's name, for example "Speech Runtime Executable."

The web

In browsers, the W3C Media Capture and Streams specification governs getUserMedia. Three parts of it matter here:

• Secure contexts only. navigator.mediaDevices and getUserMedia are marked SecureContext, so a page served over plain HTTP cannot ask for the microphone.
• Permissions Policy. "microphone" is a policy controlled feature with a default allowlist of "self". An embedded iframe from another origin cannot use the mic unless the embedding page explicitly allows it.
• Privacy indicators. The browser "MUST indicate to the user" when microphone access or live capture starts or stops, and any off to on change must stay observable long enough for a reasonably observant user to notice, which the spec says "SHOULD be at least 3 seconds."

The per OS comparison table

What is Apple's hardware microphone disconnect?

This is the strongest microphone control on any mainstream consumer device, because it does not rely on software behaving well.

According to Apple Platform Security, all Apple silicon Mac laptops and Intel Mac laptops with the Apple T2 Security Chip have a hardware disconnect that turns the microphone off whenever the lid is closed. On 13 inch MacBook Pro and MacBook Air laptops with T2, all MacBook laptops with T2 from 2019 or later, and all Apple silicon laptops, the disconnect is "implemented in hardware alone." Apple says the design prevents any software, "even with root or kernel privileges in macOS," and even software on the T2 or other firmware, from engaging the microphone with the lid closed. The camera is not disconnected, because the closed lid blocks its view.

iPads from 2020 onward have the same protection when an MFi compliant case (including Apple's own) is attached and closed.

The mechanism, as Apple describes it:

1. One or more lid sensors detect closure, for example a Hall effect sensor or a hinge angle sensor.
2. Where calibration is needed, parameters are set in production and then locked with a nonreversible hardware lock out.
3. The sensor signal passes through simple, non reprogrammable hardware logic that adds debounce, hysteresis or a delay of up to 500 ms.
4. Depending on the product, that logic either cuts the data lines between the microphone and the system on a chip, or cuts an input the microphone needs to run, such as its clock line.

Cutting the clock is a nice illustration of why MEMS matters here: a digital microphone with no clock produces no data at all. The protection is narrow by design. It applies only with the lid or case closed. With the lid open, you are back to software permissions and the Recording Indicator. And it says nothing about external microphones on USB or Bluetooth.

Amazon's Echo devices have a related physical control. Amazon's help page says the microphones button disconnects power to the microphones and lights a dedicated red light; with the mics off, the device cannot stream audio even if someone says the wake word. Amazon adds that turning the mics off also disables presence detection on supported Echo devices.

What did DolphinAttack and Light Commands show?

Both lines of research targeted the same weak point: the gap between what a person in the room can perceive and what a microphone and speech recognizer will accept. We describe the findings at the level of the researchers' own abstracts and FAQs, without any setup detail.

DolphinAttack (2017)

DolphinAttack was posted to arXiv on 31 August 2017 and published in the proceedings of ACM CCS 2017. Earlier work had shown "hidden voice commands" that people could hear but not understand. DolphinAttack set out to make commands completely inaudible.

The idea in the abstract is that a voice command can be modulated onto an ultrasonic carrier above 20 kHz, which people cannot hear. Microphone circuits are not perfectly linear, and that nonlinearity demodulates the signal back into the audible band inside the device, where the speech recognizer interprets it. The authors validated the effect against Siri, Google Now, Samsung S Voice, Huawei HiVoice, Cortana and Alexa, with proof of concept actions such as starting a FaceTime call, switching a phone to airplane mode and manipulating a car's navigation system.

Importantly, the paper also proposed defenses: detecting the attack by classifying audio with a support vector machine, and redesigning voice controllable systems to reject inaudible commands. Later research at the NDSS Symposium (SurfingAttack) extended the ultrasonic line to guided waves travelling through a table surface.

Light Commands (2020)

Light Commands, by Sugawara, Cyr, Rampazzi, Genkin and Fu, was posted to arXiv on 22 June 2020 and published at USENIX Security 2020. Its finding was stranger: MEMS microphones respond to light aimed at their aperture as if it were sound. By modulating the intensity of a light beam, the researchers produced electrical signals in the microphone that the voice assistant treated as speech.

The paper's abstract reports control of devices running Alexa, Siri, Portal and Google Assistant at distances up to 110 meters, which the researchers note was simply the longest hallway they had. The FAQ lists smart speakers, phones and tablets among the tested devices and says the effect is "generally independent from color and wavelength." Their consequences list is the part that matters to defenders: once a voice assistant accepts commands, it can open smart garage doors, make purchases, or unlock and start some vehicles. The researchers also said they had seen no indication of malicious use in the wild.

Why these papers matter even if you never meet a laser

These attacks need line of sight or physical proximity, and nobody should rearrange their home in fear. Their value is what they taught designers:

• The microphone is a sensor, not an authenticator. Anything that can move the diaphragm or the signal chain can produce "speech."
• Speaker recognition is weaker than it looks. The Light Commands FAQ notes that, at the time, speaker recognition was off by default on smart speakers and checked only the wake word, not the rest of the command.
• The actions behind the voice interface determine the risk. A voice assistant that can only tell you the weather is a curiosity target. One that can unlock a door is a door lock with a microphone attached.

What mitigations exist for voice assistants?

The researchers' own suggestions, plus the controls the vendors document, fall into a few groups.

Confirm sensitive actions. The Light Commands team suggests "an additional layer of authentication," or asking the user a simple randomized question before executing a command, which defeats an attacker who cannot hear the device's response. In practice that means requiring a voice PIN for purchases and an unlocked phone for door locks and vehicle actions.

Use the array. A real voice reaches every microphone in an array with predictable timing differences. Light usually hits one. Comparing microphones can flag injected audio. DolphinAttack's authors similarly showed that inaudible injection leaves features a classifier can detect.

Block line of sight. A barrier or a non transparent cover over the mic port attenuates light. The researchers caution this only helps "to a certain point," since an attacker can increase power. Simply not placing an assistant in view of a window removes most of the practical exposure.

Use the mute control. On Echo devices the microphones button cuts mic power and lights a red light. Google says Nest users can always turn the microphone off. A muted device in a meeting room or bedroom is not listening to anything.

Turn on audible confirmation. Amazon lets you enable a short tone whenever audio goes to the cloud. Combined with the light ring, that makes a false or injected activation noticeable.

Review history and retention. Use the vendor's review and delete controls for recordings and transcripts. The 2023 FTC action is a reminder that deletion and retention practices are a real part of microphone privacy.

Decision table: matching controls to the setting

How should apps request microphone access?

All three major platforms say roughly the same thing: ask late, ask for a reason, and handle refusal gracefully.

iOS and macOS. Apple's developer documentation says the NSMicrophoneUsageDescription key "is required if your app uses APIs that access the device's microphone." Its value is the message shown in the permission prompt. A separate key, NSAudioCaptureUsageDescription, covers capturing system audio on macOS. Write the purpose in plain words tied to a feature ("to record voice notes you start from the record button"), not "to improve your experience."

<!-- Info.plist -->
<key>NSMicrophoneUsageDescription</key>
<string>Used to record voice notes when you tap the record button.</string>

Android. Android's developer guidance says to wait until the user has granted RECORD_AUDIO before touching the microphone, and to request it when the user interacts with the feature that needs it. If your app needs to keep recording in the background, as a voice recorder or calling app does, it must use a foreground service with type microphone and the FOREGROUND_SERVICE_MICROPHONE permission. Because RECORD_AUDIO is subject to while in use restrictions, you cannot start a microphone foreground service while the app is in the background or from a boot completed receiver, apart from documented exceptions.

<!-- AndroidManifest.xml -->
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MICROPHONE" />

<service
    android:name=".RecorderService"
    android:foregroundServiceType="microphone"
    android:exported="false" />

// Ask at the moment the user taps "record", not at app launch
val requestMic = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { granted ->
    if (granted) startRecording() else showVoiceFeatureUnavailable()
}

recordButton.setOnClickListener {
    if (ContextCompat.checkSelfPermission(this, Manifest.permission.RECORD_AUDIO)
        == PackageManager.PERMISSION_GRANTED) {
        startRecording()
    } else {
        requestMic.launch(Manifest.permission.RECORD_AUDIO)
    }
}

Android also lets apps link a rationale activity to the Privacy Dashboard so users can see why the app used the mic, and documents SensorPrivacyManager.supportsSensorToggle(Sensors.MICROPHONE) for checking whether the device has the global toggle. When the toggle is off, your app gets silent audio, so a voice feature that suddenly receives nothing but silence should tell the user to check the toggle rather than fail quietly.

Web. Call getUserMedia from a user gesture, over HTTPS, and stop the tracks when you are done so the indicator goes off.

// Request the mic only when the user starts a voice feature
startButton.addEventListener("click", async () => {
  const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
  recorder = new MediaRecorder(stream);
  recorder.start();
  stopButton.onclick = () => {
    recorder.stop();
    stream.getTracks().forEach((t) => t.stop()); // releases the mic and the indicator
  };
});

Lock down where the microphone may be used with a Permissions Policy response header, and grant it to a specific embedded frame only when you mean to:

Permissions-Policy: microphone=(self)

<!-- Only this embedded voice widget may ask for the mic -->
<iframe src="https://voice.example.com/widget" allow="microphone"></iframe>

If your site never needs the microphone, microphone=() disables it for the page and every frame in it.

Step by step: audit microphone access on your own devices

These checks are read only unless noted. None of them erase data, but the revoke and reset commands change permissions, so run them only on devices you manage.

1. Linux: find the microphones and what holds them

# List capture devices known to ALSA
arecord -l

# On PipeWire or PulseAudio systems, list input sources
pactl list short sources
wpctl status        # PipeWire: shows sources and active streams

# Which processes currently have sound devices open
sudo fuser -v /dev/snd/*

# For USB microphones: confirm Audio class (bInterfaceClass 1) and the ADC version
lsusb
sudo lsusb -v -d <vendor:product> | grep -E "bInterfaceClass|bcdADC"

# Mute the default input from the command line
pactl set-source-mute @DEFAULT_SOURCE@ 1

The bcdADC field in the Audio Control interface header tells you which Audio Class release the device's descriptors follow, for example 1.00 or 2.00.

2. macOS: review and reset permissions

# List audio devices, including external and Bluetooth microphones
system_profiler SPAudioDataType

# Reset microphone permissions for all apps (each app will ask again)
tccutil reset Microphone

# Or for a single app by bundle identifier
tccutil reset Microphone com.example.app

Then open System Settings, Privacy and Security, Microphone and re-check the list. Watch the Recording Indicator in Control Center while you use voice features to confirm it appears and clears.

3. Windows: see which apps used the microphone

Open Settings, Privacy and security, Microphone and check the list under "Let desktop apps access your microphone," which shows desktop apps Windows has detected using the mic. Microsoft notes you can select an app there to see the specific file that accessed the mic. From PowerShell you can list audio endpoints and the per app consent store:

# Audio endpoints known to Windows
Get-PnpDevice -Class AudioEndpoint | Select-Object Status, FriendlyName

# Per app microphone consent entries for the current user (read only)
Get-ChildItem "HKCU:\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\microphone" |
  ForEach-Object { Get-ItemProperty $_.PSPath | Select-Object PSChildName, Value }

Treat the registry view as a convenience for inventory; the Settings page is the supported control.

4. Android: check and revoke from a computer

With USB debugging enabled on a device you own:

# Permission state for one app
adb shell dumpsys package com.example.app | grep RECORD_AUDIO

# App op state for one app
adb shell appops get com.example.app RECORD_AUDIO

# Revoke the runtime permission from an app that should not have it
adb shell pm revoke com.example.app android.permission.RECORD_AUDIO

On the phone, open Settings, Security and privacy (or Privacy), Privacy Dashboard, Microphone to see the timeline, and add the microphone tile to Quick Settings if your device supports the toggle.

5. Smart speakers: set the defaults once

• Turn on the audible tone for cloud requests (Alexa app, device settings).
• Require a voice code for purchases and disable voice unlock for locks and garage doors.
• Review and delete stored recordings in the vendor's privacy settings, and set automatic deletion where offered.
• Mute the microphones whenever the room should be private; confirm the red light.

Common mistakes

• Assuming the Windows desktop switch covers everything. Microsoft states desktop apps may not appear in the list and may access the mic even when the settings are off. Treat it as one layer, not a guarantee.
• Asking for the mic at app launch. Users deny a permission they do not understand, and platform guidance on every OS says to ask when the user starts the feature.
• Forgetting to stop the stream. On the web, a MediaStream left open keeps the browser indicator on and the mic live. Stop every track.
• Giving embedded content the microphone by accident. A wildcard Permissions Policy or a broad iframe allow attribute hands mic access to third party code. Default to self and grant per frame.
• Treating speaker recognition as authentication. The Light Commands researchers found it often checked only the wake word and could sometimes be bypassed with synthesized speech.
• Connecting door locks or vehicles to a voice assistant without a second factor. The research shows why the action, not the microphone, sets the risk.
• Relying on a hardware disconnect that does not apply. Apple's cutoff works with the lid or case closed. It does not cover an open laptop or an external USB microphone.
• Ignoring retention. On device wake word detection says nothing about how long a service keeps the recordings it does receive. Check and use deletion controls.
• Silently failing when the Android toggle is off. Your app receives silent audio, not an error. Detect it and tell the user.

FAQ

Can my phone listen to me without the indicator showing?

On current iOS and Android, ordinary apps cannot use the microphone without triggering the system indicator, because the operating system draws it when access starts. Android's documentation notes that system apps are handled differently and that phone calls use a separate audio stack that telephony must report. The indicator is not a defense against a fully compromised operating system, which is why keeping the OS updated matters.

Is Alexa always recording?

Amazon says Echo devices listen locally for the wake word and do not store or send audio to the cloud unless they detect it or you press the action button. The light ring turns blue when audio is streaming. False activations can still send short clips, so review recordings and use the mute button when you want certainty.

What does the orange dot on an iPhone mean?

It means an app is using the microphone without the camera. A green indicator means the camera is in use, with or without the microphone. Open Control Center to see which app recently used either.

Does closing my MacBook lid turn off the microphone?

On Apple silicon Mac laptops and Intel Mac laptops with the T2 chip, yes. Apple says the disconnect works in hardware and that no software, even with kernel privileges, can enable the mic while the lid is closed. External microphones are not covered.

What is USB Audio Class 2.0 versus 3.0 and 4.0?

They are releases of the USB Audio Device Class. 2.0 (2006) added High Speed support and is still the version most audio interfaces use. 3.0 (2016) added Basic Audio Device Definitions and power saving. 4.0 (2023) replaced 3.0, added Power Domains and new descriptor structures, and is not backward compatible as such.

Can someone hack a smart speaker with a laser?

Researchers showed in 2020 that modulated light aimed at a MEMS microphone can inject commands at long range with line of sight. They reported no sign of use in the wild. Moving the device away from windows and requiring a PIN for sensitive actions removes most of the practical risk.

How do I stop websites from using my microphone?

Deny the permission prompt, or manage site permissions in your browser's settings. Microsoft's guide for Edge, for example, uses Settings, Privacy, search and services, Site permissions, then lets you set Microphone to Block for a site. Browsers must also show an indicator while a site has the microphone.

Does the Android microphone toggle really cut off apps?

On supported Android 12 and later devices, Android's documentation says apps receive silent audio while the toggle is off. The exception is an emergency call, for which the system re-enables microphone access.

Where Safeguard fits

Safeguard does not manage devices, enforce microphone permissions, monitor audio or scan firmware, and none of the controls in this post depend on it. The honest connection is narrower. Voice features are built from open source components: audio servers such as PipeWire and PulseAudio, codec and container libraries, speech and wake word toolkits, and the Android and Linux images that ship in smart speakers and kiosks. If you build voice apps or audio devices, those are dependencies like any other, and Safeguard can scan your repositories, container images and SBOM files, match the components against vulnerability databases, apply reachability analysis, and show which of your projects contain a given component and version. Microphone hardware, OS indicators and a vendor's cloud retention practices stay outside that scope.

Fix it without waiting for upstream

Microphone privacy is mostly operating system and vendor territory, but the voice apps, audio libraries and device images you build on top of it carry open source code that gets advisories like anything else. If you ship a voice feature, the same patch discipline applies to the audio and speech components you compile, while the microphone, its driver and the OS indicators still come from the platform vendor.

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

These demos show dependency workflows and approval flows, not microphone controls. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the component to bump is an audio or speech library in a voice app you maintain.

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

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. If you build an image for a kiosk, a meeting room device or a smart speaker prototype, the same terminal scan can run against that project before the image ships.

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

This demo is a real Android session that sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. It is the same principle this post argues for with microphone permissions: ask at the moment of use, show what is being asked, and let a person decide.

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

Quick check

Sources

• Apple Platform Security: Hardware microphone disconnect
• Apple iPhone User Guide: Control access to hardware features
• Apple Mac User Guide: Control access to the microphone on Mac
• Apple Developer: NSMicrophoneUsageDescription
• Apple Machine Learning Research: Hey Siri, an on-device DNN-powered voice trigger
• Android Open Source Project: Privacy indicators
• Android Developers: Explain access to more sensitive information
• Android Developers: Foreground service types
• Microsoft Support: Windows camera, microphone, and privacy
• W3C: Media Capture and Streams
• USB-IF: USB Audio Devices Release 4.0 and Adopters Agreement
• USB-IF: USB Device Class Definition for Audio Devices Release 2.0 with errata and ECN
• USB-IF: Document library
• USB-IF: Defined class codes
• Amazon: Alexa, Echo devices, and your privacy
• Amazon: Alexa privacy hub
• Google Safety Center: Nest privacy commitments
• FTC: FTC and DOJ charge Amazon with violating children's privacy law by keeping kids' Alexa voice recordings forever
• arXiv: DolphinAttack, Inaudible Voice Commands (1708.09537)
• ACM Digital Library: DolphinAttack, CCS 2017 proceedings
• arXiv: Light Commands, Laser-Based Audio Injection Attacks on Voice-Controllable Systems (2006.11946)
• Light Commands researchers: project site and FAQ
• NDSS Symposium: SurfingAttack, Interactive Hidden Attack on Voice Assistants Using Ultrasonic Guided Waves
• Physical Review: Wente, A Condenser Transmitter (1917)
• Journal of the Acoustical Society of America: Sessler and West, Self-Biased Condenser Microphone with High Capacitance (1962)
• Wikipedia: Microphone (history, secondary source)

Last reviewed: 23 October 2026. Operating system privacy controls change with each major release; check the linked vendor pages for the current behaviour on your version.