Skip to content
Totem Tech editor’s note: Joe Lariz is the creator of PermitUSB and the Director of Information Technology at an electronics manufacturing company in the defense supply chain. His company’s removable media compliance problem is shared by us and many of our clients. The route he chose to solve this problem is very compelling, so we asked him to write a guest blog for us on the topic. What follows is Joe’s USB allowlisting story in his own words.
I didn’t go looking for this problem. It was handed to me.
I’m the Director of Information Technology at an electronics manufacturing company. Like a lot of shops in our position, we do work that makes us a link on the DoD supply chain, and that means cybersecurity compliance requirements roll downhill until they land on somebody’s desk. USB device control landed on mine.
The requirement itself wasn’t unreasonable: control the use of removable media. Know what’s plugged into your machines. Be able to prove it. Anybody who’s read NIST 800-171 knows the shape of it, and anybody who’s sat through a CMMC conversation knows it isn’t the kind of requirement you talk your way out of.
Think about how every other entrance to your network is governed. Email runs through a gateway that decides what gets delivered. Web traffic passes a proxy. Remote access requires MFA before anything happens. In each case the default is *deny*, and traffic earns its way in.
Now consider the USB port. There are several on every machine in your building, they connect directly to the inside of your network, and by default Windows will happily initialize almost anything you push into one. Nobody sat in a meeting and decided that. It’s just the posture you inherited, and it has quietly survived every security investment you’ve made since.
That inherited default allow is the whole problem. And the instinctive fix — start naming the things you don’t want to allow, aka setting up a blocklist — is where most cybersecurity programs go wrong.
You cannot enumerate what you're trying to stop
Blocklists work when the set of things you want to disallow is small, stable, and knowable. Think of a list of sanctioned countries or known-malicious IP ranges: finite, published, updatable. The set of USB devices you’d need to block has none of those properties: new hardware ships constantly, attacking devices are cheap and emulate legitimate hardware, and even benign manufacturers get lazy and reuse identifiers like serial numbers.
Then there’s the structural problem underneath it all. To make a blocklist work you have to be right every single time. An attacker, or honestly just a well-meaning employee using a personal device, has to find one thing you didn’t think of. That’s not a trade you can win by working harder at a block list.
Security people in other domains have known this for a long time. It’s why application control moved to allowlisting, and why firewalls deny network traffic by default. Removable media aka portable storage aka USB is one of the last places where the industry still tolerates the opposite posture.
USB allowlisting: the list you can actually finish
Flip the question. Instead of enumerating everything that might hurt you, enumerate what your business genuinely needs.
That kind of list is remarkable in one specific way: it’s finite, and it’s short. A manufacturer with three hundred employees usually runs on something like a few dozen distinct peripheral device types. Keyboards and mice. A handful of barcode scanners. Some test equipment and device programmers. Two or three approved encrypted drives. A label printer. A license dongle or two that cost more than the workstation they’re attached to.
That’s the whole list. You could write it on a legal pad.
And here’s what changes when you change from a blocklist to an allowlist mindset: the requirement to be exhaustive actually becomes manageable. You no longer have to predict the device somebody buys next year. Anything you didn’t approve simply doesn’t work, including devices that didn’t even exist when you wrote the policy. That’s the entire value of deny-by-default, and it’s available to you the moment you stop trying to guess at badness.
For defense contractors, USB allowlisting isn't optional
It’s worth remembering why these rules exist at all. In 2008, malware later named Agent.btz reached US Central Command’s classified networks from a USB flash drive plugged in at a base overseas. The cleanup ran for months, the immediate policy response was a blanket ban on removable media across DoD networks, and the episode is widely credited as one of the catalysts for standing up US Cyber Command. Two years later Stuxnet showed that even air-gapped industrial systems weren’t immune. When a network has no external connection at all, removable media isn’t one attack path among many. It is the attack path.
The controls you’re assessed against today are downstream byproducts of those incidents. If you handle Controlled Unclassified Information, DFARS 252.204-7012 obligates you to implement NIST SP 800-171, and a CMMC Level 2 assessment checks whether you actually did.
Two 800-171 controls matter here.
3.8.7 says “control the use of removable media on system components” – note the term control, not “observe”. A dashboard full of logged activity is not evidence that anything was controlled, which is a distinction that can surprise people mid-assessment.
3.8.8 is the one worth reading twice: “prohibit the use of portable storage devices when such devices have no identifiable owner”.
Sit with that. To satisfy this requirement, you must be able to distinguish a specific approved device from an unapproved one — not a category of devices, a specific unit, typically identified by serial number. There is no way to express that as a blocklist. A blocklist can tell you what isn’t allowed; it can never establish that a given device is. The control doesn’t merely permit an allowlist. It requires one.
Add the audit requirements — generating a durable, time-stamped record of what was plugged in, when, into which machine, and what the system did about it — and the acceptable approach takes shape for you: Deny by default, identify devices individually, and keep evidence you can hand to an assessor months later.
The problem was the USB allowlisting options weren’t great.
Eventually I built the thing I wanted instead: block every USB device by default, and make approving a legitimate one take seconds. But that came later. First I had to live with what was available.
Two bad options
Option one: block all USB ports. Simple, total, and completely divorced from how a real organization operates.
People hear “block USB” and picture thumb drives. That’s a stereotype. Look at what’s actually plugged into USB in a manufacturing environment. Keyboards. Mice. Barcode scanners. Test equipment. Device programmers. Bench instruments. Label printers. Camera SD cards. License dongles that cost more than the machine they’re attached to. The world of USB “peripherals” is massive, and “peripheral” is misleading – most of these devices are business-critical.
Turn all of it off on Monday morning and you haven’t secured the company. You’ve stopped it.
Option two: buy an enterprise-grade security suite. These exist, they’re mature, and they’ll absolutely check the box. They also cost substantially more than the problem you’re solving, and in my experience they tend to do a great many things okay and very few things perfectly.
So we did what most people in that position do. We worked with what we already owned.
No vendor has device control as a core competency
The endpoint protection suite we were already running supported device control with USB allowlisting. On paper, that solves it. The capability was genuinely there.
The management of it is what broke us. I don’t think that’s a knock on the vendor, and I’d say the same about most of the products in that category. Device control isn’t their core competency. It isn’t what they were built to do, it isn’t what they’re bought for, and it isn’t where their best engineering goes. It’s a module. It’s a check mark on a subscription-tier comparison chart, sitting inside a product designed to do something else genuinely well, and accordingly it gets the attention warranted for a side feature.
You feel that the moment you try to run it day to day.
Approving one thumb drive for one employee took several minutes on a good day. Longer if it had been a few weeks since the last time and I had to remember how the pieces fit together. And the whole time, the employee is standing at my desk waiting for their device.
Here’s the part that never stopped bothering me. The device block is the single most information-rich event in the entire system. That’s the exact instant the endpoint protection software knows everything worth knowing: what the device is, how Windows identified it, which machine it went into, who was logged in. Everything I needed in order to make a decision about that device existed, right then. The moment the system is smartest about a device should be the moment it’s easiest for you to decide what to do about it.
But it wasn’t easy. The device control application made us dig for relevant information and its console lacked the interface to let us do exactly what we needed to do in real-time.
My team and I said some version of “it really shouldn’t be this difficult to manage this” more times than I can count. One day I finished the sentence differently. “It really shouldn’t be this difficult, and it really doesn’t have to be.”
What I built to solve USB allowlisting
I’ve spent my career moving across a lot of disciplines. Programming, system building, networking, user support, and pretty much everything in between. Honestly, at first this looked like a simple thing to build. Watch for device plug-in, check it against a list, allow or block, write the event somewhere useful. How hard could that be? Well, it turns out there’s no simple solution when it comes to USB devices. I found that out the hard way, as my first several attempts at a USB allowlisting solution produced nothing but blue screens.
But there’s no way to overstate what that does to your process. When a mistake means a machine doesn’t boot, you stop improvising. This was intended to be an enterprise product that my company was going to trust to install on the machines our business runs on. If it bricks a computer running a machine worth millions of dollars, it doesn’t matter how clean the dashboard is. You slow down, you get extremely purposeful about what you’re doing and why, and you build the safety rails before you need them. You focus on the fundamentals and make it pretty later.
So, I worked nights and weekends, creating a robust infrastructure and procuring code signing certificates and test hardware out of pocket. The result is PermitUSB.
PermitUSB is USB device control for Windows fleets. Block by default, deploy by MSI, and a cloud-based console shows you exactly what it blocked so approving it takes seconds. The whole workflow goes like this: Someone plugs in a drive. It gets blocked. The block shows up in your dashboard with everything you need to know about the device already attached to it. If you want to approve it, you click it onto the allow list. If you don’t, you do nothing and it stays blocked.
That’s it. That’s the whole thing.
One less stress. One less worry. One requirement I can stop thinking about.
The investment of my free-time and savings paid off. Our first paying customer was my employer. The company that had the USB allowlisting requirement handed to them, the company where I stood at my desk approving thumb drives, is running PermitUSB today, and they’re a very happy customer.
If this just landed on your desk
If you’re an IT admin who got handed the same requirement I did, staring at the same two bad options I outlined above, here’s our suggestion on what to look for in a USB allowlisting tool.
Whatever tool you choose, hold it to a few things:
- Deny by default, with allow rules that can match an individual device, not just a category.
- An observation mode so you can build the list before you enforce.
- One place to manage all of it. Per-machine configuration stops scaling somewhere around the first dozen endpoints, and it leaves you unable to answer the question an assessor will actually ask: what is every machine enforcing right now? You want a console that holds the policy and the answer.
- Enforcement that survives a local administrator. If the control can be undone from Device Manager, it’s a speed bump.
- It keeps working when the network doesn’t. Losing connectivity should never “fail open” and quietly revert an endpoint to allowing everything.
- Evidence you can export. Including the approvals, not just the denials.
- A rollout you can stage, by group, so the front office and the shop floor don’t have to share a posture on day one.
I understand what you’re going through. I’m in it too. And I think this problem deserves to be somebody’s core competency. PermitUSB is our core competency.
Post Script: Who we are
PermitUSB is developed and maintained by JJMK Studios. Those are initials: mine, my wife’s, and our two kids’. Every hour that went into this was carved out of time that belonged to them, so their initials are on the door. As for the product name, I still can’t believe “PermitUSB” was available. Start a free trial at permitusb.com. Published pricing, no demo gate.
–Joe