Just spent the last two quarters arguing with finance and ThreatConnect's sales about our bill. It's ballooned, and not because we're swimming in data or fancy features. It's because we hired three more analysts.
The per-user licensing model feels like a tax on operational maturity. A team of five analysts might be "efficiently" covering a product. When an incident hits and you need to surge—or you just grow as a company—your ThreatConnect cost scales linearly with headcount, not with value derived. The analyst staring at the console for eight hours pays the same as the one who logs in for 30 minutes to validate a single dashboard. There's no concept of lightweight, read-only users or session-based pricing.
I've seen this movie before with other "seat-based" enterprise tools. It creates perverse incentives:
* Teams share logins (a security risk for a *security* platform, ironic).
* You start gatekeeping platform access, which defeats the purpose of a collaborative threat intel platform.
* Budget discussions become about "license headroom," not "how do we get more teams integrated."
Contrast this with, say, a consumption model based on indicators processed, workflows executed, or API call volume. That aligns cost with actual platform usage. Our usage patterns look like this:
```
Peak Users (Concurrent): ~4
Total "Named Users": 12
Monthly Workflows Executed: ~15,000
API Calls (External Intel Feeds): ~2 million
```
We're paying for 12 seats. We'd be far better off if the cost was tied to the 15k workflows or the API volume.
So, am I wrong? Does this model actually make sense for a growing security team, or is it just a legacy cash cow that hasn't caught up to how platforms are actually used?
You've hit on a fundamental misalignment in value capture. The per-user model assumes uniform utilization, which is rarely true in operational teams. It's the same reason I benchmark database throughput, not just connection counts.
You mentioned a consumption model as an alternative. That can introduce its own perverse incentives, like punishing teams for efficient data ingestion or creating unpredictable cost spikes during incidents. The ideal might be a hybrid: a base fee for platform capacity (nodes, data volume) topped with graduated user fees that discount low-activity or read-only sessions.
Your point about shared logins creating a security risk is the real kicker. When the licensing structure actively encourages bad security hygiene in a security product, the model is broken. I've seen teams run "benchmarks" to justify consolidating onto fewer licensed users just to prove the point to sales.
-- bb42
Yep, the per-user model is a tax on collaboration. It makes you treat logins like gold.
We hit the same wall with Splunk years ago. You end up with a privileged class of "primary users" and everyone else has to beg for access. Kills adoption of the tool you just bought.
I like the hybrid idea from the next post. But vendors won't move unless enough teams push back. Your finance team arguing is a good start.
—cp
Seen it with Salesforce, HubSpot, the whole lot. They all do it.
You're right about the perverse incentives, but the consumption model you mentioned at the end is just as bad. Now you're worrying about analysts *using the tool too much* because each click costs money. That also kills collaboration.
Only way it changes is if enough companies refuse to sign. But good luck getting procurement to hold that line.
CRM is a necessary evil
Exactly. The fear of "using the tool too much" is a real mood killer. I saw a team gatekeep a Looker license so hard that junior folks just stopped asking questions, which defeated the whole point of buying it.
The procurement problem is real, but the security angle is the vendor's weak spot. If you can show their pricing model forces shared credentials or stifles audit trails, you have a better argument than just cost. It reframes the conversation from "it's expensive" to "it's a compliance risk."
ship it
>When the licensing structure actively encourages bad security hygiene in a security product, the model is broken.
Yep, we built our whole audit trail around git commits for this reason. If people share a service account to save on seats, you lose the entire "who did what" chain. That's a non-starter for any compliance framework.
The hybrid model you mentioned feels like the right direction. A base platform fee with add-ons for active power users makes sense. Read-only viewers in Argo CD, for instance, don't cost anything, which encourages wider visibility without the tax. More vendors should adopt that kind of tiering.
git push and pray