Detection asks what this is. Allowlisting asks whether it was invited.
Everything else in the list makes a judgement: this file looks wrong, this behaviour resembles ransomware, this address has a poor reputation. Judgements are probabilistic and the good ones are very good, but they are still judgements.
Allowlisting asks a different question, and it is one with a definite answer. Was this program approved for this machine? If it was, it runs. If it was not, it does not run, and it makes no difference whether it is famous, novel, signed by somebody convincing, or written last Tuesday for you specifically. Malicious software cannot execute on a machine that will not execute anything unfamiliar.
The learning period, and why it is short.
The first phase is observation. The agent learns what this machine genuinely runs: the editing suite, the accounting package, the browser, the videoconferencing tool somebody installed for one meeting in April. That inventory becomes the policy.
The learning does not start from nothing. ThreatLocker, the default deny engine beneath this line, draws on the behaviour of an enormous population of endpoints, so ordinary legitimate software is recognised at once rather than argued about. What remains after that is the genuinely unusual, which is a short list, and it is the list a person should look at anyway.
Updates, and the thing everyone actually asks about.
The honest objection to allowlisting is not security. It is that a rule which blocks unapproved software also blocks the update that arrived this morning, and a control which interrupts work gets switched off within the quarter.
Two things address that. First, updates to approved applications are followed automatically, so a fresh version of something already permitted is recognised as that thing rather than as a stranger. Second, when a genuine request does need a decision, it comes to our desk, not to you. Elevation requests and escalations are handled by staff on duty at every hour, which is the entire difference between a control that survives and one that becomes an anecdote about why nobody uses it any more.
Where we would and would not put this.
Allowlisting is superb on machines with a defined job: the business manager\'s workstation, the machine that touches banking, the assistant\'s laptop, the server. Those estates change slowly and the policy is quiet within a fortnight.
On a principal\'s personal laptop it depends entirely on the person. Somebody who installs things constantly out of curiosity will find it intrusive at first, and we will say so before you buy rather than after. It is sold per computer for exactly this reason: put it where it fits and leave it off where it does not.
| Built on | ThreatLocker, whose engine refuses by default |
|---|---|
| Model | Default deny: what was approved runs, and nothing else is allowed to start |
| Learning | An observation period that inventories what the machine genuinely runs |
| Reference | Behaviour drawn from an enormous population of endpoints, so ordinary software is recognised without debate |
| Updates | Updates to permitted software followed automatically and passed as the same product |
| Requests | Anything needing approval reaches our desk, at any hour of the day |
| Placement | Applied per computer, at your instruction |
| Billed | Monthly, for each computer |
Where this line stops
Allowlisting governs what executes. It does not watch an approved program doing something it should not, which is detection and response, and it does not stop a person from being persuaded to hand over a password, which is mail and correspondence.
It applies to computers. Phones run a platform that already restricts execution in its own way, and are covered by Phone Protection.