Defender device control lets you block and audit USB storage

When I review Microsoft 365 environments, unmanaged USB storage is almost always a blind spot. Malicious insiders and data leaks are part of the picture, but the problem is often more mundane. Someone loses a stick with sensitive files on it, or a user copies data locally because cloud sync is too slow. Device control USB with Defender for Endpoint and Intune gives us practical, policy-driven control at the endpoint and, just as important, visibility into what people actually plug in.

Intune policies and Defender logging drive USB device control together

Intune's endpoint security blade (Endpoint security → Attack surface reduction → Device control) is where you build and assign device control policies for Windows endpoints. Defender for Endpoint enforces them. You can block USB storage devices, allow them or set them to read-only, and you can scope each rule by vendor ID, product ID or serial number. In practice that means blocking generic USB keys while still permitting approved encrypted models, or even individual devices, all managed from one place.

I always recommend running device control in audit mode before you switch to blocking. There are usually far more odd sticks, old backup drives and USB-to-Ethernet dongles in circulation than anyone expects, and audit mode tells you who is using them. All device control USB events end up in the Defender portal, where Advanced Hunting shows every access and every policy match.

The diagram below shows how the pieces fit together:

flowchart TD
  Policy["Device control policy Intune"] --> Client["Windows endpoint"]
  Client --> Defender["Defender for Endpoint"]
  Defender --> Hunting["Advanced Hunting Portal"]
  Client -- "USB drive inserted" --> Policy
  Policy -- "Block/Read-only/Audit" --> Client
  Client -- "Event" --> Defender
  Defender -- "KQL query" --> Hunting

Figure: How Intune, Defender and Advanced Hunting work together for device control USB

After deployment, the audit data quickly shows whether users still depend on unapproved media, or whether some team has a critical exception nobody remembered.

Vendor IDs and serial numbers handle groups, exceptions and encrypted sticks

Intune's device control USB settings turn out to be quite flexible in day-to-day use. I often build assignments around vendor/product IDs or serial numbers. That way I can block all generic drives and still grant access to specific encrypted company sticks or certified media. For some teams read-only mode is the right balance, because files can be fetched from the device but nothing can be copied onto it. The usual building blocks look like this:

• Block all USB storage by default
• Allow only devices with specific serial numbers
• Permit only encrypted (BitLocker) media
• Give selected device groups read-only access
• Handle mobile devices (phones etc.) separately

Once you save the policy in Intune, it applies at the next device sync, provided Defender for Endpoint is licensed and onboarded and the endpoints run at least Windows 10 22H2. Microsoft's documentation has screenshots and more detail and is worth reading (Device Control Overview).

Audit mode shows you what breaks before you block anything

Starting device control USB in audit mode is the most reliable way to avoid chaos. You capture every attempt to use a USB drive, see which hardware people really use and spot false positives before anything gets blocked. Once you know which serial numbers, vendors or models are legitimate, it's much easier to put them on an allow-list and switch everyone else to block or read-only.

You rarely need PowerShell scripts for this. All the data lands in Defender's central logs, and you can query it straight from the portal. A quick look usually turns up the corner cases as well as any urgent exceptions you need to document. That is far less stressful than dealing with angry users on the day the block goes live.

Pro tip: Always audit before you enforce. It spares you the emergency tickets when someone's last-resort USB backup suddenly stops working.

A short KQL query surfaces every USB event in Advanced Hunting

Most of the value of device control USB comes from Defender for Endpoint's logging. In the Defender portal → Investigation & response → Hunting → Advanced hunting (you'll need the right RBAC role and a Defender for Endpoint Plan 2 licence), one simple KQL query returns every USB-related event:

DeviceEvents
| where ActionType startswith "RemovableStorage"

The results include every insert, policy block and read/write access, along with vendor, model and serial numbers. I rely on that when tuning a policy, and it's just as useful when you investigate a possible data leak or risky device use. For deeper analysis you can correlate these events with other protection features, for example Attack Surface Reduction rules. My hands-on write-up on rolling out ASR rules with Intune and Microsoft's documentation on ASR policies in Intune cover that side.

USB device control has become a baseline requirement in my view

This used to be something only high-security or regulated industries bothered with. Today I see it as a baseline for any organisation that has sensitive data, remote workers or simply compliance requirements. Defender for Endpoint and Intune make USB device control practical and auditable, and starting in audit mode keeps disruption low. If you haven't started yet, put a device control USB audit on your roadmap. That applies even more if you're piloting Copilot or handling AI workloads, because this is the next step in securing your endpoints.