USB device auditing on Windows means tracking three things: when a device connects, what files move to or from it, and whether your device-control policy stopped what it was supposed to stop. Windows can record all three. Almost none of it is enabled by default.
Honeywell’s 2025 Cyber Threat Report counted 1,826 unique USB-borne threats in the first quarter of 2025 alone, including 124 that were completely new. These findings came from Secure Media Exchange scanning stations at industrial sites. The report also showed that USB plug-and-play activity caused a quarter of the top ten incidents handled by Honeywell’s monitoring and incident response service. For compliance, NIST SP 800-53 Rev. 5 control MP-7 (Media Use) requires organizations to restrict removable media and provide evidence of this.
This guide maps which Windows log sources track USB activity, the tools that collect and respond to these events, and the blocking methods you can use. It also covers the audit events that show your blocks are working.
Where does Windows log USB device activity?
Windows records USB activity in the Security log through two Advanced Audit Policy subcategories: Audit PNP Activity (device connections, event 6416) and Audit Removable Storage (file operations, event 4663). Additional detail lands in the System log and in operational channels such as DriverFrameworks-UserMode. None of these are enabled out of the box.
Device connections: Audit PNP Activity
The Audit PNP Activity subcategory, available since Windows 10 and Windows Server 2016, generates event 6416 whenever the system recognizes an external device. The event carries the fields you need for an inventory: device ID, description, class name, hardware and vendor IDs, and the physical port and hub location. Microsoft’s monitoring recommendation for this event: alert whenever the Subject Security ID is anything other than SYSTEM.
The same subcategory covers device state changes: 6419 through 6422 record requests to turn a device on or off and the resulting state. At the same time, 6423 fires when system policy forbids a device installation and 6424 fires when a previously forbidden installation is allowed. Events 6423 and 6424 return in the blocking section; they prove that a device-control policy fired. This subcategory logs Success events only. Microsoft states it has no Failure events, so there is nothing to enable on that side.
File operations: Audit Removable Storage
The Audit Removable Storage subcategory, introduced with Windows 8 and Windows Server 2012, generates an audit event "for all objects and all types of access requested, with no dependency on object’s SACL." Successful reads and writes generate event 4663 with the Task Category "Removable Storage"; failed attempts generate 4656, which additionally requires Audit Handle Manipulation to be configured.
Two caveats come straight from Microsoft’s own monitoring guidance. First, because the auditing applies to every object and every access type, volume can be substantial. Microsoft explicitly recommends against enabling it on file servers that host shares on removable storage. Second, the events identify files, users, and access types, but not the device itself: event 4663 does not record a serial number or model. To answer "which device received this file," you correlate with event 6416.
Event 4663 is also produced by the Audit File System, Audit Kernel Object, and Audit Registry subcategories, so anything consuming these events needs to separate removable-storage 4663s from the rest. The Task Category does that, and the collection config below shows how.
Driver installation and operational channels
Two more sources fill specific gaps.
The System log records events 20001 and 20003 (source UserPnp) when Windows installs a device driver.
They appear only once, during the first connection of that device on that machine; our Windows USB auditing guide documents 20001 in this role.
Separately, the Microsoft-Windows-DriverFrameworks-UserMode/Operational channel logs events 2003, 2100, and 2102 for every insert and removal of a user-mode device, which makes 2102 one of the few reliable signals for disconnection time.
This channel is disabled by default, and Microsoft publishes no per-event reference documentation for it.
Its behavior is documented in vendor guides like ours and in the digital forensics community, so treat field semantics as community-verified rather than guaranteed.
USB event ID reference table
| Event ID | Channel | What it tells you | On by default? | Prerequisite |
|---|---|---|---|---|
6416 |
Security |
New external device recognized (ID, class, port) |
No |
Audit PNP Activity (Success) |
6419-6422 |
Security |
Device disable/enable requests and results |
No |
Audit PNP Activity (Success) |
6423 |
Security |
Device installation forbidden by policy |
No |
Audit PNP Activity (Success) |
6424 |
Security |
Previously forbidden installation allowed |
No |
Audit PNP Activity (Success) |
4663 |
Security |
File read/write on removable storage (success) |
No |
Audit Removable Storage (Success)* |
4656 |
Security |
Failed access attempt on removable storage |
No |
Audit Removable Storage (Failure) + Audit Handle Manipulation |
4658 |
Security |
Handle to removable-storage object closed |
No |
Audit Removable Storage + Handle Manipulation |
20001 / 20003 |
System (UserPnp) |
Driver installed for new device (first connect only) |
Yes |
None |
2003 / 2100 / 2102 |
DriverFrameworks-UserMode/Operational |
Device insert and removal operations |
No |
Enable the channel via wevtutil |
RemovableStoragePolicyTriggered |
Microsoft Defender for Endpoint (advanced hunting) |
Device control policy allowed/denied access |
No |
MDE device control policy deployed |
* On newer Windows 10/11 builds, event 4663 for removable storage also requires the HotPlugSecureOpen registry value; see the next section.
How do you enable USB auditing on Windows?
You enable USB auditing with two auditpol subcategories (or their Group Policy equivalents under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration), plus one registry value and one channel activation for full coverage.
Enable the audit subcategories from an elevated prompt:
> auditpol /set /subcategory:"Plug and Play Events" /success:enable
> auditpol /set /subcategory:"Removable Storage" /success:enable /failure:enable
> auditpol /set /subcategory:"Handle Manipulation" /failure:enableVerify the settings:
> auditpol /get /category:"Detailed Tracking"
> auditpol /get /category:"Object Access"For fleet-wide deployment, set the same subcategories through a GPO instead, following Microsoft’s advanced audit policy documentation.
There is one requirement that is easy to miss.
On newer Windows 10 and 11 builds, enabling Audit Removable Storage alone does not produce 4663 events for USB drives.
Microsoft documents the extra step in a note on its removable storage monitoring page: "some versions of Windows 10 may require registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Storage\HotPlugSecureOpen to be set to 1 to start logging the removable storage audit events."
It does not appear in the audit policy reference itself, which is why it catches people out:
> reg add "HKLM\SYSTEM\CurrentControlSet\Control\Storage" /v HotPlugSecureOpen /t REG_DWORD /d 1 /fGuidance elsewhere often says a reboot is mandatory. On a fully patched Windows 11 machine, 4663 events began appearing within seconds of setting the value, with no restart. Treat the reboot as a fallback if events don’t show up, not a required step, and verify on Windows Server separately: we haven’t confirmed the same behavior there.
The same value has a second life as a troubleshooting item: Microsoft’s removable device policy guidance documents cases where the WPDBusEnum service re-creates the key after deletion, breaking policy enforcement. Setting it for auditing and fighting it for blocking are different problems with the same key.
Finally, if you want insert and removal timestamps, enable the DriverFrameworks channel:
> wevtutil sl "Microsoft-Windows-DriverFrameworks-UserMode/Operational" /e:trueA word on volume before you push any of this to production: Microsoft rates Plug and Play auditing as typically low volume, but Removable Storage auditing fires on every audited access to every object on every removable device. Scope it deliberately, test on a pilot group, and filter at collection time, which brings us to tooling.
What tools can you use for USB auditing on Windows?
Four tools cover most USB auditing needs: Event Viewer for spot checks, Sysmon for registry-based detection, Microsoft Defender for Endpoint for policy-aware telemetry, and a log collection agent to get any of this off the endpoint. They answer different questions, so most teams run more than one.
Event Viewer with XPath filters
For a single machine, a custom view in Event Viewer gets you started. This XPath query isolates new-device events:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=6416)]]</Select>
</Query>
</QueryList>It works, and it scales to exactly one machine at a time. Event Viewer has no alerting, correlation, or protection against local log clearing.
Sysmon
Sysmon has no dedicated USB event type.
It does offer registry auditing (event IDs 12-14), and a common community detection pattern is to watch key creation under HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR, which Windows populates when it enumerates a USB storage device.
This is a useful supplement, particularly on systems where you already run Sysmon, but it observes a side effect of device enumeration rather than the device events themselves.
For authoritative device fields, event 6416 is the better source.
Microsoft Defender for Endpoint device control
Device control in Defender for Endpoint can audit, allow, or deny removable storage access, and every policy trigger is queryable in advanced hunting:
DeviceEvents
| where ActionType == "RemovableStoragePolicyTriggered"
| extend parsed = parse_json(AdditionalFields)
| project Timestamp, DeviceName, InitiatingProcessAccountName,
RemovableStorageAccess = tostring(parsed.RemovableStorageAccess),
RemovableStoragePolicyVerdict = tostring(parsed.RemovableStoragePolicyVerdict),
MediaName = tostring(parsed.MediaName)Two constraints to plan around, both from Microsoft’s documentation: advanced hunting caps RemovableStoragePolicyTriggered at 300 events per device per day, and the feature requires the appropriate Defender for Endpoint plan. MDE tells you what its policy did; it is not a general-purpose collector for the Windows audit events above.
NXLog Agent: getting the events off the endpoint
Everything so far shares one weakness: the evidence lives on the machine that generated it. Security logs rotate, event 1102 exists because attackers clear them, and a device inventory you cannot query across your fleet is not an inventory. NXLog Agent collects the full USB event set natively through the Event Log for Windows input module, filters it at the source, and forwards structured JSON to wherever your analysts work.
Here is a working configuration that collects the device-connection, policy-block, and file-operation events, drops non-removable-storage 4663 noise, and writes JSON:
<Extension json>
Module xm_json
</Extension>
<Input usb_audit>
Module im_msvistalog
TolerateQueryErrors TRUE (1)
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Security">
*[System[(EventID=6416 or EventID=6419 or EventID=6420
or EventID=6421 or EventID=6422 or EventID=6423
or EventID=6424)]]
</Select>
<Select Path="Security">*[System[(EventID=4663)]]</Select>
<Select Path="Microsoft-Windows-DriverFrameworks-UserMode/Operational">
*[System[(EventID=2003 or EventID=2100 or EventID=2102)]]
</Select>
</Query>
</QueryList>
</QueryXML>
<Exec>
if ($EventID == 4663 and $Category != "Removable Storage") { (2)
drop();
}
to_json();
</Exec>
</Input>
<Output file>
Module om_file
File 'C:\ProgramData\nxlog\usb-audit.json'
</Output>
<Route usb>
Path usb_audit => file
</Route>| 1 | Keep collecting even if the DriverFrameworks channel is absent. |
| 2 | Event 4663 also fires for File System and Registry auditing. This keeps only the removable storage events. |
One note on that filter: $Category is resolved from the event’s task value, and the string is locale-dependent.
On an English-language Windows system, the removable-storage 4663 event carries exactly Removable Storage, which is what the config matches.
On a localized system, check the value on a sample event first with Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663} | Group-Object TaskDisplayName.
Swap the File output module for one that matches your SIEM, or skip the SIEM detour and send the events to NXLog Platform, which stores them and makes them searchable. Additionally, it manages the agent configuration centrally, so your USB collection policy cannot silently drift across a few thousand endpoints. A collected 6416 event looks like this (output trimmed):
{
"EventTime": "2026-09-07T10:23:17.482911+02:00",
"Hostname": "WKS-1042.example.com",
"EventType": "AUDIT_SUCCESS",
"EventID": 6416,
"SourceName": "Microsoft-Windows-Security-Auditing",
"Channel": "Security",
"Message": "A new external device was recognized by the system.",
"SubjectUserSid": "S-1-5-18",
"DeviceId": "USB\\VID_0951&PID_1666\\0C9D92E1D3A4B123",
"DeviceDescription": "Kingston DataTraveler 3.0 USB Device",
"ClassName": "DiskDrive",
"LocationInformation": "Port_#0003.Hub_#0001",
"SourceModuleName": "usb_audit",
"SourceModuleType": "im_msvistalog"
}The DeviceId field carries the vendor ID, product ID, and serial number: exactly the identifiers you need for first-seen-device detection and for matching a physical stick to a log line.
How do you block USB devices on Windows?
Windows offers four blocking mechanisms, from coarse to granular: Removable Storage Access policies, Device Installation Restrictions, the USBSTOR registry switch, and Defender for Endpoint device control. Pick based on how many exceptions you need to manage.
Removable Storage Access (Group Policy). Under Computer Configuration > Administrative Templates > System > Removable Storage Access, you can deny read, write, or execute access per device class, or deny everything with "All Removable Storage classes: Deny all access." These policies modify the security descriptor on the device objects: the driver still installs; access is what gets blocked. Deny-write-only is a popular middle ground: users can read reference material from a stick but cannot exfiltrate to it.
Device Installation Restrictions (Group Policy). Under Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions, you can prevent installation entirely and allow-list approved devices by hardware ID or instance ID. Microsoft’s device installation guide walks through the scenarios and carries an important warning: applying a prevent policy retroactively to already-installed devices with a broad class like Disk Drive can take out the internal hard drive along with the USB sticks. Test the "apply to matching devices already installed" checkbox somewhere you can afford to reimage.
The USBSTOR registry switch. Setting the USB storage driver’s start type to disabled blocks the storage class at the driver level:
> reg add "HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR" /v Start /t REG_DWORD /d 4 /fMicrosoft’s own troubleshooting guidance positions this as the fallback for systems without Group Policy, such as Home editions. It is a blunt instrument: it only affects the USB storage class, does nothing about phones enumerating as portable devices or network gadgets, and management tools sometimes flip it back.
Defender for Endpoint device control. For allow-listing specific devices by vendor ID, product ID, or serial number (or requiring BitLocker encryption on writable media), MDE device control policies are the most granular option. Policies combine device groups and access rules with a configurable default enforcement, deployed via Intune or Group Policy. Start every rollout with an audit-only policy and read the advanced hunting results before you flip anything to deny.
Blocking without auditing is unverifiable
Here is the part most USB-blocking guides skip: policies fail silently. Microsoft’s removable device troubleshooting article documents multiple 2025 Windows updates (KB5058379, KB5050092, KB5062552) after which "users can bypass storage policies" while gpresult still shows the GPO as applied. If your only evidence of enforcement is the policy object, you have no evidence.
The audit trail is the verification. Event 6423 tells you policy blocked a device installation, and every occurrence shows your control working. Event 6424 tells you Windows allowed a previously forbidden device, and every occurrence deserves a ticket. Tag them at collection time:
<Exec>
if $EventID in (6423, 6424) {
$AlertPriority = "high";
}
</Exec>And the inverse check matters just as much: a 6416 with ClassName: DiskDrive on a host that should block all removable storage means your policy isn’t enforcing, whatever the GPO report says.
A working USB monitoring pipeline
The pipeline has four stages. Enable the audit subcategories and the HotPlugSecureOpen value through GPO. Collect events 6416 and 6419-6424, removable-storage event 4663, and the DriverFrameworks events with NXLog Agent using the configuration above. Route the JSON to NXLog Platform or your SIEM. Then alert on a short, high-signal list:
-
A first-seen device rule: a DeviceId (which embeds the serial number) appearing on a host for the first time.
-
A write-burst rule: a spike of 4663 events with WriteData access on one host within a few minutes, the signature of a bulk copy.
-
A policy-integrity rule: any 6423 or 6424 event, plus any storage-class 6416 event on hosts that should block removable media.
-
And Microsoft’s own recommendation: any event 6416 where the Subject Security ID is not SYSTEM.
For dashboarding these events alongside the rest of your Windows security telemetry, our Windows security monitoring with Elasticsearch and Kibana walkthrough already includes a USB activity event group you can extend.
What USB auditing on Windows can’t see
Native auditing has real gaps, and you should design around them rather than discover them in an incident review.
Noise is structural.
Event 6416 fires for any external device: every keyboard, mouse, and webcam.
Filter on ClassName (DiskDrive, WPD) at collection to keep the signal.
File events lack device identity.
A 4663 names the file, the user, and the access type, but not the device serial.
Correlation with 6416 on the same host closes most of the gap.
Forensic practitioners also use the Microsoft-Windows-Partition/Diagnostic channel (event 1006), which captures device details including serial numbers on connect.
This channel has no official Microsoft documentation, so we flag it as community-documented practice rather than a supported interface.
Storage-focused controls miss HID attacks. Karsten Nohl, Sascha Krißler, and Jakob Lell of SRLabs demonstrated at Black Hat USA 2014 that a reprogrammed USB device can present itself as a keyboard and inject keystrokes. That bypasses every removable storage policy on this page, because to Windows it is not storage. Honeywell’s 2025 report expanded its analysis to these Human Interface Device threats for the same reason. PNP auditing still logs the device connection (event 6416 records keyboards too), which is exactly why you collect it even on hosts where storage is fully blocked.
Controls drift. Conflicting GPOs overwrite audit policies, updates break enforcement, and registry values regenerate. Treat the audit stream itself as the control’s health check.
Turn USB events into evidence
Windows gives you the raw material for USB device auditing: connection events with serial numbers, file-level access records, and policy verdicts. What it does not give you is durability, correlation, or fleet-wide consistency; that is the collection layer’s job. NXLog Agent gathers every event ID in this article from thousands of Windows endpoints, and NXLog Platform keeps the configurations aligned and the evidence searchable when someone asks what left the building on that stick.
Try NXLog Platform for free, or start with the configurations in our Windows USB auditing documentation.
FAQ
- What Windows event ID shows a USB device was plugged in?
-
Event 6416 in the Security log ("A new external device was recognized by the system"), generated when the Audit PNP Activity subcategory is enabled on Windows 10, Windows 11, or Windows Server 2016 and later. It includes the device ID, class, description, and physical port.
- Does Windows log an event for files copied to a USB drive by default?
-
No. You must enable the Audit Removable Storage subcategory, which produces event 4663 for each read or write on removable media. On newer Windows 10/11 builds, you also need to set the HotPlugSecureOpen registry value to 1.
- What is the difference between event 6416 and event 4663?
-
6416 records the device connecting (identity, class, port); 4663 records file operations on the device (who accessed which file, and how). Device-level and file-level visibility require different audit subcategories, and a complete picture needs both.
- How do I verify my USB blocking policy is working?
-
Watch for event 6423 (installation forbidden by policy) as positive confirmation, event 6424 (previously forbidden device allowed) as an escalation trigger, and any storage-class 6416 on supposedly blocked hosts as a policy failure. In Defender for Endpoint, query RemovableStoragePolicyTriggered in advanced hunting.
- Can I block all USB drives but allow approved devices?
-
Yes. Device Installation Restrictions in Group Policy support an allow-list by hardware or instance ID layered over a class-wide block, and Defender for Endpoint device control can allow specific devices by vendor ID, product ID, or serial number, including encryption-state conditions.
