Skip to main content
ThreatLocker connects to Wirespeed through the PortalAPI. Wirespeed synchronizes endpoint inventory and polls the Unified Audit for enforced denies.
ThreatLocker portal users are administrative accounts, not a directory of people on endpoints. Wirespeed treats usernames from endpoints and audit events as observables. Connect your identity provider separately for directory context.

Create a ThreatLocker API user

  1. In the ThreatLocker Portal, navigate to Users > API Users.
  2. Create an API user for Wirespeed with access to the target organization.
  3. Grant the API user permission to view computers and the Unified Audit.
  4. Generate and copy the API token. ThreatLocker displays it only once.
The token is sent verbatim in the Authorization header. Do not add a Bearer prefix to the PortalAPI token.

Find your instance and organization

Your PortalAPI hostname has the form portalapi.INSTANCE.threatlocker.com. Enter only the INSTANCE value in Wirespeed, such as g, ca1, or eu1. For every integration, open Manage > Organizations, select the target organization, and copy its Organization ID GUID. Use the primary organization’s GUID for a direct customer and the target child’s GUID for an MSP-managed customer. An MSP parent API token can be reused across child integrations; Wirespeed scopes every request to the Organization ID you enter.
Create one Wirespeed integration per ThreatLocker organization. Each integration reads only the organization whose ID it is configured with.

Connect ThreatLocker in Wirespeed

  1. In Wirespeed, navigate to Integrations > Add Integration > ThreatLocker.
  2. Enter the PortalAPI instance.
  3. Enter the target Organization ID.
  4. Paste the raw ThreatLocker API token into API Token.
  5. Complete the integration.
Wirespeed validates the token by requesting one computer and a short Unified Audit search from the configured organization. Setup fails if the API user cannot read either.

Data ingested

Wirespeed synchronizes:
  • ThreatLocker computers: ID, hostname, operating system, last check-in, and logged-in user when returned by the PortalAPI
  • Unified Audit true denies: actions ThreatLocker actually blocked, excluding monitor-only (simulated) denies. Each deny becomes a blocked detection. The endpoint, user, process, file path and SHA-256, matched policy, and source/destination IPs are included when the PortalAPI returns them for that deny.
The first sync reads the previous 24 hours. Later syncs continue from the most recent deny already ingested. Each sync reads at most 10,000 denies; when a window holds more, the next sync resumes from the last deny read.

Current limitations

  • Endpoint isolation and lockdown are not available through this integration.
  • ThreatLocker does not assign a severity to Unified Audit denies, so every deny is ingested at medium severity.
  • Only true denies are ingested. Permitted actions and ThreatLocker Detect alerts are not.
  • Detection categorization remains non-escalating until ThreatLocker WDC rules are defined.