Disable USB Storage

What the USB Storage Blocker does

This Automox Worklet™ blocks access to USB removable storage endpoints by configuring Windows endpoint installation policies through the registry. The Worklet targets the specific endpoint class GUID for USB mass storage ({53f5630d-b6bf-11d0-94f2-00a0c91efb8b}) and sets both Deny_Read and Deny_Write values to prevent any data transfer.

The policy operates at the Windows endpoint class level, which means it blocks all USB mass storage endpoints including thumb drives, external hard drives, SD card readers, and mobile phones in USB storage mode. Other USB endpoint classes remain unaffected, so keyboards, mice, printers, and other non-storage peripherals continue to work normally.

The Worklet creates registry entries under HKLM:\Software\Policies\Microsoft\Windows\RemovableStorageDevices to enforce the storage restriction. This approach uses the same mechanism as Group Policy, making it compatible with enterprise management tools and audit processes.

Why block USB storage on endpoints

USB storage endpoints represent one of the most common vectors for data exfiltration and malware introduction. Employees can intentionally or accidentally copy sensitive files to personal drives, and malicious actors can use USB endpoints to bypass network-based security controls. Blocking USB storage reduces the risk of data loss prevention (DLP) violations and insider threats.

Many compliance frameworks require organizations to control removable media access. PCI-DSS requirement 12.3.5 addresses removable electronic media usage. HIPAA security rules require controls on endpoints that can transfer electronic protected health information. CIS Controls include removable media restrictions as part of data protection measures.

USB storage restrictions also protect against BadUSB attacks and USB-based malware that can autorun when endpoints are connected. By preventing USB storage mounting entirely, you eliminate this attack vector regardless of the specific malware technique used.

How USB storage blocking works

1. Evaluation phase: The Worklet checks for the existence of the Deny_Read registry value at HKLM:\Software\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}. If the value exists and is populated, USB storage blocking is already enabled. If the registry key or value is missing, the endpoint requires remediation.

2. Remediation phase: The Worklet creates the RemovableStorageDevices registry path if it does not exist, then creates the endpoint class subkey for USB mass storage. It sets both Deny_Read and Deny_Write DWORD values to 1, which blocks all read and write operations to USB storage endpoints. A reboot is required for the policy to take effect.

USB storage policy requirements

• Windows 7 or later, Windows Server 2008 R2 or later

• Administrative privileges to modify HKLM registry

• Reboot required after remediation for policy to take effect

• No conflicting Group Policy settings for removable storage

Expected USB access state after remediation

After the endpoint reboots, USB mass storage endpoints will not be accessible. When users connect a thumb drive or external hard drive, Windows will not assign a drive letter or allow access to the storage contents. Users may see the endpoint in endpoint Manager but cannot read from or write to it. You can verify this change through the Automox Activity Log or by checking the endpoint configuration directly.

You can verify the policy by checking the registry at HKLM:\Software\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} for Deny_Read and Deny_Write values set to 1. Non-storage USB endpoints like keyboards, mice, webcams, and audio endpoints remain fully functional.

How to validate disable usb storage changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for disable usb storage.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Test-RegistryValue, Write-Output, Get-ItemProperty.

4. Validate remediation effects from script operations such as Test-RegistryValue, Write-Output, Get-ItemProperty, then rerun evaluation for compliance.