Why We Stopped Using SentinelOne: Even Though It Was Already Deployed Across Every Client

Ask a room of IT people if they've heard of SentinelOne and every hand goes up. It's the Norton of the managed services world. Not dated, just everywhere. A few years back, Eric Thompson asked exactly that question in front of a room of peers. Every hand went up. Most of them couldn't tell you much else about the product, but they knew the name. That's how big SentinelOne is.

McNallan had SentinelOne deployed across every client. We had contracts. Our people were trained on it. We replaced it anyway.

Here's what happened.

SentinelOne Was Quiet, and That Was the Problem

We didn't switch because of a dramatic breach. The reality was more unsettling than that: SentinelOne wasn't showing us much of anything.

A security product should be reporting on your environment. It should be surfacing findings, flagging anomalies, catching things, even if most turn out to be benign. That's how you know it's actually watching. With SentinelOne, we were getting very little signal. And when it did flag something, it was usually a false positive.

We started asking ourselves: is this tool actually working? Is the silence a sign that our clients' environments are perfectly clean, or is it just not seeing what's there?

No matter how much tweaking and admin configuration time we spent, the results didn't change. SentinelOne stayed quiet.

What Happened When We Layered in Huntress

Rocky, McNallan's owner, and the rest of our team have a standing practice: we evaluate our security stack every six months. We go to conferences. We talk to peer groups. We run our own tests in-house before we recommend anything to a client. It's how we found Huntress.

Huntress is an endpoint detection and response platform with a critical difference from SentinelOne: it has a human component. Real analysts review threats and take action. It is not purely automated detection.

Rather than rip SentinelOne out on a hunch, we did what we always do: we tested first. We layered Huntress alongside SentinelOne in our environments so we could see what each product was catching.

We don't have a neat before-and-after metric to share (Eric is honest about that), but the difference was stark enough that no metric was needed. SentinelOne had been fully deployed, fully tuned, running for years. Huntress walked in and started finding things SentinelOne wasn't even reporting on.

If a new tool can find issues on day one that your existing tool missed for years, even after extensive configuration and tuning, then the existing tool isn't doing its job.

Why We Added ThreatLocker (and What Application Whitelisting Actually Means)

Huntress solved the detection problem. Around the same time, Rocky went to a conference put on by ThreatLocker. What he saw there shaped the rest of our security stack.

The ThreatLocker CEO was presenting at a hotel conference center. Partway through his talk he pulled out a rubber ducky. A rubber ducky is a programmable USB device that looks like a thumb drive but behaves like a keyboard. The CEO used ChatGPT to code the rubber ducky with a data exfiltration payload, right there. Then he walked down to the hotel concierge desk, dropped his room key, and when the concierge bent over to pick it up, he plugged the USB into the back of the front-desk computer. By the time he got back to the conference room, it was already sending him data.

Traditional security products, SentinelOne included, work by trying to identify bad software. They maintain databases of known threats, analyze suspicious behavior, and attempt to catch malware before it causes damage. The problem is that new threats emerge constantly, and there's always a gap between when a threat appears and when the security product learns to recognize it. Something a CEO can cook up at a podium with ChatGPT isn't in any database yet.

Application whitelisting flips the model. Instead of trying to identify everything that's bad, it only allows what's been explicitly approved. Every application on every machine is either on the approved list or it's blocked. It doesn't wait for a human or an antivirus to tell it something is good or bad. It just asks: is this accepted? If not, it doesn't run.

ThreatLocker implements this approach. Combined with Huntress for detection and response, it gave us a two-layer stack that was fundamentally stronger than what SentinelOne provided alone:

• ThreatLocker (application whitelisting): Prevents unauthorized software from executing. Binary yes or no. Is this application approved? If not, it is blocked before it can do anything.
• Huntress (EDR with human review): Monitors for threats that do make it into the environment, with real analysts investigating and responding to incidents, not just automated alerts.

How We Handled the Switch Without Disrupting Clients

Replacing a core security product across a full client base is not something you do overnight. Every deployment is different, every environment has its quirks, and in Eric's words: McNallan has never seen a cybersecurity deployment go perfectly to plan, and that's especially true in cyber.

We took a phased approach: roughly three clients at a time, starting with the ones that had the highest exposure and the most to lose. The largest, highest-paying clients went first; the three-person shops came last. The full migration took a few months.

On cost, we tried to absorb as much as possible. Swapping SentinelOne for Huntress was cost-neutral to the client. We kept the price the same. ThreatLocker was an additional layer, and that did add cost. For price-conscious clients, we offered a two-to-three-month ramp-up period where McNallan absorbed the difference. By month three, the full pricing was in effect.

Not a single client said no.

The reason isn't that we're unusually persuasive. It's that we have honest conversations with clients about security all year, not just when we need them to spend more. Every annual review, we tell clients the same thing: plan for roughly 20% more in security spending next year. When the time actually comes to make the change, the budget conversation has already happened.

What This Means for Your Business

If you're currently running SentinelOne, or any single-product security approach, the question to ask yourself isn't whether your security product is popular or well-known. The question is: when was the last time it actually caught something?

Silence from a security product is not the same as safety. A tool that reports nothing might be missing everything.