| Control model | Default deny. Approved applications execute; everything else is blocked before it runs |
|---|---|
| Platform | ThreatLocker application allowlisting, deployed and operated by Fortify 24x7 |
| Coverage | Windows and macOS workstations and servers |
| Learning period | The agent catalogues what your business already runs before enforcement is switched on |
| Update handling | Vendor update tracking keeps patched binaries approved without a manual re-approval each cycle |
| Elevation requests | Raised from the endpoint and answered by our operations desk, 24 hours a day |
| Ringfencing | Approved applications are constrained in what they may launch, read, and reach |
| Storage control | Policy on removable media and network shares, including read-only and deny states |
| Audit trail | Every approval, denial, and exception is recorded against the endpoint and the requester |
| How it is billed | One rate for each protected endpoint, charged monthly, with no lock-in |
Detection is a guess about a file. Allowlisting is a decision about your estate.
Signature and reputation engines answer a question about the wider world: has anyone seen this file behave badly before. That question fails in exactly the cases that matter. A loader compiled for one campaign has no reputation. A signed remote-access tool has an excellent one. A script interpreter that ships with the operating system has never been malicious in its life, right up until somebody uses it against you.
Default deny inverts the question. Rather than asking whether an unknown binary is dangerous, the endpoint asks whether it is on the list of things this business runs. If it is not, it does not execute, and nobody has to have been clever enough to recognise it first.
This is the reason it sits first on the board. Every other control on this site improves how quickly you learn that something ran. This one is the only control that decides whether it runs at all.
Learn the estate, then enforce it
Deployment starts in learning mode. The agent inventories what is genuinely installed and genuinely used across your machines, which is almost never the list anyone would have written from memory. That inventory becomes the policy, so enforcement begins from your actual operations rather than from a vendor template.
Once enforcement is live, three mechanisms carry the day-to-day load:
- Update tracking. Approved applications change hash on every patch. The platform follows vendor releases so a Tuesday update does not become a Tuesday outage, which is the failure that has killed most allowlisting projects historically.
- Ringfencing. Approval is not the same as permission to do anything. A spreadsheet application has no business launching a script interpreter, and a backup agent has no business reading the browser credential store. Ringfencing draws those boundaries between approved programs, which is what blunts living-off-the-land technique before it starts.
- Storage policy. Removable media and network shares get their own rules, so an unknown USB device is a prompt rather than an incident.
Yes, it generates requests. That is why the desk is included.
We would rather set this expectation now than have you discover it in week two. A default-deny estate produces elevation requests, especially in the first fortnight and especially from the people who install their own tools. There is no configuration that makes that go away, and any vendor implying otherwise has not run one.
What changes the experience is who answers. Requests reach our operations desk around the clock, and the response is a decision rather than a ticket that ages. Your internal staff are not the approval queue, which is the arrangement that quietly turns most allowlisting deployments into a permanent allow-everything policy within a quarter.
What this stops, and what it does not
It stops execution. Ransomware payloads, unapproved remote-access tooling, credential dumpers, cryptominers, and the long tail of unknown binaries do not start. Abuse of approved software through ringfenced paths is constrained.
It does not stop a valid login. An attacker holding working credentials who uses sanctioned software the way it is meant to be used has not broken an allowlist rule. That is why this line pairs with detection above it and with mail security below it: identity abuse is a different failure and needs a different control.
Speed of response is worth less than removing the need for one
An operations desk that contains a detonation in four minutes is doing excellent work, and the business still spends the following week restoring, notifying, and explaining. A policy that refuses to run the payload produces a support request instead.
The two controls are complementary rather than alternative. Allowlisting shrinks the ground an intruder can stand on; managed detection watches what remains, including the approved tools nobody can block. Businesses that buy only the second one are paying for a faster description of the same bad week.
Where this stops
This is prevention, not forensics. Allowlisting deployed today constrains what runs from today. It does not reach backwards into an account that is already compromised, a mailbox rule that was already planted, or data that has already left. If you are dealing with an active intrusion, open a case first and let us tell you what is in scope before you buy anything.
Enforcement covers application execution and storage access. It is not a firewall, an identity provider, or a substitute for multi-factor authentication, and it makes no representation about regulatory compliance on its own.