A Fortify 24x7 brand. Detection engineering and analyst response, run from a staffed security operations center.Client sign inContact
S1XDR
Home / Add-on modules / Zero Trust
Add-on family · one module

Zero Trust allowlisting

Detection asks what a program did. Allowlisting asks whether it should have been allowed to start.

Zero Trust moduleVendor: ThreatLocker
Zero Trust AllowlistingFortify-ZeroTrust

Default-deny application control with learned baselines, automated update tracking, and a 24x7 team handling every elevation request and escalation.

per endpoint
billed monthly
Loading
QTY
SpecificationFortify-ZeroTrust
Control modelDefault deny: approved software executes, everything else is blocked
Baseline creationLearning algorithms build the approved set from observed behavior across a large endpoint population
Update handlingApplication updates are tracked automatically so patched binaries do not become blocked binaries
Elevation requestsWorked round the clock by the Fortify 24x7 team rather than queued to a local administrator
PlatformEndpoint agent, deployed alongside the detection agent
Relationship to detectionIndependent control. Runs with any tier, including none
BillingCharged each month against one endpoint
01Premise

A deny list is a list of things somebody already knew about

Signature and reputation approaches share one structural weakness: they are a record of what has already been seen. Application allowlisting inverts the question. Rather than enumerating badness, it enumerates the software your business actually needs and refuses to execute anything outside that set.

The effect on the attack chain is blunt. A macro that drops a loader, a signed installer carrying an unwanted payload, a living-off-the-land binary invoked in a way nobody in your organization has ever invoked it: none of these need to be recognized as malicious. They only need to be absent from the approved set.

02Operation

How the baseline is built and kept honest

The agent learns first. It observes what runs in your environment and, drawing on behavior aggregated across a very large endpoint population, distinguishes the software your business depends on from the software that merely happened to execute once.

Update tracking is the part that decides whether an allowlist survives contact with reality. Software changes constantly, and an allowlist that treats every patched binary as a stranger becomes an obstruction inside a fortnight. Fortify ZeroTrust follows application updates automatically and streamlines approval for the rest, which is what keeps the control from being switched off by an exasperated operations team six weeks after purchase.

03 · The operational cost

It will block something you wanted. That is the deal.

Any honest description of allowlisting includes this: at some point a genuine tool will be stopped, and somebody will need it in the next ten minutes. Vendors tend to skip past that sentence. We would rather price it in.

Elevation requests and escalations go to the Fortify 24x7 team, on the same round-the-clock rota that runs the detection service. The request does not sit in a queue owned by whoever on your side still has the console password. That single arrangement is the difference between an allowlist that stays enforcing and one that gets moved to audit mode after the first bad week.

04Fit

How this sits next to the detection tiers

Allowlisting and detection are complements, not alternatives, and neither is a reason to skip the other.

  • Allowlisting narrows what can begin. Fewer executions means fewer detonations to detect, and a quieter alert stream is a genuine security outcome rather than a cosmetic one.
  • Detection covers what is already allowed. Approved software abused by a valid user is invisible to an allowlist by definition. That is exactly the territory behavioral detection and cross-layer correlation exist to cover.

Run together, the residue is small: approved tools behaving abnormally, which is a queue a staffed SOC can actually work through.

Where this module stops

It is not a detection product and carries no SOC monitoring of its own. It blocks execution; it does not investigate intent, and it will not tell you that an approved administrative tool was used against you. Pair it with a detection tier rather than treating it as one.

It also needs a learning period and a real conversation about your software estate before enforcement is switched on. Deploying default-deny to a fleet on day one without that work is how organizations end up with a very secure environment that nobody can do any work in.