Use endpoint device control policies, Defender device control deployed through Intune, or Group Policy where you have no MDM, with a deny-by-default stance and an audit pilot before enforcement. Your main levers are deny-write, allow by hardware ID or class GUID, and attack surface rules that stop unsigned executables from running off USB media. Monitor everything with advanced hunting, and enforce only after the audit data is clean.
TL;DR:
- Inventory business critical USB devices and their class GUIDs, then run a small Audit mode pilot and use advanced hunting to refine the allowlist.
- Use Group Policy for domain joined machines without Intune enrollment, while MDM suits remote laptops; mixed fleets can share one maintained allowlist.
- An installation restriction may not block devices whose drivers were installed earlier, and some encrypted drives need Execute or disk level Write access.
- Intune policies with unique device IDs can exceed the 350,000 character OMA URI limit; split them or group devices to avoid deployment failures.
- Review hunting results weekly during the pilot and monthly afterward, and alert when mounted drives do not match the allowlist.
Table of Contents
- How does Defender for Endpoint device control work?
- What are your options without Intune?
- What does a safe deployment checklist look like?
- How do you monitor and hunt for USB events?
- Why does a device still work after the policy lands?
- Which physical controls and user policies help?
- Why staged, preventative rollout works for small and mid-size teams
- Let us plan, deploy, and run device control for you
- FAQ
- Sources
How does Defender for Endpoint device control work?
Defender for Endpoint device control is a set of endpoint policies that allow or block USB and other peripherals based on device type, hardware ID, and the access requested. For organizations on Microsoft 365, Microsoft Intune is the recommended tool to deploy it, either through custom OMA-URI policies or the Settings Catalog.
Here is what you need to know before you build a policy:
- Controllable device types: RemovableMediaDevices, CdRomDevices, WpdDevices, and PrinterDevices, plus Bluetooth and other classes.
- Default enforcement: you set DefaultEnforcement to Deny or Allow per device type, and identify devices by product family ID.
- Write protection: RemovableDiskDenyWriteAccess gives you read-only removable storage without blocking it outright.
- Deployment paths: the Settings Catalog, or custom OMA-URI rows. Intune exposes reusable settings such as device control profiles and device type lists, but product family IDs and OMA-URI formatting need careful syntax.
- Assignments: a profile does nothing until you add allow and deny rules and assign it to a device group.
Commonly restricted classes include USB bus devices, HID, and imaging devices, each tied to a setup class GUID. You can also build a policy in the Intune Settings Catalog that blocks or allows specific classes and hardware IDs.
What are your options without Intune?
Servers, unmanaged workstations, and hybrid environments often have no MDM in the path. Group Policy and the registry cover those cases. CISA documents Group Policy and registry countermeasures for removable media, and the steps are short:
- Open the Group Policy editor and go to Computer Configuration → Policies → Administrative Templates → System → Removable Storage Access.
- Enable the policy that denies access to removable storage classes you do not need.
- Under System → Device Installation → Device Installation Restrictions, block installation of unapproved device IDs and classes.
- Set the NoDriveTypeAutoRun registry value to disable AutoRun.
- Set the RemovableStorageDevices\Deny_All registry value for machines that should never touch removable media.
Pick Group Policy when a device is domain joined but not enrolled in Intune. Pick MDM for remote and roaming laptops. Many of the environments we manage use both, with a single allowlist maintained as the source of truth. Our Intune guidance for small businesses covers the MDM side in more depth.
What does a safe deployment checklist look like?
The fastest way to break a workflow is to block a device before you know someone depends on it. Microsoft recommends Audit Mode during deployment so you can watch USB activity without disrupting work. Expect an operational adjustment period while allowlists settle.
- Inventory first: list business-critical USB devices and their class GUIDs before you block anything.
- Audit pilot: run a small group in Audit mode, collect advanced hunting data, and refine allowlists by hardware ID and class GUID.
- Staged rollout: pilot, then department waves, then the whole organization, each with a clear notice and a support path.
- Ongoing upkeep: maintain the allowlist, document every exception, and schedule periodic reviews.
Pro Tip: Send users a short notice before each wave that names the policy, the date, and the exact way to request an exception. Surprise can lead to support tickets, so explain the change in advance.
How do you monitor and hunt for USB events?
Enforcement without telemetry leaves you guessing. Collect plug-and-play events, mount attempts, and successful mounts, and ingest them into Defender for Endpoint so you can hunt across the fleet. Microsoft's guidance for device safeguards also points to discovering plug-and-play events and enabling real-time scanning of removable storage.
- List mounted storage: use advanced hunting to see which removable drives mounted, on which machines, and by which user.
- Flag unapproved mounts: compare mounts against your allowlist and turn the gaps into alerts.
- Block execution from USB: Attack Surface Reduction rules can stop untrusted and unsigned executables from running off USB devices, configurable through Group Policy or Intune.
- Review the results: weekly during the pilot, monthly afterward.
Why does a device still work after the policy lands?
Most surprises fall into three buckets:
- Drivers already installed: once a device has been used, an install restriction alone may not stop it. Remove the old driver through Device Manager or Devcon to revoke previously used storage.
- Wrong access mask: some hardware needs more than Read to function. Certain Kingston encrypted drives need Execute for their CD-ROM partition, and some WD My Passport drives need disk-level Write even for basic reads. Check advanced hunting events to find the accessMask the device requires.
- Oversized policies: the OMA-URI XML limit is 350,000 characters, and exceeding it can cause deployment failures when you manage many unique device IDs. Split policies or group devices.
If an allowed device is still blocked, the Intune guide shows how to find class GUIDs and read setupapi.dev.log.
Which physical controls and user policies help?
Software policy covers the endpoint. People and hardware cover the gaps.
- Hardware: use USB port locks on shared machines and USB data blockers for public charging, as CISA recommends.
- Encryption: require encryption on authorized portable media, using something like our BitLocker guide.
- Acceptable use: state who may use removable media, how to request an exception, and how to report a found drive.
- Training: teach staff never to plug in unknown media. Portable media is a common malware vector.
- Hardware keys: for authentication, a security key can help keep legitimate USB use tied to a known device.
Why staged, preventative rollout works for small and mid-size teams
The mistake we see most often is skipping the audit pilot, then discovering at enforcement time that a scanner, a label printer, or a backup drive was never on the allowlist. Discovery is the real work, and it is cheap when done first. I also push clients to pair device control with disk encryption and data loss prevention, because blocking ports reduces exfiltration paths without eliminating them. If you want to see a rollout from start to finish, read our Intune rollout case study.
— Alex
Let us plan, deploy, and run device control for you
We design and operate Intune and Defender device control policies for small and mid-size businesses: the pilot, the allowlist, the staged rollout, and the monitoring that follows. Our Cybersecurity Solutions team adds 24/7 monitoring and incident response, and our Managed IT Services team keeps your endpoints current. You also get help mapping policy to HIPAA, GDPR, and SOC 2 requirements, with rapid on-call support when a device gets blocked. Contact us for a consultation, or ask us to review your Intune rollout.

FAQ
How do I check USB devices on a PC?
Open Device Manager and expand Universal Serial Bus controllers and Disk drives to see connected and previously installed devices. For a fleet, use advanced hunting in Defender for Endpoint to list mounted storage across all machines. Microsoft's FAQ explains how to read the device events.
Do USB data blockers really work?
A USB data blocker can help protect against data transfer when you charge on public ports. CISA recommends them for public charging. They do not replace endpoint policy for drives your own staff plug in.
What is the best way to block USB devices?
Use an endpoint device control policy with a deny-by-default stance and an allowlist by hardware ID or class GUID. Deploy it through Intune and Defender for Endpoint, or Group Policy where MDM is not available. Start in Audit mode so you learn what the business actually uses.
Why does an allowed USB device still get blocked?
The device may need a different access mask, such as Execute or disk-level Write, or its class GUID may be missing from your rule. Check advanced hunting events for the required accessMask. The Intune Settings Catalog guide also covers setupapi.dev.log troubleshooting.
Sources
- Learn
- Microsoft Defender for Endpoint Device Control frequently asked questions - Microsoft Defender for Endpoint | Microsoft Learn
- | CISA
- Restrict USB Devices Using Settings Catalog in Microsoft Intune - Microsoft Intune | Microsoft Learn
