In a 2023 experiment, researchers classified individual keyboard presses with 95 percent accuracy from a nearby smartphone recording and 93 percent from audio captured through Zoom. Those results make AI acoustic side-channel attacks worth understanding. They do not mean an attacker can recover 93 percent of anyone's passwords simply by joining a meeting. The research measured recognition of individual keys under a defined training and recording setup, rather than successful account compromises or a campaign against unsuspecting victims.
At their core, these attacks exploit information carried by ordinary physical signals. A keyboard produces sound; a phone's speaker produces vibration; a microphone can respond to signals a person does not hear. Researchers have explored ways to turn those properties into information leaks or unauthorized commands. The mechanisms differ, and so do the conditions an attacker must satisfy.
For professionals, policymakers, and security-conscious technologists, the useful question is where these demonstrations change an assessment of risk. That requires separating the signal captured, the model's task, its test conditions, and the sensitive information an adversary might ultimately obtain. This article examines the research behind the headline numbers, the limits of microphone permissions, and proportionate measures for sensitive work.
Key Takeaways
- The widely reported 95 and 93 percent results describe individual-key classification in a trained experimental setup. They are not full-password recovery rates.
- A separate 2024 paper reported 43 percent average word recovery using a different method and metric. The numbers cannot be treated as one model's performance moving out of the laboratory.
- EarSpy studied speech information inferred from phone-speaker vibrations. SurfingAttack studied active ultrasonic command injection. Neither is evidence of microphone-free keyboard password recovery.
- Microphone permissions and access indicators help manage audio exposure, but they do not establish what an authorized recipient or recording service does with captured sound.
- For sensitive workflows, reduce unnecessary recording, limit access to meeting audio, and reduce dependence on manually typed passwords. Treat noise-based defenses as experimental rather than guaranteed protection.
What Are AI Acoustic Side-Channel Attacks?
Core Definition and Mechanism
An acoustic side channel carries information outside the intended digital communication path. The application receives a keyboard character through its normal input system, while the key press also creates an audible sound. If a recording contains enough distinguishing information, an attacker may try to infer the character from that second signal.
The 2023 experiment illustrates a supervised-learning approach. Researchers recorded labeled key presses, converted the audio into representations suitable for a neural network, trained a classifier, and tested it on held-out examples. The labels told the system which sound belonged to which key. It was not given an arbitrary conversation recording and asked to discover a stranger's password without preparation.
Different keys need not have perfectly unique or stable sounds for classification to work. A model can use statistical differences in the recordings. Conversely, a sound pattern learned from one keyboard, recording position, or typing style is not automatically a reliable fingerprint elsewhere. A credible assessment asks how much the test setup resembles the situation in which an attacker would use the result.
Why Machine Learning Matters
Machine learning helps identify patterns that would be difficult to recognize by listening. It also makes it possible to process recordings repeatedly and test different interpretations. That is a meaningful capability, even where the resulting predictions contain errors.
It is misleading, however, to divide this history into an earlier era of manual analysis and a new era in which AI suddenly made the attacks possible. A 2023 survey of keyboard acoustic side-channel research describes earlier statistical, neural-network, and other machine-learning approaches. The development is an evolving research field, rather than a single recent breakthrough that removed every practical constraint.
The distinction matters for procurement and policy. A system advertised as using a newer architecture still needs evidence about the recording access, training data, devices, and tasks it supports. A more sophisticated model name does not answer those questions. Nor does fast processing prove that an adversary can obtain usable recordings at scale.
Which Information Is Actually Being Inferred?
Keystroke classification is one task. Recovering words, reconstructing a random password, identifying a speaker, and getting a voice assistant to execute a command are different tasks. An experiment can succeed at one while saying little about the others.
Language can help resolve uncertainty when the target is ordinary text: a plausible sentence constrains which words fit. A random password does not offer the same grammatical clues. Missing key presses, uncertain boundaries, punctuation, capitalization, and mistakes can complicate the path from predicted characters to a usable secret. Security assessments should therefore name the target information rather than use “password theft” as shorthand for every acoustic result.
How Apps and Meetings Expose Useful Signals
Microphone Access and Platform Controls
For a microphone-based attack, usable audio has to reach the attacker. Possible scenarios include an untrusted meeting participant receiving microphone audio, a recording shared beyond its intended audience, or software with access to the microphone. These are threat-model scenarios, not evidence that every conferencing app or recording has been exploited.
Apple's App Privacy Report documentation explains how to view recent access to sensors and data, including the microphone. On supported iPhones, collection starts after the report is enabled and covers the previous seven days of activity. An empty history immediately after enabling it is not proof that earlier access never occurred.
Android's Privacy Dashboard instructions describe reviewing which apps accessed permissions and changing access settings. The history period depends on the Android version: the documented dashboard covers the past seven days on Android 13 and the past 24 hours on Android 12. Device menus can differ, so follow the controls available on the managed device rather than assuming one screenshot applies everywhere.
Apple also documents per-app microphone controls and recording indicators. These controls provide useful information about local access. They do not certify that a meeting participant is trustworthy, establish how a remote recording is stored, or show that captured typing was successfully classified.
Permission Requests Are Not Proof of Recording
A dated permissions study remains useful context when its meaning is kept narrow. In July 2025, Which? reported tests conducted with Hexiosec on 20 popular Android apps. The selected apps collectively requested 882 permissions, including 78 categorized as risky; 14 requested microphone access. Some access was optional or connected to legitimate functionality.
That investigation did not test acoustic keystroke recovery. A permission request is not evidence of background recording, malicious intent, or a compromised password. Its relevance here is the governance question: does an application need access to a sensitive input, and do users or administrators understand when that access is appropriate?
For an organization, it is more useful to answer that question for its actual applications than to treat a count from selected consumer apps as a measurement of its own exposure. Meeting software may reasonably need a microphone. A separate decision concerns participants, recording, transcription services, retention, and who receives the resulting files. Our Privacy & Identity Protection resources provide broader context for reviewing those data-sharing decisions.
Microphones Are Only One Possible Input
Acoustic research also includes vibrations measured through other sensors. That does not make all sensor access equivalent to unrestricted audio recording. The device, sensor placement, sampling rate, operating system, and particular signal all affect what can be measured.
EarSpy, discussed below, is an example of this narrower point. It studied information carried by a phone's own earpiece vibrations. It should prompt a specific question about the tested signal path, rather than the conclusion that any phone app can secretly hear everything without microphone permission.
Four Research Examples and What They Establish
1. Keyboard Classification Through a Smartphone or Zoom
The 2023 study used a 2021 16-inch MacBook Pro and 36 classes of keys: the letters a–z and digits 0–9. The researchers collected 25 presses of each key. In the phone-recording setup, an iPhone 13 mini sat approximately 17 centimeters to the left of the laptop. The Zoom experiment used the laptop's built-in microphone and low noise suppression.
The reported 95 percent smartphone and 93 percent Zoom figures came from classifying individual test keystrokes, with 180 test items in each case. They show that this keyboard's sounds retained useful distinguishing information through those recording paths. They do not establish the probability of reconstructing an entire password, working across arbitrary keyboards, or identifying every key in a continuous stream of normal meeting activity.
The training requirement is important. An adversary would need suitable examples or another viable route to learn the target sounds, usable audio, and a way to identify and interpret the relevant typing. The study makes that concern concrete, but it does not demonstrate that joining any Zoom meeting supplies all those conditions.
For a sensitive meeting, the operational lesson is to consider what the microphone transmits alongside speech. The research supports reviewing that exposure. It does not support telling employees that a 93 percent password-theft probability applies whenever they type during a call.
2. Word Recovery Under Different Experimental Conditions
A March 2024 preprint on acoustic eavesdropping explored a different approach using statistical information about timing between keystrokes. Across 20 adult users, it reported an average of 43 percent of words correctly detected. The work considered different keyboards, typing styles, and ambient noise, and used an English dictionary to filter possibilities.
This result should not be described as the earlier deep-learning classifier retaining 43 percent accuracy in the real world. The methods, evaluation units, and assumptions differ. In the 2024 work, the timing model was trained and tested for the same user, and word recognition benefited from language constraints. Those details belong beside the result because they explain both its value and its limits.
Recovering part of ordinary text could still expose useful information. That is a reasonable security concern. It is a separate proposition from recovering 43 percent of random passwords or compromising 43 percent of accounts. Neither inference follows from the reported word-recognition metric.
3. EarSpy and Vibrations From a Phone's Earpiece
The EarSpy research preprint, first posted in December 2022, investigated whether accelerometers could pick up information from a phone's earpiece speaker. The experiments used OnePlus 7T and OnePlus 9 phones running Android 11 and Android 12, respectively, with known speech datasets played through the earpiece.
Researchers evaluated tasks including speaker characteristics and spoken-digit recognition. A reported digit-classification result reached 56.42 percent across ten digit classes. This was not full-conversation transcription, a demonstration of arbitrary microphone replacement, or a keyboard-password attack. Speaker vibration, sensor layout, sampling, and the particular phone mattered to the experiment.
The permission issue also needs platform context. Google's Android sensor documentation describes restrictions on background sensor access and sampling rates that vary with Android version and app targeting. For example, Android 9 restricts background access to several continuously reporting sensors, while newer targeting rules limit standard motion-sensor sampling rates unless the relevant higher-rate permission is declared. A result on the tested phones should not be presented as an unchanged capability on every current Android device.
For security teams, EarSpy is a reason to include unintended physical signal paths in device assessments. It is not a reason to tell users that denying microphone permission has no value.
4. SurfingAttack and Active Ultrasonic Command Injection
SurfingAttack, presented at NDSS in 2020, studied a different direction of attack. Rather than listening to keyboard sounds, researchers sent ultrasonic guided waves through a tabletop to influence a phone's voice assistant. Their setup included a transducer in contact with the table, concealed underneath it.
This is active command injection: a signal is introduced with the aim of making a system interpret it as a command. The experiments involved 17 phone models and four table materials, succeeding on 15 phones and three table types under the tested conditions. Effects depended on the devices, the surface and its properties, and the assistant commands available.
The result belongs in a discussion of acoustic security because it challenges assumptions about microphones and audible speech. It does not demonstrate that ultrasonic signals recover keyboard passwords. Nor does a 2020 test establish that all current voice assistants or phones remain vulnerable to the same setup. The relevant question for a deployed product is whether the particular signal path and command behavior still exist.
Why These Attacks Matter to Organizations
Assess the Whole Path to Sensitive Information
The research is valuable because it identifies ways information or commands can cross boundaries that a conventional application diagram may omit. A keyboard's sound is not the same as its USB or Bluetooth input. Earpiece vibration is not the same as granting an app microphone access. A surface-borne command is not an authorized person speaking to a device.
For a useful threat model, work through the entire path. What equipment or access must the attacker have? Which signal reaches that access point? What training or calibration is necessary? What output does the model produce? Finally, what could the adversary do with it? Recording sound and compromising an account are separate stages, each with its own assumptions.
This also keeps priority decisions proportionate. A team handling unusually sensitive conversations may decide to restrict recording devices in a designated room. Another may gain more from reducing recording retention and tightening access to meeting files. Neither decision requires claiming that acoustic espionage is a documented routine attack against the organization.
Keep Experimental Findings Separate From Incident Evidence
The papers discussed here establish research results. They do not, by themselves, establish how often criminals or state actors deploy these methods. Assertions about widespread campaigns, undetectable operation, or absent logs need separate evidence.
That distinction should carry through briefings. Identify the research date, tested equipment, measured task, and limitations. Label a hypothetical scenario as a scenario. If a team reports a suspected incident, distinguish observed recording access or sensor collection from an inferred acoustic decoding step. Accurate language lets decision-makers take a technical possibility seriously without treating every possibility as an observed event.
How to Reduce Exposure During Sensitive Work
Reduce Unnecessary Audio and Recording Access
Start with the recording opportunity rather than a promise to defeat every model. Review which applications need microphone access and remove unnecessary grants. For sensitive meetings, identify who can attend, whether recording or automated transcription is necessary, and who can retrieve the resulting audio.
Where practical, avoid manually typing secrets while transmitting keyboard sound to people or services that do not need it. Pause the relevant audio transmission or complete the authentication step separately. A mute control affects the audio path it actually controls; it should not be described as physically disconnecting every microphone or stopping other local software from recording.
Hardware controls also need device-specific interpretation. A documented physical disconnect may offer a different assurance from a software mute button. Verify what a switch disconnects before relying on it. Similarly, a conferencing noise-suppression setting is designed for meeting audio, not a certified acoustic side-channel defense. The Zoom result depended on the study's selected recording settings.
Reduce the Consequences of a Captured Password
Password managers can reduce occasions when a person manually types a password, while strong multifactor authentication adds a separate barrier if a password is exposed. NIST's authentication guidance supports password managers and autofill and distinguishes phishing-resistant authentication from manually entered one-time codes. Neither a password manager nor an additional factor makes a recording disappear. They address part of the account-compromise pathway rather than every kind of information leakage discussed here.
Our guide to passwords, passkeys, and two-factor authentication explains the differences among those account protections. Choose controls supported by the organization's services and recovery arrangements. Do not describe an extra authentication factor as a guarantee: its value depends on the factor and the wider authentication process.
These account controls also do not protect every sensitive item someone might type or say. A confidential sentence, source-code fragment, or business decision can matter independently of account access. Match the control to the information at risk rather than assuming stronger login security resolves the whole acoustic question.
Treat Proposed Signal Defenses as Experimental
Adding background noise may sound like an easy answer, but it should not be offered as assured protection. The 2023 keystroke paper discusses possible countermeasures, including changes to typing behavior and added sounds; that is not a universal test proving that a white-noise machine defeats acoustic inference.
If a high-assurance environment needs a signal-level countermeasure, evaluate it against the actual devices, recording positions, and task that matter. Check whether it interferes with communication or accessibility. A familiar product label such as “noise cancelling” does not establish which sounds an untrusted microphone receives or which features a classifier can use.
For ordinary organizational practice, removing unnecessary capture and limiting the audience for sensitive recordings are clearer measures than relying on an untested sound-masking claim. Keep endpoint maintenance, application approval, and access management in place as well; a specialized acoustic concern should not displace those foundational controls. The Cybersecurity Basics hub connects those broader measures.
Respond to Evidence of Unauthorized Capture
If there is evidence of an unauthorized app, meeting participant, or recording, address that observed problem first. Stop unnecessary capture, restrict access to the recording, and preserve relevant access records through the organization's incident process. Identify which information was present and who could receive it.
Reset a credential or revoke a session when the evidence warrants that action, rather than claiming a sound recording proves the credential was recovered. Conversely, uncertainty about the acoustic analysis does not make unauthorized recording harmless. The content of the call itself may already require a confidentiality response.
What Security Teams and Policymakers Should Watch
Better Models Still Need Appropriate Evidence
A February 2025 preprint on transformers and large language models for keyboard attacks explored improved classification and language-based correction. It reused the earlier single-keyboard dataset, with 25 samples per key. Its language-model evaluation used ordinary English sentences assembled from the existing keystroke dataset, with artificial noise added to the spectrograms and space-key performance assumed. These were not new recordings of continuously typed sentences; the original key dataset did not include spaces.
That work is relevant to the direction of research, but it does not show that models now generalize across arbitrary hardware with little prior information. Nor does performance on ordinary English establish reliable reconstruction of random passwords. The authors' limitations concerning the dataset and generalization are essential to interpreting the proposed improvements.
For future papers, useful questions include whether training and testing share a keyboard or person, whether audio is continuous, whether the attacker knows word boundaries, and whether the evaluation includes realistic mistakes. Report whether success means a correct key, word, full secret, or executed action. Those questions make new results comparable without assuming every higher percentage means a more practical attack.
Governance Should Follow the Data and Device
Policy work can address permissions, recording practices, retention, and sensor transparency without declaring that a particular research technique has become commonplace. Organizations can ask vendors what an access indicator represents, what logs are available, and which sensor restrictions apply to their supported devices.
The same discipline should guide purchasing and internal assurance. Ask a defensive vendor which attack path a product addresses and what testing supports its claim. Do not assume an automated detector, noise generator, or microphone control covers unrelated vibration inference and command injection. There is no single result in these papers that establishes such comprehensive protection.
For policymakers, a useful distinction is between improving general data governance and mandating a specific countermeasure for a demonstrated configuration. The former can reduce unnecessary exposure broadly. The latter needs evidence that the required control works for the devices, software, and threat it is supposed to address.
For measured analysis of AI-driven threats and the evidence behind them, subscribe to the Quantum Cyber AI Brief.
Conclusion
AI acoustic side-channel attacks deserve attention because they show that physical signals can carry information beyond a system's intended interfaces. The keyboard studies, EarSpy, and SurfingAttack each make a different contribution to that understanding. Their results are most useful when the task, access requirements, devices, and limitations stay attached to the headline finding.
For professionals and policymakers, the response is to assess the relevant signal path and reduce avoidable exposure. Review microphone permissions, recording audiences, sensitive-work practices, and account protection. Preserve the distinction between a research demonstration and evidence of an actual compromise. That approach supports practical security decisions without turning a classification score into a claim the research did not establish.
FAQ
Does 93 Percent Keystroke Accuracy Mean 93 Percent of Passwords Can Be Stolen?
No. The 2023 Zoom result measured individual-key classification in the tested setup. A full password is a sequence, potentially involving characters and behavior outside the experiment. Recovering it also requires suitable recording access, relevant training, and interpretation. The reported percentage is not a password-recovery or account-compromise rate.
Can an Acoustic Attack Work Without Microphone Permission?
EarSpy studied information inferred from vibrations recorded by accelerometers on particular phones. Its tasks included speaker characteristics and spoken digits, rather than arbitrary conversation transcription or keyboard password recovery. Microphone controls remain useful, while other sensor paths require assessment on their own terms and under the operating system's applicable restrictions.
Does Encryption Protect Against Acoustic Leakage?
Encryption protects the digital data path covered by the encryption system. It does not make the physical sound of typing inaudible. Whether that sound exposes useful information depends on access to a recording and a viable inference method. This is a reason to consider endpoints and recording practices alongside encryption, not a reason to abandon encryption.
Do Headphones or White Noise Solve the Problem?
The presence of headphones or a noise source is not enough to establish protection. The relevant question is which signal reaches the attacker's recording path and what can be inferred from it. Controls should be assessed for the particular device and task; the research discussed here does not provide a universal guarantee for either approach.