Wireless Peripheral Security Guide: securing keyboards, mice, presenters and headsets

A wireless keyboard is a radio that types into your most trusted computers, and many of the receivers plugged into corporate laptops were never designed to resist someone nearby with a cheap transmitter. Keystroke injection through unencrypted or weakly protected 2.4 GHz receivers, sniffing of typed passwords, presentation clickers that can be turned into keyboards, and headset chips that expose microphones and phone link keys are all documented, with CVE records and vendor fixes. This guide covers keyboards, mice, presenters, headsets and their USB receivers: how the radio links differ, which flaws matter, how to choose and configure peripherals, and how to detect unexpected input devices. It is for endpoint, workplace technology and security architecture teams; general Bluetooth protocol security is covered in the Bluetooth, RFID and NFC Security Guide.

Key takeaways

• Input devices are trusted by default. An operating system accepts keystrokes from anything that presents as a keyboard, so a peripheral link that can be spoofed is a remote typing channel into an unlocked session (MITRE ATT&CK T1200 Hardware Additions).
• Proprietary 2.4 GHz receivers have the worst record. CERT/CC VU#981271 (2016) described receivers that let a nearby attacker inject keystrokes, read keystrokes and pair new devices, and later CVEs showed encryption keys being recovered from receivers and a presentation clicker.
• Headsets are computers with microphones. The 2025 Airoha chip flaws (CVE-2025-20700 to CVE-2025-20702) allowed unpaired attackers within Bluetooth range to read device memory and extract link keys used to impersonate the headset to a paired phone.
• Policy beats preference. Windows can restrict Bluetooth to an allow list of service UUIDs (ServicesAllowedList) and set a minimum encryption key size; most fleets never configure either.
• Buy for updatability and modern pairing. Prefer peripherals that use Bluetooth LE Secure Connections or a receiver built on it, that receive firmware updates through managed tooling, and that match the sensitivity of the room they are used in.

How peripheral radio links differ

Flaws that shaped the field

The issues below are described defensively, to explain what controls need to stop. All CVE records were checked in the CVE list on 11 November 2026; none appear in the CISA Known Exploited Vulnerabilities catalogue.

Two lessons repeat. First, the attacker usually needs to be within radio range, a few metres to around ten, which makes open-plan offices, shared buildings, conference venues and public transport the realistic settings. Second, fixes arrive as peripheral firmware, which many organisations never deploy because nobody owns it. Keystroke injection maps to ATT&CK T1200; sniffing typed input to T1056.001 Keylogging; headset microphone access to T1123 Audio Capture; and Bluetooth data paths to T1011.001 Exfiltration Over Bluetooth.

Keyboards and mice

• Retire legacy receivers: inventory receivers by USB vendor and product ID and replace models that cannot be updated or that rely on proprietary protocols with known flaws. Include mouse-only receivers: VU#981271 covers both wireless keyboards and mice.
• Update firmware centrally: where a vendor offers managed firmware tools, include peripherals in the patch cycle with an owner and a record of versions.
• Pair in a controlled place: pairing is when keys are exchanged. Factory pre-paired receivers or pairing at the IT desk reduce the chance of an observed pairing.
• Prefer passkey or numeric comparison: the vendor documentation for Logi Bolt, for instance, states Level 3 passkey entry for keyboards and Just Works for mice when paired directly over Bluetooth, and Level 4 through the receiver; check the equivalent for your models.
• Lock screens quickly: injection only works against a session that accepts input. Short idle locks and lock-on-leave habits remove most of the impact.
• Wired for the highest-risk machines: privileged access workstations, jump hosts and payment or trading terminals are good candidates for wired input only. See the Privileged Access Workstations Guide.

Presenters, docking stations and meeting rooms

• A presenter is a keyboard: CVE-2019-13054 shows a clicker being turned into a text injection device. Plug presenter receivers only into the presenting machine, remove them afterwards, and avoid leaving them in shared meeting room PCs.
• Meeting room PCs are shared targets: they often stay logged in, run with broad accounts and have receivers attached permanently. Use dedicated low-privilege accounts, locked-down shells and wired or Bluetooth-policy-controlled peripherals.
• Docks and hubs carry receivers too: receivers left in docks follow the user's laptop into every session. Include docks in the inventory.

Headsets and audio devices

• Know the chipset: the Airoha research found that some manufacturers did not know which Bluetooth chip their products used because the module was outsourced. Ask suppliers for the SoC, the firmware update mechanism and the security contact before standardising on a headset.
• Patch the headset, not just the laptop: headset firmware usually updates through a vendor app or management console; assign an owner and track versions.
• Protect the phone link: the 2025 research showed stolen link keys being used to impersonate a headset to a paired phone. For staff whose phones carry authenticator apps or sensitive calls, remove headset pairings that are unpatched.
• Restrict profiles on managed laptops: allow audio profiles only where needed, and do not allow file transfer profiles on corporate endpoints.
• High-risk roles: the ERNW researchers advised that people at higher risk, such as journalists and diplomats, should not rely on Bluetooth headphones; wired headsets are the conservative choice for executives in sensitive discussions. See the Executive Protection and Digital Footprint Guide.

Configuring endpoints

Windows Bluetooth policy

The Bluetooth Policy CSP (./Device/Vendor/MSFT/Policy/Config/Bluetooth/), available through Intune or other MDM, offers settings that most fleets leave at default:

Every profile a device needs must be listed or it will stop working, so build the allow list from a pilot of the headsets and keyboards you actually issue. On macOS and Linux, use MDM restrictions or disable Bluetooth on systems that do not need it, and keep the host Bluetooth stack patched, which addresses host-side flaws such as CVE-2023-45866.

USB receivers and device control

Receivers are USB HID devices, so USB device control can allow known receiver vendor and product IDs and block others on sensitive endpoints. The Removable Media and USB Control Guide and the Thunderbolt, DMA and Peripheral Attack Protection Guide cover the device control mechanics; the USB Drop Attacks Guide covers malicious devices presenting as keyboards.

Choosing peripherals by environment

Small organisations get most of the value from three steps: buy current Bluetooth LE peripherals from vendors that publish firmware updates, enable short screen locks, and use wired input for administrators. Larger organisations should add the Bluetooth policy allow list, receiver inventory and procurement standards.

Rolling out controls

1. Inventory: collect USB receiver IDs and Bluetooth paired-device lists from endpoint management and identify legacy receiver models.
2. Set a standard: publish an approved peripheral list per environment with required firmware levels and an update owner.
3. Pilot the Bluetooth allow list: deploy ServicesAllowedList to a pilot ring with every issued headset and keyboard model; record which UUIDs each needs.
4. Expand in rings: roll out by department, with a help desk script for "my headset stopped working"; rollback is removing the policy and rebooting or reloading the Bluetooth stack.
5. Replace legacy receivers: swap out receivers that cannot be updated, starting with administrators, finance and executives.
6. Lock down high-risk endpoints: disable Bluetooth and enforce wired input on privileged and operational systems.

Detection and measurement

Keystroke injection is hard to see on the wire, so detection focuses on devices and behaviour. Log plug-and-play device connections (Windows Security event 6416 with Audit PnP Activity enabled, or endpoint detection device events), alert on new HID devices on privileged workstations, and watch for keyboard-driven process launches that happen seconds after a new input device appears, such as a run dialog followed by a shell. Wireless intrusion detection can add radio visibility in sensitive spaces; see the Wireless intrusion detection guide.

• Legacy receiver count: endpoints with receiver models on the deny list, trending to zero.
• Firmware currency: percentage of managed headsets and receivers on the current approved firmware.
• Policy coverage: percentage of Windows endpoints with ServicesAllowedList and minimum key size applied.
• Privileged endpoints with wireless input: target zero.
• Unexpected HID events: new keyboard devices on privileged or kiosk systems, each investigated.

Where identity fits

Peripherals do not hold accounts, but they interact with identity in two ways. Injected keystrokes run with the signed-in user's privileges, which is why administrators should use wired input on separate privileged workstations. And headsets paired to phones sit next to authenticator apps and voice-based verification; a compromised headset that can impersonate itself to the phone touches the user's second factor channel. Phishing-resistant authenticators reduce what an attacker can do with either path; see the Hardware Security Keys Guide.

Framework mapping

Common failure patterns

• Peripheral firmware has no owner: receivers vulnerable since 2016 stay in use because peripheral updates are outside every patch process.
• Buying on price: unbranded keyboard bundles with undocumented receivers are bought centrally and issued to administrators.
• Presenters left in meeting room PCs: a receiver that accepts keystrokes stays plugged into a shared, logged-in machine.
• Bluetooth left wide open: discoverable laptops, Swift Pair prompts and every profile allowed, including file transfer.
• Headsets ignored in vulnerability management: chip-level flaws affecting dozens of brands go untracked because headsets are treated as accessories.
• No screen lock discipline: unlocked sessions turn any injection flaw into full user access.

Practitioner checklist

• Inventory wireless receivers and paired Bluetooth peripherals across the fleet.
• Replace legacy proprietary receivers with known flaws or no update path.
• Publish an approved peripheral list per environment with firmware owners.
• Deploy the Windows Bluetooth ServicesAllowedList and minimum encryption key size after a pilot.
• Disable Bluetooth discoverability, Swift Pair prompts and file transfer profiles on managed laptops.
• Use wired input on privileged access workstations and operational systems.
• Treat presenters as keyboards and keep them off shared logged-in machines.
• Track headset chipsets and firmware, and unpair unpatched headsets for high-risk users.
• Alert on new HID devices on privileged endpoints.
• Enforce short idle screen locks.

Standards and references

• CERT/CC: VU#981271 Multiple wireless keyboard/mouse devices use an unsafe proprietary wireless protocol
• Microsoft Learn: Bluetooth Policy CSP
• NIST: SP 800-121 Rev. 2, Guide to Bluetooth Security
• CVE: CVE-2019-13054
• CVE: CVE-2023-45866
• ERNW: Airoha Bluetooth Security Vulnerabilities
• Logitech: Logi Bolt Wireless Technology
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Bluetooth, RFID and NFC Security Guide · Thunderbolt, DMA and Peripheral Attack Protection Guide · Removable Media and USB Control Guide · Wireless Network Security Policy Template