Connexion
NanoKVM (Original) and it’s ‘Secret’ Microphone – Should You Be Worried?
Is the Sipeed NanoKVM Safe? On-board Microphone Identified
The Sipeed NanoKVM Cube is a low cost, network connected KVM built around the LicheeRV Nano RISC-V module, and recent reporting has drawn attention to the fact that this first generation hardware quietly inherited an onboard analog microphone from that core board. While the LicheeRV Nano documentation clearly lists audio input and output capabilities, the NanoKVM product materials initially focused on its KVM role and did not prominently call out the presence of a microphone on the internal PCB. That gap in presentation, combined with the device’s origin in China and its role as an always-on, remotely accessible appliance, has led to questions about transparency and potential privacy impact. This article reviews what is actually on the hardware, how Sipeed has responded, which issues have been addressed in software, and what residual risk remains for users who already have the NanoKVM Cube deployed.
The NanoKVM Cube and That Microphone – What We Learned?
The initial detailed public discussion of the NanoKVM Cube microphone came from a Telefoncek.si research article, which documented security testing of early units and highlighted the presence of a small, operational microphone on the device’s PCB. The NanoKVM Cube is built on the LicheeRV Nano platform, and that design decision is the origin of the audio hardware. The LicheeRV Nano specification explicitly lists an onboard analog silicon microphone for audio input and a PA amplifier for driving a small speaker, because the module is intended as a general purpose SBC for a range of embedded applications. When Sipeed used this module as the core of a consumer facing KVM, the Cube inherited that audio circuitry intact, including the tiny surface mount MEMS microphone, even though typical KVM usage does not require audio capture capabilities.
What Telefoncek.si article from Feb ’25 drew attention to was the combination of this hardware and a software stack that already contained working audio tooling. Researchers who obtained early NanoKVM units found that, with SSH access, standard ALSA tools such as amixer and arecord could be used to adjust gain and record ambient sound through the built in microphone, and that the resulting audio files could be copied or potentially streamed off the device. At that time, the NanoKVM product page described its relationship to the LicheeRV Nano SDK and resources in general terms, but did not highlight that a functioning microphone remained present on the KVM board. For many users, that gap between what the SBC documentation said and what the KVM product page emphasized was perceived as a lack of clear disclosure rather than a predictable consequence of module reuse.
The NanoKVM Security Concern and Presentation Issues
The initial concern around NanoKVM security was not limited to the microphone. Early firmware builds shipped with default credentials, SSH enabled, weak web security controls, and hardcoded encryption keys that were identical across devices. Researchers also found diagnostic and security utilities present on the system image that were more appropriate for development or lab use than for a small appliance likely to be exposed on home or small business networks. These findings created a picture of a product that had been moved from prototype to retail relatively quickly, with baseline functionality in place but limited attention paid to hardening or least privilege.
Presentation played a significant role in how the microphone issue was perceived. For the LicheeRV Nano SBC, the presence of audio input and output is clearly listed as part of the hardware specification, and that makes sense for a general purpose module. For NanoKVM Cube, the public facing documentation initially focused on KVM features, HDMI input, and compatibility with the LicheeRV Nano SDK, while leaving the inherited audio hardware implicit. Only later did the NanoKVM wiki entry gain explicit wording that the Cube retains display, touch, microphone, and amplifier circuits from the base module, and that newer firmware versions would remove the relevant drivers and future production runs would omit these components entirely.
Sipeed’s public responses combine these two aspects. On the one hand they point to the LicheeRV Nano documentation and the updated NanoKVM wiki as evidence that the microphone is not intended to be secret. On the other hand they argue that, from a threat model perspective, the presence of a board level microphone does not materially change risk once an attacker has obtained full control of the device, since they could already perform sensitive actions through the host system. For critics, the issue is less about the technical possibility of audio capture in a fully compromised scenario and more about expectation and trust: a network attached KVM marketed primarily on its remote control capabilities but not clearly calling out built in audio capture hardware is likely to be treated with more suspicion, especially when it comes from a vendor that has already needed several rounds of security fixes.
Reality Check – How Much of a Concern is this?
From a strict security engineering viewpoint, the onboard microphone in the NanoKVM Cube does not create a new, independent way into the device. An attacker still needs a working exploit, exposed service, or misconfiguration to gain sufficient access before any audio capture is possible. In that sense, the primary risk is still the usual set of issues that apply to any IP KVM: exposed management interfaces, weak credentials, unpatched firmware, or poor network segmentation. If those fundamentals are handled correctly, the probability that a remote attacker can turn the Cube into a listening device is significantly reduced, and using alternative firmware or a locked down software stack can further narrow the options.
The impact side of the equation is different. Once a NanoKVM Cube is compromised at a system level, the presence of a functional microphone increases the potential harm compared with a KVM that only relays keyboard, video, and mouse. A device that sits in a home office, lab, or equipment room and can capture ambient sound can turn a general compromise into a privacy incident that extends beyond the connected host system. For some users that incremental risk will be acceptable if the device is strictly isolated, regularly updated, and treated as an untrusted appliance at the edge of the network. For others, the residual possibility of room audio capture from a small, unattended box may be enough to justify either physical removal of the mic, replacement with a later hardware revision, or avoiding this particular model altogether.
Note. Here is the board view of the NanoKVM USB and NanaKVM Pro PCIe, with no microphone visible:
|
|
|
|
Asking Sipeed Questions about the NanoKVM Microphone Issue – How and Why This Occurred?
To clarify how the microphone ended up in a shipping KVM product and what Sipeed intends to do about it, I put a series of written questions to the company. The goal was not to reassess the technical findings already covered by independent research, but to obtain clear statements from the vendor on 4 points: how they view the documentation and disclosure around the microphone, which specific NanoKVM variants and hardware revisions include it, what mitigations they believe limit its security and privacy impact for existing deployments, and what concrete changes they are planning for future production runs. The questions and Sipeed’s responses are reproduced in full below. Thanks again to Caesar Wu for his time in answering my questions.
Why was there a microphone on the device, and how/why it’s absent from the documentation?
This premise contains a serious factual error made by the original article. The presence and rationale for the microphone are not undocumented; they are explicitly mentioned on the product’s main Wiki page: https://wiki.sipeed.com/hardware/en/kvm/NanoKVM/introduction.html#NanoKVM
Which Version/Batch/Revisions of NanoKVM feature this Microphone?
The microphone is featured on the NanoKVM Lite and NanoKVM Cube versions. These are derivative products based on the LicheeRV-Nano (RISC-V SBC core module) and consequently inherited its Single Board Computer (SBC) peripherals, including the microphone, speaker, and MIPI touchscreen support.
Is this present on other versions of NanoKVM (i.e PCIe, Pro, USB, etc)?
No. Other products use custom-designed boards dedicated solely to the KVM scenario. They do not reuse the SBC module and therefore do not include non-KVM-essential components.
Why was this microphone not eliminated at the point of production?
The core part of NanoKVM-Cube/Lite is LicheeRV Nano. We reuse LicheeRV Nano as a standard “SOM” in many different products, like AI Camera MaixCAM: https://www.aliexpress.com/item/1005006912917562.html . And our toB customer also use it as a standard linux core board(Just like RPi CM4, CM5), they are very satisfied with the onboard microphone, speaker, and touch screen. As stated in my previous email, we maintain that logically, the retention of the microphone on the board does not introduce any negative impact on security. While the onboard components (microphone, speaker power amplifier (PA), and touchscreen connector) introduce a slight increase in Bill of Materials (BoM) cost, this decision significantly simplifies inventory management.
In fact, the base LicheeRV Nano product already comes in 4 configuration variants (Basic, Eth, WiFi, and Ethe+WiFi). If we were to further segment the inventory by adding options for the presence or absence of the microphone and touchscreen connector, the total number of SKUs would increase exponentially(the number of SKUs multiplies by two for every added configuration options). Therefore, based on a comprehensive consideration of security, cost efficiency, and inventory management complexity, we maintain the microphone, speaker PA, and touchscreen connector as the default base configuration.
What steps are being taken to ensure that this does not pose a Security/Privacy threat to user who have the nanoKVM in active deployment?
Users must understand the threat model: an attacker can only listen via the onboard mic if the NanoKVM itself has already been fully compromised. The paradox is that once compromised, the attacker already has sufficient privileges to perform high-level operations (include record audio via PC’s own mic). Therefore, the presence of the onboard mic does not increase the inherent security risk of the device. We emphasize that proper network risk awareness and isolation configuration by the user are essential, regardless of whether the device is a NanoKVM, JetKVM, GL.iNet KVM, or PiKVM.
What further steps have been made/planned at Production to avoid this occurring again in future hardware releases?
As stated in Question 4, we plan to remove the microphone in the next batch of the Lite/Cube models purely for psychological comfort and ease of mind for our users. We acknowledge this step will inevitably increase our inventory management complexity due to the need for separate SKUs and production processes. We are also implementing more rigorous hardware audits to ensure compliance with the Principle of Least Privilege in future designs.
Conclusion – Should NanoKVM Owners Be Worried?
For current NanoKVM Cube owners, the level of concern depends largely on how and where the device is deployed. In a well segmented environment where the KVM sits on an isolated management network, with updated firmware and strong access controls, the presence of a dormant microphone on the board is a secondary issue behind the more general risk of any remote management appliance. In small or less structured setups where the NanoKVM has direct exposure to the internet or shares a LAN with everyday client devices, both the historical software weaknesses and the possibility of audio capture in a successful compromise are more relevant factors in deciding whether to keep using the unit unchanged.
Looking ahead, Sipeed has stated that newer firmware removes the audio drivers and that future Lite and Cube batches will omit the microphone and related circuitry entirely, which addresses the concern for new buyers over time. For existing devices, users who are uncomfortable with any residual audio capability have practical options: physically removing or disabling the mic at board level, reflashing with a minimal or community maintained software stack, or replacing the hardware with a later revision or a different KVM platform. The key is to treat the NanoKVM Cube as a high impact management tool rather than a neutral accessory, and to decide whether its cost and feature set justify the additional precautions it requires in a given environment.
SUBSCRIBE TO OUR NEWSLETTER [contact-form-7]
Join Inner Circle Get an alert every time something gets added to this specific article!
Subscribe
This description contains links to Amazon. These links will take you to some of the products mentioned in today's content. As an Amazon Associate, I earn from qualifying purchases. Visit the NASCompares Deal Finder to find the best place to buy this device in your region, based on Service, Support and Reputation - Just Search for your NAS Drive in the Box Below
Need Advice on Data Storage from an Expert?
Finally, for free advice about your setup, just leave a message in the comments below here at NASCompares.com and we will get back to you.
Need Help?
Where possible (and where appropriate) please provide as much information about your requirements, as then I can arrange the best answer and solution to your needs. Do not worry about your e-mail address being required, it will NOT be used in a mailing list and will NOT be used in any way other than to respond to your enquiry.
[contact-form-7]
TRY CHAT
Terms and Conditions
Ko-fi or old school Paypal. Thanks!To find out more about how to support this advice service check HEREIf you need to fix or configure a NAS, check Fiver
Have you thought about helping others with your knowledge? Find Instructions Here
|
|
|
