Disable USB Storage

What the Disable USB Storage Worklet does

This Automox Worklet™ disables USB mass storage access on Windows endpoints by writing the RemovableStorageDevices policy keys to the registry. The Worklet targets the USB mass storage class GUID {53f5630d-b6bf-11d0-94f2-00a0c91efb8b} and sets Deny_Read and Deny_Write to 1, which blocks the operating system from mounting any device that enumerates as a USB storage class.

The policy operates at the Windows device class layer, so it covers thumb drives, external hard drives, SD card readers, and mobile phones in mass storage mode. Other USB classes are not touched. Keyboards, mice, signature pads, webcams, audio devices, and USB printers continue to enumerate and work normally on the same endpoint.

Registry entries are created under HKLM:\Software\Policies\Microsoft\Windows\RemovableStorageDevices, which is the same path Group Policy writes when you configure the Removable Storage Access ADMX template. Endpoints managed through Automox and endpoints managed through GPO end up with an identical configuration footprint, so audit tooling that inspects the registry will see the policy applied either way.

The Worklet runs in PowerShell using Get-ItemProperty for the evaluation check and New-Item plus New-ItemProperty for remediation. It runs in the Automox agent context, which already holds SYSTEM-level rights on the endpoint, so no separate elevation step or scheduled task is required.

Why block USB mass storage on Windows

USB mass storage is one of the cheapest paths into and out of an endpoint. An unattended laptop and a thumb drive will exfiltrate a customer database in under a minute. A vendor laptop carrying a worm-loaded autorun image will infect a workstation the moment it is plugged in. Network-layer DLP controls do not see either event because the data never crosses the wire. Disabling the USB storage class at the OS level cuts off the channel that perimeter tooling cannot reach.

The control maps cleanly to common compliance frameworks. PCI-DSS 12.3.10 calls for documented restrictions on removable electronic media. HIPAA Security Rule 164.310(d)(1) requires controls on devices that move electronic PHI. NIST 800-53 MP-7 covers media use restriction. CIS Controls v8 13.5 covers removable media. CIS Benchmarks for Windows 10 and Windows 11 specifically list the RemovableStorageDevices Deny_Read / Deny_Write values this Worklet writes.

This Worklet writes Deny_Read=1 and Deny_Write=1 under HKLM:\Software\Policies\Microsoft\Windows\RemovableStorageDevices on every Windows endpoint in scope, which mirrors the registry values the CIS Benchmarks call for under removable storage controls. Workstations and servers that already match the baseline finish in milliseconds, and the activity log captures any endpoint where a local administrator had cleared the value before the next evaluation re-asserts it.

How USB storage blocking works

1. Evaluation phase: The Worklet calls Get-ItemProperty against HKLM:\Software\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} and reads the Deny_Read value. If the value exists and is non-empty, the endpoint is already compliant and the script writes a confirmation line to the Automox Activity Log and exits 0. If the key or value is missing, the script logs that the policy is not enabled and exits 1 to schedule remediation.

2. Remediation phase: The remediation script reads the $USBPolicy variable, which ships with a default value of Check. Set it to Enable before deploying the policy: the script then calls Test-Path against the RemovableStorageDevices key, creates the USB mass storage class subkey with New-Item when either is missing, and writes Deny_Read and Deny_Write as DWORD values set to 1 via New-ItemProperty. Set $USBPolicy to Disable to call Remove-Item on the class subkey and restore default USB storage behavior. Set it to Check to log current policy state to the Activity Log without making changes. A reboot is required for the kernel-mode policy to take effect on already-mounted endpoints.

USB storage policy requirements

• Windows 10, Windows 11, or Windows Server 2016 and later (the RemovableStorageDevices policy path exists from Windows 7 / Server 2008 R2 onward, but only these versions are in support)

• Automox agent installed and running in its default SYSTEM context, which already has the rights needed to write under HKLM:\Software\Policies

• PowerShell 5.1 or PowerShell 7 available on the endpoint (the script uses only built-in cmdlets: Get-ItemProperty, Test-Path, New-Item, New-ItemProperty, Remove-Item)

• Set the $USBPolicy variable in the remediation script: Enable blocks USB storage, Disable removes the block, Check reports current state to the Activity Log without making changes

• Reboot allowed within the maintenance window; the kernel does not unload the in-use usbstor stack until the next boot

• No conflicting Group Policy writing the same RemovableStorageDevices subkey (GPO refresh will overwrite the Worklet's values every 90 minutes if both are active)

Expected USB storage state after remediation

After the endpoint reboots, plugging in a thumb drive, an external SSD, or a phone in USB mass storage mode produces no drive letter and no entry in File Explorer. The device still enumerates in Device Manager under Universal Serial Bus controllers, but the storage volume does not mount and read or write operations against the device class are denied at the kernel level. End users see the device appear and then nothing happens. The Automox Activity Log records exit code 0 on the next evaluation run.

Validate the policy directly by running Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}' and confirming Deny_Read and Deny_Write both return 1. Validate functionally by inserting a known-good USB drive and confirming that diskpart list disk does not show the device and that no removable volume appears under Get-Volume. Non-storage USB peripherals (keyboard, mouse, webcam, USB-to-serial adapters, signature pads, USB printers) remain fully functional, which you can confirm by inspecting Get-PnpDevice -PresentOnly output for the unchanged class GUIDs.

To roll the policy back on a specific endpoint, set $USBPolicy to Disable and run the Worklet again. The remediation script calls Remove-Item against the class subkey, the registry returns to its default state, and USB mass storage mounts on the next device insertion (a reboot is not required for the unblock direction). For audit evidence, capture the Activity Log entry for the policy run alongside the registry snapshot from Get-ItemProperty; together they prove the endpoint moved from non-compliant to compliant under a known policy run identifier.