Thoughts on the new 'ThreatLab' integration - is it just a dashboard widget?

Anna K. · 2026-08-02T07:05:51Z

Hey folks, I've been poking around the latest ZPA admin portal update and saw the new "ThreatLab" integration. On the surface, it looks like a new dashboard widget with some threat intel feeds and alert summaries. But I'm trying to figure out if there's more under the hood, especially from a workflow automation perspective. Has anyone dug into the API or config to see if it actually influences policy enforcement dynamically? For example, can ThreatLab scores or indicators automatically trigger a change in a microtenant's access policy, or is it purely for analyst review? I'm thinking about scenarios like automating a temporary block on a user's access to specific apps if a high-confidence threat indicator is tied to their device. I did a quick check and the main visible addition seems to be this new section in the portal JSON schema (from a browser inspect): ```json "threatLabDashboard": { "enabled": true, "widgets": ["globalThreatFeed", "userRiskSummary"], "refreshInterval": 300 } ``` This suggests it's primarily a reporting module right now. But I'm curious if anyone has found: * **Webhooks or alert triggers** that can be consumed by an external SOAR. * **Any new fields** in the `/enrollment` or `/device` API endpoints that reflect ThreatLab risk scoring. * **Granular logging changes** in the SIEM export that tie a session denial directly to a ThreatLab indicator. Without these, it feels like a nice-to-have dashboard, not a deeply integrated security feature. I love the idea, but the implementation details make all the difference for actually improving code/configuration for zero-trust workflows. What have you all found?

Page 5 / 5 Prev

Zscaler ZPA Reviews

Last Post by datadog_dave_3 1 hour ago

61 Posts

59 Users

0 Reactions

9 Views

RSS

datadog_dave_3

(@datadog_dave_3)

Estimable Member

Joined: 3 months ago

Posts: 171

04/08/2026 2:20 pm

Your schema find is correct, it shows the integration's current scope. While others have confirmed the absence of policy hooks, there is a reporting API endpoint at `/v1/threatintel/indicators`. It's undocumented but returns JSON, so you could technically poll it from an external orchestrator.

The real limitation, as you've identified, is the five minute data latency baked into the refresh interval. That makes automated blocking impractical for a live threat scenario, but it could be suitable for longer-term policy adjustments based on aggregated risk trends. So there is a data source, just not a real-time control mechanism.

null

ReplyQuote

Page 5 / 5 Prev