ThreatLocker
Default deny, explained properly
Most endpoint products decide whether software looks malicious. ThreatLocker inverts the question: software that has not been approved does not run, and software that has been approved is still fenced in to what it legitimately needs.
Why detection has to be right every single time
A detection product succeeds by recognising something bad. That is a harder promise than it sounds, and the failure mode is quiet.
Nothing has seen it yet
A binary compiled this morning has no reputation and no signature. Behavioural analysis can still catch it, but only after it has begun to behave, which means after it has started doing the thing you did not want done.
The tool is already trusted
Attackers increasingly avoid malware entirely and drive the administrative utilities already present on the machine. Those utilities are legitimate, signed and expected, so the question a detection engine has to answer is one of intent rather than identity.
Signed does not mean safe
Software arriving through a legitimate update channel carries the publisher's signature whether or not that publisher was compromised. Trust anchored to the signature alone inherits the publisher's security as well as their code.
You learn about the miss afterwards
When detection works, there is an alert. When it does not, there is nothing at all, and the absence looks identical to a quiet week. That asymmetry is the argument for a control that fails closed instead.
From learning mode to enforced, step by step
The sequence below is the part worth understanding before you buy, because the middle of it is where the work actually falls.
Learn what already runs here
The agent is deployed in a learning mode that catalogues the software genuinely in use across the estate, rather than the software somebody believes is in use. ThreatLocker describes this period as lasting roughly one to two months. Expect it to surface applications nobody remembered approving, which is itself a useful finding.
Turn the inventory into a policy
What was learned becomes the allowlist: permitted applications, the publishers and paths they are permitted under, and the users or groups they apply to. This is a decision-making exercise rather than a technical one, and it is where the deployment either gets done or stalls.
Fence each approved application in
Ringfencing constrains what an approved application may do: which files it may touch, which registry keys, which network destinations, and which other applications it may launch. This is what stops a trusted utility being turned against the machine it is trusted on.
Enforce, and handle the requests
Once enforcement is on, anything outside policy is blocked and the user can request approval. ThreatLocker staffs a team to review those requests, and publishes a target of responding within minutes during business hours. Confirm the current commitment and its hours for your region before relying on it.
The controls, and what each one is actually for
Application control is the headline. The surrounding controls are what make it survivable day to day.
| Control | What it does | What it prevents |
|---|---|---|
| Allowlisting | Permits only approved software to execute | Unknown and newly compiled payloads running at all |
| Ringfencing | Limits what an approved application may reach | Legitimate tools being weaponised against the host |
| Storage control | Governs access to drives, shares and removable media | Bulk copying to a USB device or an unapproved share |
| Elevation control | Grants administrative rights to specific applications | Standing local administrator accounts on every desktop |
| Network control | Host level policy over inbound connections | Lateral reach from one compromised workstation |
Where default deny works, and where it will be resented
A strong fit
Estates with a stable, well understood set of applications: finance, healthcare, manufacturing, professional services, and any organization already being asked by an insurer or a regulator to demonstrate application control. It also suits environments where the endpoint population is largely standardised, because the policy stays small.
A weaker fit
Teams that install new tools constantly and unpredictably, developer workstations above all, will generate approval requests faster than anyone wants to process them. If your engineers compile and run new binaries hourly, expect to carve out a different policy for them rather than pretending one policy fits the estate.
It is not a replacement for detection
Preventing execution does not tell you that someone is signing in from an unexpected country, and it does not investigate an incident for you. ThreatLocker sits alongside endpoint detection and identity monitoring rather than in place of them. Anyone selling it as a whole security programme is overselling it.
The real cost is attention in month one
The licence is the small part. The genuine cost is the learning period and the first weeks of enforcement, when policy gaps surface as blocked work. Budget somebody's time for that deliberately, because underestimating it is the most common reason a default deny rollout is abandoned halfway.
See what is running before deciding what to block
The sensible first step is the inventory, not the policy. Learning mode on a representative group of machines will tell you within weeks whether default deny is a small project here or a large one, and that answer is worth having before anything is committed.
See the architecture reviewGet in touch with Your Company
Questions about this solution? Reach us directly.