ThreatLocker Review - First 90-Days On the Platform

I wrote this in June 2025, after my first 90 days running ThreatLocker across a client base. It has been one of the most read things on this site ever since, which is the reason for the section that follows. A product review is a photograph, not a portrait. ThreatLocker ships to the agent and the portal every 7 to 10 days, which means a specific complaint written in June 2025 has had well over a hundred release cycles to stop being true.

So before the review, the update.

Where this stands now

I still run ThreatLocker. I recommend it. I like the company.

In the months after this review went up, they made real changes to how support works, and every issue I raised here was addressed. Not deflected, not closed as working-as-intended. Fixed. That is a genuinely unusual response to a public review that was not flattering, and it is worth more to me than if the product had been perfect in month two.

So read what follows as a snapshot of one platform at one moment, by one person rolling it out at pace. If you are evaluating ThreatLocker today, do not treat any individual bug below as current. Assume it is stale unless you can reproduce it yourself. What is still worth reading is the shape of the thing: what application control actually costs to run, where a fast moving platform tends to crack, and what questions to ask before you sign.

The rest of this is as written, in June 2025.

The short version

ThreatLocker largely delivers on its core promise. Application control works, the platform evolves faster than anything else in my stack, and the people are good to deal with. It is also rough around the edges in the way a company scaling quickly tends to be, and the cost of that roughness lands on whoever is doing the rollout.

In my first 90 days I opened 47 tickets. A meaningful share were bugs or platform issues rather than my own confusion. Some got resolved, some lingered, and I eventually closed around 20 out of frustration. At points it felt like I was doing quality assurance rather than receiving support.

The time cost was real: roughly 150 hours in the first few months, averaging about 12 hours a week spent troubleshooting, chasing tickets, and making sure the product did not disrupt client operations.

The direction is right. The pace of development, the investment in training, and the willingness to listen all point the same way. The gap is between how fast they ship and how fast they catch what shipping breaks.

How I got here

My first real contact with ThreatLocker was at Kaseya and Datto conferences. They put a lot into marketing, from the branding to giving away vehicles, and it works. I also liked that they had teams on shore in Florida and in Dublin.

I had tried an application control product once before, Panda Adaptive 360, back in 2018. That rollout was rough. It disrupted clients and it left an impression that took years to shake. I wrote about it at the time and Panda pushed back that the piece dwelled on the negatives. Looking at it now they were not wrong to want balance, and the product clearly had growing pains of its own.

Years later I decided to look at application control again. At a conference afterparty in an Irish pub I ended up talking to Danny, the CEO, who was sitting at a table on his own with a pint. A friend of mine, an MSP decision maker from Chicago running ThreatLocker on more than a thousand machines, vouched for it: a learning curve, but no disasters. We sat with Danny for twenty minutes, joking around and hearing about his keynote trip to Saudi Arabia. Personable, genuine, obviously invested in what they were building.

What pulled me back was the promise of consolidating agents and escaping the false positive treadmill. Other EDR platforms, SentinelOne included, kept flagging ordinary behaviour in Excel, in Carbonite, in software people use every day. Application control plus application level firewalls plus RingFencing is a more precise way to draw the lines. It reminded me of a FreeBSD jail: not a whole virtual machine, just containment at the right level.

What is good

They move. The agent and the portal both update roughly every 7 to 10 days, and the updates are substantive. Plenty of bug fixes, but real feature work too, including in modules I do not use yet. Since I started there have been more than a dozen agent releases and about as many portal releases, plus around 45 on the beta portal. Hundreds of individual changes.

You can control the pace. Slower or faster release rings, applied per machine group. That is the right lever to give someone running this in production.

The portal is clean. Not bloated, logically laid out, a reasonable balance of simple and deep. A few things sit a click or two further away than I would like, which is normal for a tool with this much surface area.

Nothing catastrophic. My Panda experience was bluescreens, lag, and performance complaints. ThreatLocker has caused nothing like that. There were reports of trouble with Windows 24H2 updates that I did not hit, and I still took the beta fix early on principle.

The training is real training. It covers what you need, and the consulting sessions are useful. Mine was with someone who had actually built the training programme and knew the product cold. Weekly sessions focus on reviewing blocks, tuning policies, working tickets, and solving live problems. If I had one request it would be deeper dives per module for people who want past the basics. The format works, but it works on the condition that you do your part: watch the training, use the product, arrive with questions. These sessions are not a substitute for being hands on.

The people are good. Sales, support, everyone in between, professional and easy to deal with from day one. The documentation is well written and detailed. The one thing missing is a way to request a new article or a clarification without opening a full support ticket.

Feature requests go somewhere. Some were marked In Progress the same day. Others were marked Planned before anyone had voted. That tells me somebody reads them. What they could do better is drive participation: the feedback portal is full of good ideas sitting at single digit votes. Surface them in the interface, in emails, anywhere people will see them.

Detect is transparent. Real visibility into signatures and detections. You can see what is active, read the content, toggle things on and off, and test beta detections in your own environment. That is not a black box, and the alerts cover living off the land techniques and other quiet tactics properly.

Support, and the wrong metric

My experience of support in those 90 days was poor, and I want to be careful about where I put the blame, because I do not think it sat with the people I was talking to.

The organisation was optimising for first response time. Chat answers arrived in seconds. Tickets opened any other way often sat for days or weeks unless I went into chat and chased them. When a reply did come it was frequently from a late shift, surface level, and handed the next step back to me. At one point I had 15 to 20 tickets open, and some of the more serious ones went past two months without a meaningful update.

A ten second first reply is not support. It is an acknowledgement. What matters is how long until the problem is actually gone, and how many exchanges it took to get there. ThreatLocker is not alone in confusing the two. Microsoft will call you back in twenty minutes with a voicemail when you specifically chose email, clearly without having read the ticket. Salesforce will reply within hours, book a meeting for next week, then ask you to repeat everything you already wrote down. None of that is speed. It is the appearance of urgency.

The structural problem is what happens when chat becomes the channel that gets worked. The person in chat is often relaying questions to someone else, which means anything beyond simple turns into an hour long session with long silences while they consult internally. That is not a failure of the person in the chat window. They are doing precisely what the measurement asks of them, with the access they have been given. If first contact cannot reach the people who understand the system, you have built a relay, and the customer is the one holding the line.

The line I heard most often was that determining whether a file is malicious is the customer’s responsibility. No analysis, no discussion of whether a specific file looked wrong. Which is hard to square with Managed Approvals, where they do exactly that analysis on user requests using VirusTotal, other public sources, and their own sandbox, except when no sandbox is available at peak times, at which point the request comes back to you as an escalation.

That contradiction is not a support agent’s doing. It is a policy boundary, and it was drawn in a place that left the frontline unable to help with the most common question a customer has.

The claim I would push back on hardest is the one from the top: best support in the industry, measured by how fast chat answers. The speed is real. Measured by resolution, 47 tickets and 20 abandonments in 90 days says something different.

Friction in daily administration

These are not bugs. They are design decisions that cost the administrator time.

Agent upgrade restarts

You can restart one machine at a time, or restart the entire company including every agent that has already finished upgrading. There is no way to target just the machines that still need it. Worse, the UI shows a Pending Restart tag even when the machine was offline at the moment the command went out. That restart never happens. No queue, no retry, no indication it failed, so you believe the job is done when it is not.

Detect policy management

You pull applicable policies from the Community into your tenant. After that, the community versions keep changing and getting fixes, and you are never told. There is no version indicator. Hitting Download again gives you no way to know whether you got something new or a duplicate. Support will tell you an updated version exists; you cannot verify that yourself. I now have over 400 of these and they are effectively unmanageable, because there is no view of what I have already taken.

Detect collaboration

When an event fires there is nowhere to see whether ThreatLocker has assigned anyone to it. The Response Details section is always empty, including on events they cleared. In one case a user logged in from India and then from California ten minutes later, which is impossible travel, and it correctly triggered risk detection in Microsoft 365. ThreatLocker cleared it. I have no idea who cleared it or why. It looks like nobody correlated the earlier logins and somebody simply took the Low priority from the Microsoft side at face value, on an event that plainly warranted a look.

No current user

The console does not show who is using a machine, and there is no escalation path for approval requests that arrive by text or email. There is a feature request for this, the second most voted in the portal, open since June 2022. Three years. It is marked Planned. With roughly 1,500 requests in there and only 8 above a hundred votes, Planned starts to feel like a filing cabinet.

No justification on approvals

When a request is denied you usually get a reason, a policy reference or a specific risk. When something is approved on a judgement call, the reasoning is not captured anywhere. A Cyber Hero might approve because the app is already permitted elsewhere in the environment, or because it matches what the user base runs. Reasonable, and invisible. If it goes wrong later there is no context, and you are opening a ticket to find out why your own environment changed. A dropdown or a free text note stored on the approval record would fix this entirely. The same gap exists in reverse: when an approval is escalated to you, the reason is only in the email, so from the portal there is no record of why it landed on your desk.

Deployment and detection of deployment

ThreatLocker does not appear in Add/Remove Programs, so RMM filtering cannot reliably tell you where it is installed. The supplied deployment script does not check whether the agent is already there, so it reinstalls over working setups every time it runs. I wrote a custom check against the installation folder, which then failed because the installer creates the folder even when the install fails. Checking whether the service is running turned out to be the only dependable signal.

Diagnostics

Support cannot pull logs from an endpoint. To get them you disable Tamper Protection, log into the machine, collect the files by hand, and upload them, because as a local admin you can see the files but not read or copy them. Doing it through RMM does not work either: SYSTEM is blocked from those directories by tamper prevention, and stays blocked after you disable tamper protection. A human admin can list and read the directory, an RMM agent cannot. Meanwhile they can pull the 2 GB application database off the machine themselves for analysis, which makes the log situation harder to explain.

VDI on demand

The sandbox for analysing applications is genuinely useful and you cannot trigger it yourself. It only runs off a user approval request. Even then, plenty of things will not analyse: anything needing a runtime dependency such as .NET 8.0, any browser add in for Chrome, Firefox or Edge, and a set of other cases nobody could explain, including simply having no sandbox available at peak times. That last one produced escalations back to us.

Quality control

I appreciate the release cadence. I also notice what is in the releases. Every portal release, roughly every 7 to 10 days, carried 20 to 30 bug fixes alongside the new features, and a lot of those bugs should not have reached production. That changes how I behave: I stay in conservative rings, I do not chase versions, and I only move when a release fixes something I am actually experiencing.

What that looked like in practice, in the first 90 days.

Things blocked that were explicitly permitted

After taking a fix support recommended and moving to 10.1.x, we got widespread blocking of allowed applications. Adobe Creative Suite, Dell firmware tools, Datto RMM, others. Users were flooded with Request Access prompts for software they use daily and the help desk queue spiked. We failed open 200 machines and waited days, and were eventually told to undo the change they had recommended in the first place.

Separately, files from Datto RMM, DNSFilter and other critical tools were being blocked at random. Support traced it to the 2 GB application database being locked during high disk activity, Patch Tuesday for instance. When it cannot be read it fails closed, which blocks nearly everything that is not a Windows core file. Their advice was to enable CoreThrottle, which is what led directly to the problem above.

Ringfencing blocked Windows Defender from reaching Microsoft’s MAPS servers, which took log digging and manual IP allowances to resolve. Ringfencing Chrome broke Open in Desktop from SharePoint for some users; that one was never resolved and we worked around it. Built in policies kept missing files in completely standard software, Chrome, Outlook, Adobe, Dell, Lenovo, Office, and there is no portal function to submit those, so it was a ticket every time, more than half a dozen of them. Visio Viewer was classified as an IT tool for network scanning, which took days to get acknowledged while the user waited to install a document viewer.

ThreatLocker also blocked SentinelOne updates, breaking machines and causing real performance problems, and blocked files needed for Windows 10 to 11 upgrades until we bypassed it for the duration. Their own documentation says one security product should not need to be bypassed to update another.

The agent itself

ThreatLockerService.exe was crashing repeatedly on about 75 percent of our machines, including fresh installs. Updating .NET helped on some. Support blamed .NET and had no further way to investigate. The stub installer failed on a dozen machines with API communication errors, registered nothing in Add/Remove, and left those machines in an unknown state, so we wrote scripts to detect and repair it. No investigation into why the backend failed. An out of box Dell pulled an 8.x stub from years ago off the backend; ThreatLocker’s position was that we must have installed it previously, on a machine that had never been touched. No root cause. And one of our own techs had applications blocked during Learning Mode because the device never received the correct maintenance status. We waited 16 days, re-pushed the policy ourselves, and were told we had interfered. It took five days before anyone asked for logs.

The platform

Four portal outages in my first few months, with sessions dropped mid-use and long stretches where I could not log in. Chat from the login screen was a nice touch; the absence of a status page was not. I was told updates would be on Facebook, or on the login page, and frequently there was nothing in either place. 500 errors stopped us clearing events in the Detect dashboard, so they piled up and stayed uncleared for two and a half months. The Microsoft 365 connector logged nothing at all for 18 days despite a working Graph connection. Detect kept flagging malware in SharePoint from a community detector that had been updated upstream, and since the portal does not tell you about detector updates, finding out meant manually re-downloading across 400 plus items. Guest accounts showed as locked in VPN alerts while being active in Entra ID; after months of back and forth we were told to check again after a portal update that mentioned nothing in the changelog, and it never reached development. Errors in the Software Report function delayed our view of installed applications across the estate, first response three days.

The sandbox failed to launch at least five times, including for ThreatLocker’s own analysts, who then had to escalate requests they could not run. We fell back to VirusTotal hashes to make decisions.

And support would call us about things that did not warrant a phone call, such as a user having Skype set to start automatically.

The interface

The iPhone app crashed every time we opened logs, which took 40 days to fix, and threw raw ASP.NET errors on screen during outages. The Help Desk feature returned 500 errors on file uploads and ticket clearing. Long IPv6 addresses did not wrap in the web UI and overlapped the text beside them. Long email addresses ran off the screen in the mobile Help Desk. Microsoft 365 app approval logs did not include the application name, only vague data, which makes it hard to trace what a user actually consented to. Firefox add ons showed up as unnamed .xpi files with no identifier: Chrome and Edge both give you a path back to the store listing, Firefox did not, which made them hard to approve with any confidence.

Where I landed

Taken together, in June 2025: a product whose core thesis is correct and whose execution had not caught up with its own velocity. I would still have bought it. I would have budgeted considerably more time for the first quarter than anyone told me to.

Which brings this back to where it started. I wrote the above honestly, as the first 90 days actually went, and I published it knowing the company would read it. They did, and they fixed it. Support works differently now. The issues in this review are not the issues you will encounter.

If you are weighing application control, that response is the part I would weigh. Every platform at this stage of growth will ship something that breaks your Tuesday. The question worth asking is what the company does when a customer writes it down.