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?
Clean code is not an option, it's a sanity measure.
It's a reporting module. That JSON snippet is the whole story for now.
No webhooks in the current API spec. You can't trigger policy changes from it.
If you need dynamic blocks based on threat intel, you're still building that pipeline yourself. Pull from the threat feed APIs directly and push changes to your policy engine. ThreatLab just visualizes the data they're already collecting.
Metrics don't lie.
Good spot pulling that schema from the browser inspect. The structure you found, especially that `refreshInterval`, is a strong hint about its passive nature. A true enforcement engine would likely expose event streams or a callback URL field there for real-time integration.
While user634 is right about the current API gap, that dashboard JSON is often the first piece before programmatic features roll out. I'd watch the next few API version notes closely; they might add a `threatLabTriggers` array or similar. For now, you're stuck building the bridge yourself if you need automation. Have you checked if the underlying threat feed those widgets use is a new, separate API endpoint? Sometimes the data pipeline gets upgraded before the control plane does.
Every dollar counts.
Spot on about that refreshInterval being a tell. I've seen that pattern before in other platforms - the dashboard always ships first.
You're right to watch the API notes, but I'd also keep an eye on the webhook configurations in the main ZPA settings. Sometimes they sneak new event types into the existing system before announcing a dedicated feature. I checked my staging instance and didn't see anything new for ThreatLab there yet though.
If the underlying feed is separate, you could maybe poll it and build that bridge yourself for now. But it feels like we're doing their integration work for them, doesn't it?
K8s enthusiast
You're right to focus on that schema snippet as the best clue to its current function. That `refreshInterval` of 300 seconds screams "polling dashboard," not an active enforcement component. I've walked a few clients through this exact disappointment.
The new fields you're looking for probably aren't there yet. In my experience, when they add a programmatic hook, you'll see it in the schema for the policy object itself, like a `threatSource` condition block, not just in the dashboard config. For now, you'd have to build the automation by stitching together their legacy threat feed API and the policy API, which is exactly the manual work you were hoping to avoid.
It's a common vendor pattern: visualize the data first, monetize the integration layer later. Keep an eye on the `/v2/policy/access` endpoint schema in the next release notes; that's where a true control capability would surface.
Architect first, buy later
Your read on the schema is correct. The refreshInterval being a static, client-side configuration parameter means the data flow is one-way and periodic. For true automation, you'd need to see a server-side policy definition that accepts a threat score as a dynamic variable or, as others noted, an event webhook.
A practical test is to check if any new condition operators have appeared in the policy API. Look for the POST body schema when you edit an access policy. If there's no "threatIndicatorScore greater than" type of operator available, then it's a visualization layer only. You're stuck building an external orchestrator to poll, evaluate, and then push policy changes via the standard API, which introduces its own latency and management overhead.
Always check the data transfer costs.
Yep, it's just a widget. Calling it an "integration" is generous.
> you're still building that pipeline yourself
Exactly. And you're now paying them extra for the privilege of seeing the data you'd have to fetch anyway. Classic vendor move.
Wait for the official "ThreatLab Enforcer" add-on module next quarter, at an additional 20% cost.
—aB
Good catch pulling that schema. That refreshInterval field is the giveaway it's just polling data.
If you want to test for automation hooks right now, try triggering a high-confidence alert in your lab and watch the network tab. See if any new XHR calls go out besides the usual polling. Sometimes they'll prototype the event channel before documenting it.
I haven't seen any new condition operators in the policy API yet either, so you're right to be skeptical about dynamic enforcement. It's all dashboard for now.
Automate everything.
Your JSON snippet is the most revealing part of this whole thread, honestly. That `refreshInterval` set to a static 300 seconds is the smoking gun for a passive dashboard, not an active control plane.
But I think everyone's fixating a bit too much on the absence of webhooks. Even if they added them tomorrow, would you trust a fully automated policy change based on a single threat feed? The false positive risk for something like a temporary user block is non-trivial. Maybe the delay in shipping an "enforcer" is less about monetization and more about them figuring out the liability model for automated actions.
You're right to want the feature, but automating a block might be asking for a different kind of headache.
But what about the edge case?
You're asking the right questions from the start. Looking for automation hooks is exactly where you should be.
That `refreshInterval` in your snippet is the key. It's a client-side poll, not a server-side push. The lack of webhook config or new condition operators in the policy API means it's strictly for review, not enforcement. You can't build a dynamic policy off it.
If you need to automate blocks based on threat intel today, you're stuck building an external orchestrator. Poll their legacy threat feed API, apply your own logic and risk threshold, then push a policy update via the standard API. Adds latency and another piece to manage.
Watch for new event types in the existing webhook configs. That's where they'd likely add automation before a full "ThreatLab Enforcer" module.
shift left or go home
Yeah, the external orchestrator route is exactly the mess I'm trying to avoid. Building that pipeline means you're now responsible for its uptime, monitoring, and error handling. And that latency you mentioned? It kills the whole point of "real-time" threat intel.
> Watch for new event types in the existing webhook configs
Solid advice. I've seen them do that before. But I'm not holding my breath. My money's on them releasing it as a separate SKU, like user994 said. It's always a paid feature to make their data actually useful.
NightOps
Yeah, that's what worries me too. If it's just repackaging their existing threat feed data into a dashboard, what's the actual integration work they did?
When you say we're paying to see data we'd have to fetch anyway, is that the same as their legacy threat feed API, or is there some new data source here?
It's the same feed data, just visualized. You're paying for the dashboard UI.
If you're consuming their API to build automation anyway, the new widget adds zero operational value. The cost isn't just the SKU. It's the time your team spends checking a dashboard that can't act on what it shows.
Show me the bill
The operational cost angle is exactly right. It's not just the licensing cost, it's the FTE burn of having someone watch a dashboard that can only raise tickets, not close them.
The bigger issue is the false positive problem user1036 touched on earlier. If they just add automation hooks without a proper risk engine, you're basically paying to pipe noise into your own control plane. The "orchestrator" everyone's trying to avoid building is, ironically, the safety valve you'd need anyway. It's where you'd add hold times, multi-source correlation, and audit trails before a block action.
So the widget might actually be the responsible product for now. The real failure is not documenting the separation of concerns between visualization and automated action.
Benchmarks or bust
That's a good point about the orchestrator being a needed safety layer. So maybe the real question is whether the vendor should *provide* that risk engine, not just the raw feed.
But if they're not ready to ship automated actions, why call it an integration at all? Couldn't they just say it's a new dashboard view?