USB device control is the practice of deciding, by policy, which devices may connect to a company computer and what they may do there. The goal is simple: a stranger's flash drive should not mount, a known encrypted drive should, and a keyboard, mouse or headset should never be caught in the middle. Done badly, USB blocking is the control users hate most, because it stops the one drive they needed on the day they needed it. Done well, it is invisible until it matters. This guide covers how removable storage leaks data, how teams usually control it, what a good device control policy looks like, and a checklist you can apply with any tool.
Why removable storage is still a problem
File sharing has moved to the cloud, but the USB port is still there, and it is still the fastest way to move a large amount of data off a laptop with no network trace. Three things make it different from other channels:
- It is offline. A copy to a flash drive leaves no proxy log, no mail header and no upload record. If the endpoint does not record it, nobody does.
- It is physical. The drive walks out of the building. There is no link to revoke.
- It is two-way. A drive that carries data out can also carry malware in. CISA's guidance on removable media covers both directions: https://www.cisa.gov/news-events/news/using-caution-usb-drives
The classic leak is not dramatic. A leaving employee copies "my files" to a personal drive in their last week. A contractor takes a customer export home to finish a report. Neither thinks of themselves as an insider, which is why a control that depends on good intentions does not work.
How USB blocking is usually done, and where it breaks
Group Policy and registry settings
Windows can deny removable storage classes through Group Policy, or stop the USBSTOR driver from loading. Microsoft documents the device installation restrictions here: https://learn.microsoft.com/en-us/windows/client-management/manage-device-installation-with-group-policy
It works, and it costs nothing. The problems appear on day two. Exceptions are by hardware ID, which matches every drive of that model, not by serial. There is no way for a user to ask for access, so every exception is a help-desk ticket and a GPO edit. There is no record of what was copied, or of which drive was plugged in. And a local admin can undo it.
Device-only allowlists
The next step up is a tool with an allowlist and some logging. What is often missing is a connection to the content of the file: the same rule applies to a holiday photo and a payroll export, and the exception process still lives in email.
The common failure in both is the same: the control treats "USB" as one thing. A good policy treats the device class, the specific device, the user, the file and the time as separate questions.
What good USB device control looks like
A device control policy that people can live with has five properties.
Deny by default, by class, not by port
Storage is denied unless a rule allows it. Keyboards, mice, webcams and printers are not storage and should not be affected. Bluetooth, wireless adapters, removable disks and phones in MTP mode each get their own rule, because each is a different risk. A "USB" rule that also switches off the wireless adapter on a laptop with no Ethernet port gets the whole control rolled back within a week.
Trust specific devices by serial number
A company-issued encrypted drive should work everywhere. The way to express that is the device's serial number, not its vendor and product ID, which every drive of that model shares. The same applies to removable hard disks, which the operating system does not always report as "removable" and which need their own treatment.
Let users ask, and let the answer expire
The honest reason users work around USB blocking is that the exception process takes days. A good policy has a request path built in: the user plugs in a drive, the agent explains why it is blocked, the user asks for access with a reason, and an admin approves it from the console for a fixed time. One hour is enough for most real tasks. When the hour ends the deny returns on its own, with nothing to remember to revoke.
Read-only is a real option
Many tasks need to read from a drive, not write to it. A read-only mode for untrusted storage covers the supplier's firmware update and the auditor's questionnaire, with no data leaving.
Log the file, not just the plug-in event
"Device connected" is not evidence. "User X copied Y.xlsx, classified Confidential, to drive serial Z at 14:02" is. File-level tracing on allowed drives turns device control from a wall into a record, and answers the question that always comes after a departure: what did they take?
Device control and content: where DLP comes in
Device control answers "may this device connect?" Data loss prevention answers "may this file leave?" They are different questions and you want both.
With device control alone, a trusted drive is a free channel: any file, any classification. With DLP alone, every unknown drive still mounts. Together, the shape is:
| Situation | Device control | DLP on file copy |
|---|---|---|
| Unknown flash drive | Denied, user can request | Not reached |
| Trusted drive, public file | Allowed | Allowed |
| Trusted drive, confidential file | Allowed | Warn, ask for a reason, or block, by policy |
| Trusted drive, customer records | Allowed | Block, incident recorded |
The DLP layer has to read what is in the file, not just its name. A customer list renamed to notes.txt is still a customer list. For how content inspection works across channels, see What is Data Loss Prevention (DLP)? A practical guide. USB is one way out; the clipboard is another, covered in Clipboard DLP: how to stop copy-paste leaks, and printing is the one everyone forgets: Print DLP.
Rolling it out without a revolt
The order matters more than the tool.
- Inventory first. Run in monitor-only mode for two to four weeks. You will find drives you did not know existed: backup drives on finance desks, label printers that present as storage, the dongle on the lathe in the workshop.
- Build the trusted list from the inventory, by serial number. Issue company drives so there is a sanctioned way to do the job.
- Decide the exception path and its time limit before enforcement starts. Tell people what it is.
- Enforce by group, not estate-wide. Start with a team that rarely uses drives, then IT, then everyone.
- Turn on file tracing for allowed drives from day one, so the record exists before the first incident.
- Watch the request queue. Ten requests a day from the same team means that team needs a trusted device, not ten approvals.
Removable storage is an endpoint-only problem that no network appliance will see; Endpoint DLP vs network DLP covers why.
USB device control checklist
- Removable storage is denied by default on every managed computer, including servers and shared desks.
- Rules are per device class: removable disks, removable hard disks, Bluetooth, wireless, phones. Input devices and printers are not affected.
- Trusted devices are listed by serial number, not vendor and product ID.
- Users can request access from the block notice with a reason, and approval expires after a set time.
- A read-only option exists for untrusted storage where reading is legitimate.
- File copies to allowed drives are recorded at file level, with user, file, classification and device serial.
- Confidential content on the way to a trusted drive is inspected by DLP and warned, justified or blocked by policy.
- Local admin rights cannot switch the control off. If users still hold local admin, read Just-in-time admin rights.
- Enforcement is rolled out by group, after a monitor-only period.
- Every policy change is in the admin trail, so an auditor can see who loosened what and when.
How Tracemark does it
Tracemark's Device Control is part of the Endpoint Control product and runs in the same agent that delivers DLP, so the two layers above are one policy, not two tools.
USB storage is denied by default. Trusted drives are added by serial number. Bluetooth, wireless adapters and removable disks are separate classes, each with its own rule, so blocking storage does not take down a laptop's wireless connection.
When a user plugs in a drive that is not trusted, they can send an access request. An admin approves it from the console for a limited time, for example one hour, and the deny returns automatically when the time expires. There is nothing to revoke later.
Because DLP runs in the same agent, a file copied to a trusted drive is read for what it contains: built-in detectors, custom keyword and pattern categories, exact-data fingerprints of records such as a customer list, document fingerprints, and OCR of text inside images. The policy can warn, ask for a reason, or block. Every decision lands in the Incidents queue with who, what, channel, policy and outcome, searchable, exportable to CSV and bundled into evidence packs.
USB activity also feeds the per-user risk score in Insider Risk, so a pattern of copies before a resignation is visible rather than buried. Enforcement by group uses dynamic endpoint groups by rule, every policy change is kept in the admin trail, and the agent works offline, so a laptop on a plane enforces the same rules it had in the office.
Frequently asked questions
Does blocking USB storage also block keyboards and mice?
Not with a class-based policy. Keyboards, mice, webcams and most printers use different USB device classes from mass storage. A correctly scoped rule denies storage and leaves input devices alone. If your tool only offers "block USB", look for a more specific control.
How do I allow a specific drive and not all drives of that model?
Use the device serial number. Vendor and product IDs are shared by every unit of a model, so an allowlist built on them trusts the whole batch. A serial identifies one physical device, and most tools can read it when the drive is first seen, so you trust it from the inventory rather than typing it in.
What about phones connected as storage?
Phones in MTP or PTP mode present as a different device class from a flash drive and need their own rule. Charging does not require storage access, so blocking the storage class does not stop charging. For phones held up to the screen rather than plugged in, see Screen watermarking.
Can users bypass USB device control?
A user with local admin can usually stop an agent or edit the registry, so device control depends on users not holding standing admin rights. Booting another operating system from USB is a separate problem, solved with BitLocker and a firmware password; see BitLocker management.
Try it
Try Tracemark free for three months. Claim it at tracemark.ca