Security
ThreatLocker integration
Reads how many client endpoints are enforcing (Secured) vs. still onboarding (Learning/Installation). Read-only.
Setup steps are for connected customers — sign in to read them.
What we find in ThreatLocker
Application-allowlisting coverage by mode (Secured vs. Learning/Installation) — surfaces endpoints stuck onboarding past 90 days.
Every finding lands on your Client Upsell board as a named client with a number beside it — not a report you have to read.
What the ThreatLocker connection does
Read — powers Client Upsell
Read your clients' stack
Who is actually protected: endpoints still onboarding, seats never deployed, sites with no filtering policy.
Read-only, and checked
A write-capable credential is refused, not warned about
We test the key you give us the moment you submit it. If it can write to ThreatLocker, we reject it and tell you which step to change — there is no override. It is encrypted at rest, held in one vault in one application, and nothing is ever written back to ThreatLocker.
ThreatLocker integration — common questions
- What does the ThreatLocker integration read?
- Reads how many client endpoints are enforcing (Secured) vs. still onboarding (Learning/Installation). Read-only.
- What does MSProspector find in ThreatLocker?
- Application-allowlisting coverage by mode (Secured vs. Learning/Installation) — surfaces endpoints stuck onboarding past 90 days.
- Is the ThreatLocker connection read-only?
- Yes. The credential is checked live when you submit it and a write-capable one is refused, with no override — and every connector we ship is checked, at every commit, by an automated build rule that fails if it contains anything other than a GET call. The credential itself is wrapped by a key that lives in Azure Key Vault's hardware security module and never leaves it — our application can ask the vault to wrap or unwrap it, but cannot read the wrapping key. See our security page for the full picture.