Device coverage
Which devices PermitUSB can see and act on, which it cannot, and where the line falls. If it enumerates on the USB bus, a rule can act on it.
The rule is the bus, not the device type. If a device enumerates on the USB bus, PermitUSB sees it and a policy rule can act on it. That covers far more than storage: printers, Bluetooth radios, network adapters, phones, webcams and card readers are all ordinary USB devices as far as Windows is concerned, and all of them are ordinary devices as far as a rule is concerned.
This page is the specific answer to "does it handle my thing?", including the cases where the answer is no.
Device classes you can name in a rule
These are the classes the policy editor offers by name. A rule can list several at once.
| Class | What it covers |
|---|---|
| USB storage | Flash drives and external HDDs and SSDs. Covers USBSTOR for bulk-only transport devices plus UASPStor and SCSIAdapter for UAS, which is what most modern USB 3.x SSDs use |
| Optical drives | CD, DVD and Blu-ray readers and burners |
| Printers | USB-attached printers |
| Audio devices | Headsets, microphones and speakers |
| Webcams | USB cameras |
| Scanners / imaging | Flatbed and document scanners |
| Smart card readers | Including CAC and PIV readers |
| Fingerprint / biometric readers | Usually the sensor built into a laptop chassis rather than anything plugged in. Blocking this class breaks Windows Hello sign-in |
| USB hubs | The hub itself, not the devices behind it, which are evaluated on their own |
| Bluetooth devices | The Bluetooth radio |
| Network adapters | USB Ethernet dongles, USB Wi-Fi adapters, and the Ethernet side of a USB-C or Thunderbolt dock |
| Modems | USB modems and cellular sticks |
| Serial / parallel ports | USB-to-COM and USB-to-LPT adapters, common on shop-floor equipment |
| Portable devices | Phones and tablets connected in MTP mode |
Matching below the class level
Class is the broadest match. A rule can also match a single physical device by serial number, every device sharing a vendor and product ID, a substring of the vendor name, or membership of a device group you curate. Where two rules both match, the more specific one wins, and the events page shows which rule made each decision.
What each enforcement layer covers
Two layers run underneath every rule, and they do not cover the same ground. This matters if you are reading a claim about when a device is stopped.
- User-mode enforcement applies to every class on this page. It acts through the Windows Configuration Manager as soon as the device is seen, and it is the only layer on an endpoint without the kernel driver
- Kernel-mode enforcement arms on USB mass storage. There it vetoes the device before it starts, below anything reachable from Device Manager or an elevated shell, and it enforces from early boot using a cached policy snapshot
- Read-only is a storage disposition. It is enforced by refusing writes to the drive, so it is meaningful for storage and not for a printer or a webcam. You can still select it on a non-storage rule, and the agent blocks the device and says on the event that read-only does not apply to it - so use allow or block there instead. Where a read-only rule cannot be enforced the device is blocked rather than handed over writable
So "blocked before it becomes functional" is a mass-storage claim. Everything else on this page is blocked promptly rather than pre-emptively.
Where the boundary is
PermitUSB governs the port. It does not govern what a permitted device then does, and it does not reach devices that are not on the USB bus at all.
- The Bluetooth pairing stack and Bluetooth traffic. A rule blocks the radio; it does not filter what pairs with a radio you have allowed
- Built-in network interfaces. A laptop or desktop NIC on PCIe never enumerates on the USB bus, so a network-adapter rule cannot reach it. Neither can it reach a virtual adapter belonging to a VPN client or a hypervisor
- Network printers and network shares. Nothing plugs in, so there is no port to act at
- Internal PCIe, NVMe and M.2 devices, including a drive attached over Thunderbolt as PCIe rather than as USB
- File contents. PermitUSB records device identity and the decision taken. It does not read, copy or inspect the files on a drive
Two things to know before you block them
- Network adapters. On an endpoint whose only connection is a USB adapter, blocking this class also cuts the agent off from the cloud. The endpoint keeps enforcing the last policy it received, which means it cannot be reached to undo the rule. Blocking network adapters is a reasonable control on a wired shop-floor machine and a bad one on a laptop that docks
- Fingerprint and biometric readers. Blocking the class disables Windows Hello sign-in on any endpoint whose sensor is on the USB bus
Known limitation
A non-storage device that is already plugged in when the agent starts is not evaluated until it re-enumerates, which in practice means until it is unplugged and replugged or the machine restarts. Mass storage does not have this gap: a drive present at install is swept and blocked immediately. This is a real hole in first-install coverage for peripherals and it is on the roadmap rather than fixed.
Platform
Windows 10 and Windows 11 on x64. There is no macOS or Linux agent. The MSI installer page carries the full system requirements.
Something missing or wrong here? Tell us. Documentation gaps get filled fast.