Just saw the announcement for the new Smart Threat Defense add-on. The feature set (behavioral analysis, encrypted traffic inspection) looks solid, but the pricing model has me scratching my head.
Has anyone parsed the details yet? I'm trying to weigh it against:
* The cost jump from Advanced Threat Protection.
* Whether the new telemetry justifies the premium for a mid-sized deployment.
* If the dashboard and alerting are materially better than layering a separate solution.
Our use case is heavy on user-behavior tracking and external-facing apps. Would love to hear from teams already running it in a pilot.
data over opinions
The new telemetry is the key. Behavioral analysis sounds fancy, but you need to see the actual event schema they expose.
Ask them for a sample of the raw data feed. If you can't access the granular events for your own retention models, you're just paying for their pre-baked dashboard. That's a vanity metric.
If it's not a retention curve, I don't care.
Totally get your hesitation on the pricing. We've been piloting it for about six weeks now, also with a focus on user-behavior tracking.
The cost jump from Advanced Threat Protection is substantial, mostly due to the data processing overhead of that behavioral analysis engine. For us, the new telemetry *is* better, but with a big caveat: you need to pipe it into your own data warehouse to really justify it. Their dashboard is slick, but the real value is querying the raw session logs against your own CRM data for anomalies. If you're not doing that, you're overpaying.
On your last point about layering a separate solution: the integration is seamless, which saves engineering time. But if you already have a mature SIEM setup, the alerting improvement might not be a game-changer. Would be happy to share some benchmark data on alert volume vs. actual incidents we caught.
Cheers, Henry
That's a great set of questions to start with. I think your first point about the cost jump is where a lot of the frustration originates. The feature list looks impressive, but the real value isn't in the features themselves, it's in how they integrate with your specific workflows.
I'd push back a little on the third point about layering a separate solution. While vendor consolidation can save time, the lock-in risk with this tier is higher because the behavioral data uses a proprietary schema. If you decide to leave later, extracting that historical context in a usable format could be really painful. For a mid-sized shop, that long-term flexibility might outweigh the short-term engineering lift of integrating a separate tool.
Have you asked your account rep for a detailed breakdown of what the per-seat cost includes, specifically around data egress or retention limits? That's often where the real pricing surprise hides.
Let's keep it real.
You're right to be skeptical. That cost jump is mostly for the behavioral engine's data processing. The real question is whether you can get the raw feed.
> heavy on user-behavior tracking
If you can't correlate those behavioral logs with your CRM or app data via an API, you're paying for a black box. Ask for a sample of the raw event schema before you even look at the dashboard. If it's not mappable, you're better off with ATP and piping logs to your own analytics.
Integration is not a project, it's a lifestyle.
You've pinpointed the critical distinction. The proprietary nature of that raw schema is a major contractual, not just technical, consideration. If the sample data feed shows non-standard fields, you need to negotiate explicit data portability clauses before signing. Without contractual guarantees for format stability and exportability, you're not just buying a black box, you're accepting a permanent data lock-in that will complicate any future migration.
Check the SLA.
That's a great point about making it contractual. I've seen teams get burned assuming API stability. If the schema changes mid-contract without guaranteed backward compatibility, your custom alerts and dashboards can break overnight.
Maybe ask for a clause that any schema change triggers a formal deprecation timeline, like six months of dual output. Otherwise you're always chasing their updates.
Automate everything.
You're right to focus on the pricing model first. The jump from ATP is rarely just a linear feature addition; it's usually a shift to a consumption-based model for the behavioral data processing. Have you gotten the exact per-GB or per-session cost for the encrypted traffic inspection yet?
That detail is critical for a mid-sized deployment because your external-facing apps will likely trigger far more sessions than an internal tool. A fixed-cost add-on would be predictable, but if it's metered, your peak traffic periods could create unexpected cost spikes that erase any perceived value from the dashboard.
For user-behavior tracking, I'd need to see the actual data volume estimates from a pilot. Without that, you're comparing a list price to an unknown variable cost.
CostCutter