ThreatLocker
Zero-trust endpoint allowlisting. Application approval requests surface in Plugboard so the ICT team actions them in one place, with a ticket attached.
| Category | Security |
| Authentication | API key |
| Reaches | Your ThreatLocker portal API |
| Needs an agent | No |
| Demo mode | Yes |
Capabilities
Section titled “Capabilities”security.listComputers, security.getComputer, security.isolate,
security.listRequests, security.resolveRequest, security.deviceHistory
Which lights up the security page, gated by the
module.security module.
Getting the credentials
Section titled “Getting the credentials”- Sign in to the ThreatLocker portal as an administrator.
- Find the API section under your organisation’s settings and generate an API key.
- Note your organisation id, which identifies your tenant within ThreatLocker.
- Note the portal API URL for your region.
ThreatLocker’s portal layout changes between versions. If you cannot find the API section, your ThreatLocker partner or account manager can point at it, and in some plans has to enable it first.
Configuring it in Plugboard
Section titled “Configuring it in Plugboard”Admin, Connectors, ThreatLocker, Configure.
Settings
Section titled “Settings”| Field | Default | Value |
|---|---|---|
baseUrl | empty | The ThreatLocker portal API URL |
organizationId | empty | Your organisation, or tenant, id |
demoMode | false | Return fixture data |
Credentials
Section titled “Credentials”| Field | Value |
|---|---|
apiKey | The API key |
Save and test.
Why this is in a service desk at all
Section titled “Why this is in a service desk at all”Because an approval request is a service desk request, and treating it as one fixes the two things that go wrong with allowlisting in a school.
It gets actioned. Approval requests that live only in a security console get looked at when somebody remembers. In the queue alongside everything else, they get worked.
It gets a reason. Attaching the request to a ticket means the record of why an application was approved sits next to who asked and who decided. Six months later, when somebody asks why a piece of software is allowed, there is an answer that is not “somebody clicked approve”.
What you can do
Section titled “What you can do”| Action | Notes |
|---|---|
| See pending approval requests | With their details |
| Approve or deny | Sent back to ThreatLocker |
| Attach to a ticket | An existing submission, or raise a new one |
| See per-device history | Previous approvals and decisions on that machine |
| Isolate a computer | Cut it off the network |
Isolation
Section titled “Isolation”security.isolate cuts a machine off the network. It is the right response to a
compromised device and the wrong response to almost everything else.
Treat it the way you treat a wipe: gate it behind a role that few people hold, and know that every use is audited.
Try demo mode first
Section titled “Try demo mode first”The approval workflow is easier to understand when you can see it. Demo mode gives you sample requests to approve, deny and ticket, so the team knows the flow before real requests start arriving.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Cause |
|---|---|
| Sample requests appear | demoMode is still on |
401 on test | Wrong API key |
403 | The key lacks the scope, or API access is not enabled on your plan |
| Empty request list | There genuinely are none, or the organisation id is wrong |
| Approvals do not take effect | The key is read-only. Resolving a request needs write access |
| Page says ThreatLocker is not connected | The connector is not enabled, or module.security is off |