Removable Media and USB Control Guide: Device Control and Encryption

A USB port is an unauthenticated path for data out of the organisation and for code and fake keyboards into it, and most endpoints still leave it open by default. Removable media control has to handle three different problems at once: data leaving on drives, malware arriving on drives, and malicious devices that are not storage at all. This guide covers removable media policy and governance, device control and device installation restrictions, USB allowlisting, encrypted USB drives and BitLocker To Go, content aware device control and USB DLP, removable media scanning, and the USB-borne threats (BadUSB, keystroke injection, USB drop attacks and worms such as Raspberry Robin) that drive the controls. It is written for endpoint engineers, Windows and macOS administrators, data protection teams and SOC analysts.

Key takeaways

• Default deny, then allow by exception. Block removable storage for everyone, then allowlist approved, encrypted drives by vendor ID, product ID or serial number for the users who need them.
• Storage control is not device control. Removable storage policies stop drives; only device installation restrictions or hardware allowlisting stop a malicious USB device that presents itself as a keyboard.
• Write only to encrypted media. Denying write access to removable drives not protected by BitLocker, or to anything other than approved hardware-encrypted drives, turns lost drives into non-events.
• Use content awareness where blocking is too blunt. USB DLP that inspects sensitivity labels and content lets you allow drives for most files and stop copies of regulated data.
• Audit before you enforce. Run device control in audit mode, read the events, build the allowlist from real usage, and pilot in rings so you never lock users out of keyboards or boot disks.

Why removable media still matters

Removable media covers USB flash drives, external disks, SD cards, optical media, phones mounted as storage and any other device that creates a drive letter or mounts as a volume. MITRE ATT&CK tracks the three main abuse patterns separately:

Baiting works. In a study published at IEEE Symposium on Security and Privacy, researchers dropped 297 flash drives on a university campus, estimated a success rate of 45% to 98%, and saw the first drive connected in under six minutes. Worms still spread this way too: Microsoft reported in October 2022 that Raspberry Robin, which spreads through a shortcut (LNK) file disguised as a folder on a USB drive, had triggered alerts on nearly 3,000 devices in almost 1,000 organisations in 30 days, and linked later activity to Clop ransomware deployments. See the Malware Guide for the wider malware picture.

Removable media policy and governance

Technical controls need a written removable media policy behind them, or every exception becomes a negotiation. A workable policy answers six questions:

• Is removable storage allowed at all? The default should be no, with named business cases such as field engineers, forensics, studio media or offline transfer to OT networks.
• Which devices? Only organisation-issued drives, ideally hardware-encrypted models validated to FIPS 140-3, registered in an inventory by serial number.
• Which data? Whether regulated or highly confidential data may ever be written to removable media, and under what approval.
• Read, write or both? Many roles need to read supplier media but never write to it.
• Who approves and for how long? Time-limited exceptions, owned by a manager and reviewed at least quarterly.
• What happens to found or returned media? Found drives go to IT unopened; returned drives are wiped to NIST SP 800-88 media sanitisation guidance before reissue.

Removable media governance then becomes measurable: an inventory of approved devices, a register of exceptions, and audit events that show whether the policy is followed. Lost devices follow your incident process; see the Lost or Stolen Device Response Checklist.

Control options compared

Windows offers several overlapping mechanisms. They operate at different layers and are often combined.

The Endpoint Security Guide places these controls in the wider endpoint stack.

Device installation restrictions

Device installation restrictions live under Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions (or the equivalent Intune administrative template). They decide whether Windows will install a driver for a device at all, which makes them the only built-in control that also stops a rogue keyboard or network adapter.

• Prevent policies: Prevent installation of devices that match these device IDs, Prevent installation of devices that match any of these device instance IDs, Prevent installation of devices using drivers that match these device setup classes, and Prevent installation of removable devices.
• Allow policies: the matching Allow installation of devices ... policies for device IDs, instance IDs and setup classes.
• Layered evaluation: Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria evaluates device instance IDs, then device IDs, then setup classes, then removable devices, so a specific allow can override a broad prevent. Without it, every Prevent policy beats every Allow policy.
• Retroactive option: Also apply to matching devices that are already installed removes devices already present. Use it with care: Microsoft warns that blocking the disk drive or network class this way can make a machine unusable.
• Local administrators: Allow administrators to override Device Installation Restriction policies exempts local Administrators. Leave it disabled and remove standing local admin rights, or anyone with admin rights can bypass the whole control. See the Endpoint Privilege Management Guide.

To block all USB devices except approved ones, Microsoft's worked example prevents the USB Bus Devices class {36fc9e60-c465-11cf-8056-444553540000} and the USBDevice class {88BAE032-5A81-49f0-BC3D-A4FF138216D6}, enables layered evaluation, and then allows the approved device IDs plus the whole parent chain of host controllers and hubs. Miss a hub or host controller and keyboards and mice stop working, so build and test the allow list in a lab first.

Defender for Endpoint device control and USB allowlisting

Microsoft Defender for Endpoint device control applies to devices that create a disk, printers and Windows Portable Devices, on Windows 10 and 11 and on macOS. Microsoft notes that "By default device control is disabled, so access to all types of devices is allowed." A device control policy is built from groups, rules and entries:

• Groups: sets of devices matched on properties such as PrimaryId, VID_PID, SerialNumberId, InstancePathId, HardwareId, BusId, FriendlyNameId, and DeviceEncryptionStateId (BitlockerEncrypted or Plain, in preview), combined with MatchAll, MatchAny, MatchExcludeAll or MatchExcludeAny.
• Entries: an action of Allow, Deny, AuditAllow or AuditDeny, an AccessMask (1 device read, 2 device write, 4 device execute, 8 file read, 16 file write, 32 file execute, 64 print), and optional user, machine or network conditions.
• Default enforcement: Allow or Deny for anything no rule matches. A USB device control policy for most organisations sets Deny, with explicit allow entries for approved devices.

A typical USB allowlist has three tiers: approved encrypted drives (by serial number) get read and write for a named group; any other storage gets read only, or nothing; and all denied attempts generate an event. Matching on VID and PID allows a whole drive model, which is easier to run; matching on serial number pins access to issued devices, which is stronger against look-alike hardware but needs an inventory process. Intune is Microsoft's recommended management tool, and because Intune does not honour rule ordering, exclude out-of-scope groups explicitly.

On macOS, Defender device control covers USB removable media, iOS devices and APFS encryption state, and Apple's declarative device management offers a disk management configuration (com.apple.configuration.diskmanagement.settings, macOS 15 and later, supervised devices) that can set ExternalStorage and NetworkStorage to Disallowed or read-only. See the macOS Security Guide for Enterprises.

Encrypted USB drives and BitLocker To Go

Removable media encryption (USB encryption) protects data on media that leaves the building. There are two models:

• Software encryption (BitLocker To Go): the Group Policy Deny write access to removable drives not protected by BitLocker (Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives; registry value RDVDenyWriteAccess; Intune BitLocker CSP node RemovableDrivesRequireEncryption) mounts any unencrypted removable drive read-only. Its option Deny write access to devices configured in another organization, with the identifiers set in Provide the unique identifiers for your organization, stops staff writing to drives encrypted elsewhere. Microsoft recommends XTS-AES and defaults to XTS-AES 128-bit when no cipher policy is set. Note that enabling Removable Disks: Deny write access under Removable Storage Access overrides this policy.
• Hardware-encrypted USB drives: an encrypted USB drive with on-board encryption, PIN entry or management software works across operating systems and cannot be written unencrypted. Choose models with FIPS 140-3 validation, brute-force wipe, and central management if you issue many.

Software encryption is cheap and centrally recoverable through BitLocker key escrow; hardware drives suit mixed-platform users and data exchange with partners. Either way, combine encryption with device control so only issued encrypted drives are writable. The Encryption Guide covers algorithms and key handling.

Content aware device control and USB DLP

Blocking is blunt. Content aware device control inspects what is being copied: Microsoft Purview Endpoint DLP, for example, can block, warn or audit the Copy to USB removable device activity based on sensitive information types and sensitivity labels, on Windows 10 and 11, Windows Server 2019 and later, and recent macOS versions. Use USB DLP when drives must stay usable for ordinary work but regulated data must not leave, and pair it with device control rather than replacing it: DLP does not stop a keyboard injection device or malware arriving on a drive. Classification is the prerequisite; see the Data Loss Prevention (DLP) Guide and the Data Exfiltration Guide for removable media exfiltration among other channels.

USB-borne threats: malware, BadUSB and baiting

• USB borne malware: Raspberry Robin's LNK file launched cmd.exe, which started msiexec.exe to fetch a payload from compromised network storage devices. Microsoft's recommended mitigations included preventing autorun and two attack surface reduction rules: Block untrusted and unsigned processes that run from USB, and Block execution of potentially obfuscated scripts. Also turn off AutoPlay and set AutoRun to not execute any commands, and deny the execute right on removable storage where device control is available.
• Removable media scanning: enable on-access and scheduled scanning of removable drives in your anti-malware platform (in Microsoft Defender Antivirus, the Scan removable drives setting). Where media must cross into isolated or OT networks, use a dedicated scanning station and transfer only after a clean scan. See the OT Security Guide.
• BadUSB and USB keystroke injection: a BadUSB (bad USB) device has firmware that announces itself as a human interface device and types commands at machine speed. Commercial keystroke injection tools such as the USB Rubber Ducky are the archetype defenders look for. Storage policies do not see these devices, so use device installation restrictions to block new keyboard and network adapter classes on high-risk hosts, lock screens when unattended, and detect new HID devices followed immediately by shell activity.
• USB drop attacks and baiting: default-deny policies neutralise most of the risk; awareness training and a simple route to hand in found media handle the rest. See the Security Awareness and Human Risk Management Guide.
• Charging ports: a USB data blocker (often called a USB condom) passes power but not data, which is useful for staff charging devices from untrusted ports.

Detection and measurement

Useful detection logic, described in words: a new HID keyboard on a server or kiosk followed within seconds by a command shell or script host; processes started from a removable drive letter; a burst of file reads on file shares followed by large writes to removable storage; and repeated AuditDeny events from one user. Forward these events centrally; the Windows Event Log Guide covers collection. Metrics that show the programme is working:

• Coverage: percentage of endpoints with device control in enforce mode, not audit.
• Encryption: percentage of writes to removable media that went to encrypted or approved devices (target 100%).
• Exceptions: number of active removable media exceptions and percentage reviewed on time.
• Blocked attempts: denied events per week, trended, with repeat offenders followed up.
• Sensitive copies: DLP blocks and overrides for USB, and the share justified by business reason.

A phased rollout

1. Discover: enable Audit PNP Activity and Audit Removable Storage, and deploy device control with AuditAllow entries only. Collect two to four weeks of data on which devices, users and hosts actually use removable media.
2. Decide: agree the removable media policy, approved device list and exception process with data owners and the business.
3. Quick wins: turn off AutoRun and AutoPlay, enable the two USB attack surface reduction rules in audit then block mode, and enable removable drive scanning.
4. Pilot: apply default Deny with allow entries to an IT ring, then a small business ring. Test keyboards, docking stations, headsets, smart card readers and printers, since some are composite USB devices.
5. Enforce: roll out in rings, add BitLocker write protection or approved hardware-encrypted drives, and switch device installation restrictions on for kiosks and servers.
6. Roll back: keep the previous policy version in Intune or Group Policy so a ring can be returned to audit mode in one change; for device installation restrictions, never enable the retroactive option until the allow list is proven.

Small and large organisations

• Small organisations: a removable storage access policy (All Removable Storage classes: Deny all access) to block removable storage, BitLocker write protection for the few who need drives, and AutoRun off give most of the benefit without new tooling.
• Large organisations: device control with per-group allowlists by serial number, Endpoint DLP for content awareness, central event collection and an automated exception workflow. Separate policy sets for servers, kiosks, OT engineering workstations and standard users.

Framework mapping

In NIST CSF 2.0 these controls sit mainly in PR.PS (platform security), PR.DS (data security) and DE.CM (continuous monitoring).

Common failure patterns

• Audit mode forever: device control deployed in audit, reports never read, enforcement never switched on.
• Storage blocked, keyboards ignored: removable storage access policies in place but no control over new HID devices, so keystroke injection still works.
• Local admins bypass everything: users with standing admin rights uninstall agents or benefit from the administrator override.
• Allowlist by model only: approving a popular drive model by VID and PID lets any personal drive of that model through.
• Encryption without write control: encrypted drives are issued, but unencrypted drives remain writable, so staff use whatever is in their pocket.
• Lockout during rollout: blocking USB classes without the host controller and hub chain, or using the retroactive option too early, leaves machines without keyboards or disks.

Practitioner checklist

• Publish a removable media policy with default deny, approved devices and a time-limited exception process.
• Enable Audit PNP Activity and Audit Removable Storage and collect the events centrally.
• Deploy device control in audit mode, then default Deny with allow entries for approved drives by serial number.
• Require BitLocker or approved hardware-encrypted drives for any write to removable media.
• Turn off AutoRun and AutoPlay and enable the USB attack surface reduction rules.
• Enable removable drive scanning and a scanning station for media entering isolated networks.
• Use device installation restrictions to block new HID and network adapter classes on servers and kiosks.
• Remove standing local admin rights and disable the administrator override.
• Apply USB DLP to labelled and regulated data where drives must remain usable.
• Track enforcement coverage, exceptions and blocked attempts every month.

Standards and references

• Microsoft Learn: Device control in Microsoft Defender for Endpoint
• Microsoft Learn: Device control policies in Microsoft Defender for Endpoint
• Microsoft Learn: Manage device installation with Group Policy
• Microsoft Learn: BitLocker CSP
• MITRE ATT&CK: T1091 Replication Through Removable Media
• MITRE ATT&CK: T1200 Hardware Additions
• Microsoft Threat Intelligence: Raspberry Robin worm part of larger ecosystem facilitating pre-ransomware activity
• Google Research: Users Really Do Plug in USB Drives They Find

Related NHI Mgmt Group resources: Endpoint Security Guide · Top 10 Endpoint Security Risks · Data Loss Prevention (DLP) Guide · Insider Threat Programme Guide · Application Allowlisting Guide