Overview

ThreatLocker is a cloud-managed, Zero Trust endpoint protection platform built around default-deny Application Allowlisting. A lightweight endpoint agent enforces policy locally from a cached copy, so protection continues even if the endpoint temporarily loses connectivity to the ThreatLocker portal. Beyond application execution control, the platform bundles several modules that extend the same default-deny philosophy to other parts of the endpoint: Ringfencing (containing what an allowed application can do), Storage Control (removable media and file access), Network Control (host-based dynamic-ACL firewall), Elevation Control (endpoint privilege management), and Detect (policy-based EDR).

This article covers ThreatLocker-specific configuration and terminology. For the underlying theory — trust models, default-deny rationale, deployment methodology, common bypass techniques, and alignment with the ACSC Essential Eight and NIST SP 800-53 — see the vendor-agnostic Application Control article; this article maps that theory onto ThreatLocker's concrete implementation rather than repeating it.

Architecture and Console Hierarchy

Management is entirely through the cloud portal (portal.threatlocker.com, with regional tenants available). Policy is organised in a hierarchy:

Entire Organization
  └── Computer Groups (e.g. Workstations, Servers, Privileged Workstations)
        └── Individual Computers

Policies can be assigned at any level via the Applies To scope on a policy. ThreatLocker also maintains Global (built-in, vendor-curated) policies that sit beneath your organisation's custom policies. As with any hierarchical policy model, plan the Computer Group taxonomy before mass deployment — mirroring the risk-tiered grouping already recommended in Windows Workstation Hardening and the CrowdStrike Falcon article (at minimum: general workstations, servers, and a stricter group for privileged/sensitive users) makes it possible to run different Maintenance Modes and Ringfencing strictness per tier rather than a single organisation-wide setting.

Application Control (Allowlisting)

Application Definitions

ThreatLocker identifies an "application" for policy purposes using one or more of these methods:

This maps directly onto the trust-model taxonomy in Application Control — ThreatLocker's own guidance to prefer Hash over Path echoes that article's general recommendation to default to hash/publisher rules and treat path rules as the weakest acceptable option.

Built-In Application Catalog

ThreatLocker maintains a catalog of 15,000+ pre-built, vendor-curated application definitions (built from hash and certificate data), which substantially reduces the effort of building an initial allowlist compared to authoring every rule from scratch — a meaningful practical advantage over a bespoke WDAC/AppLocker policy built entirely in-house.

Policy Actions

Each policy resolves to one of four actions: Permit, Deny, Ringfenced, or Elevated. Ringfenced and Elevated are not simple allow/deny outcomes — they layer additional constraints or privileges onto a Permit decision (see Ringfencing and Elevation Control below).

Maintenance Modes (Rollout Path)

ThreatLocker's Maintenance Modes are the mechanism for the phased audit-to-enforcement rollout recommended generally in Application Control. They are set per Computer Group (or per computer) and can be scheduled to change automatically:

Important nuance: because Learning Mode leaves Ringfencing and Storage Control fully enforced, a poorly-scoped Ringfencing policy can still disrupt users even while Application Control itself is in Learning Mode — don't assume Learning Mode means "nothing is enforced yet."

Recommended rollout, following the general methodology: run Learning Mode for 2–4 weeks per Computer Group to build a baseline, review the auto-created policies (tighten any that are broader than necessary — e.g. replace an auto-generated Path rule with a Hash rule where practical), move a pilot group to Secured Mode, then expand ring by ring, leaving servers and privileged workstations for last once the policy set is proven.

Ringfencing

Ringfencing is ThreatLocker's answer to the gap called out in the general article's "What Must Be Controlled" section: an application being allowed to run doesn't mean it should be allowed to do anything it wants. Ringfencing restricts what a Permitted application can do once it's running — its ability to:

• Launch or interact with other applications (blocking, for example, an Office application from spawning powershell.exe or cmd.exe)
• Read or write specific files and local data stores
• Access the Windows registry
• Reach the network or the internet

This directly mitigates the living-off-the-land and script-abuse bypass techniques described in the general article — a signed, legitimately Permitted application (a browser, an Office app, a PDF reader) is still a viable attack vector if a malicious document or exploit gets it to spawn a script interpreter or exfiltrate data, and simple allow/deny application control has no answer to that. Ringfencing does.

Recommend Ringfencing by default on:

Storage Control

Storage Control extends default-deny to removable media, network shares, and monitored local folders, with a central audit trail of file and document access. Apply the same exception-governance discipline described in the general article's "Handling Exceptions" section: default to deny, scope any approved-device exception as narrowly as possible (a specific device serial rather than an entire vendor ID where feasible), require a documented business justification, and review exceptions periodically rather than letting them accumulate indefinitely.

Network Control

Network Control is a host-based, application-aware firewall using dynamic ACLs — ports and connections are closed by default and opened only for approved application/user/destination combinations. Because enforcement happens on the endpoint itself, it travels with the device: a laptop outside the corporate network perimeter is still protected by the same default-deny network posture, which traditional network-based segmentation cannot provide for roaming or remote endpoints.

Elevation Control

Elevation Control removes standing local administrator rights from end users while allowing specific, approved applications or installers to run elevated on a policy-driven, just-in-time basis — the user never needs to be a local admin to run something that legitimately requires elevation.

This is worth calling out explicitly: Elevation Control implements a second, separate ACSC Essential Eight strategy — "Restrict Administrative Privileges" — in addition to the Application Control strategy covered by allowlisting itself. Removing standing admin rights directly shrinks what a compromised user session can do (install software, disable security controls, access other users' data) regardless of whether the initial compromise came through a permitted application.

Detect (EDR)

ThreatLocker Detect is a policy-based behavioural detection layer running alongside allowlisting — monitoring for indicators of compromise (e.g. abnormal RDP activity, multiple failed logins, anomalous/impossible-travel access patterns) and executing predefined automated responses (isolating a host, killing a process) when a policy match fires.

This is the ThreatLocker-native fulfilment of the general article's closing recommendation to pair application control with behavioural detection rather than deploying allowlisting as a sole control — allowlisting stops unapproved code from executing, but a sophisticated attacker operating entirely within already-permitted software (or abusing a Ringfencing gap) still needs a detective backstop. See Endpoint Detection and Response (EDR) for the general EDR concepts this module implements.

Approval Request Workflow (Exception Handling)

When a user hits a Deny policy, ThreatLocker surfaces a pop-up allowing them to submit an Approval Request with a justification. This can route to your own IT team, or — as a managed option — to ThreatLocker's 24/7 Cyber Hero team, who target a response in roughly 60 seconds.

Operational gotcha to know before relying on this: approving a request scoped to the single requesting computer deploys the resulting policy to that machine automatically. Approving a request scoped to a Computer Group or the entire Organization does not automatically push it to every other member — an administrator must separately trigger Deploy Policies to roll it out fleet-wide. This is a common source of "I approved it, why is it still blocked everywhere else" confusion during rollout.

Govern this workflow the same way the general article recommends for exceptions generally: require a documented justification and an accountable approver, prefer the narrowest Application Definition available (Hash over Path) when building the resulting policy, and periodically review accumulated approvals rather than treating them as permanent by default.

Deployment

1. From the portal, use Install Computer to generate an installer for the target Computer Group
2. Choose a deployment method: manual install, RMM-based push, or a PowerShell-based install script
3. Choose the installer type appropriate to the deployment method (stub installer, MSI, or PowerShell script) — the exact command/package is generated per-organisation from the portal, since it embeds your organisation's identifier
4. Confirm the agent checks in and the computer appears under the intended Computer Group before relying on policy targeting

Alignment with the ACSC Essential Eight and NIST SP 800-53

Full maturity-level detail is covered in Application Control and isn't repeated here. In summary:

• Application Control (Allowlisting) maps to the Essential Eight's Application Control strategy and NIST SP 800-53 CM-7(5) (Authorized Software / Allow-by-Exception) — Hash-based Application Definitions in Secured Mode are the closest fit to that control's deny-all, permit-by-exception model.
• Elevation Control additionally maps to the Essential Eight's separate Restrict Administrative Privileges strategy — worth tracking distinctly in a maturity assessment, since a single ThreatLocker deployment can advance two of the eight strategies at once if both Application Control and Elevation Control are actually enforced (not just licensed).

Hardening Checklist

References

• Application Control
• Endpoint Detection and Response (EDR)
• CrowdStrike Falcon: Configuration & Settings
• ThreatLocker Application Control Quick Start Guide
• ThreatLocker — Managing Application Definitions
• ThreatLocker — Maintenance Modes
• ThreatLocker — Ringfencing
• ThreatLocker — Detect (EDR)
• ACSC Essential Eight Maturity Model