Let's be honest, the moment a security company's pricing page is just a "Contact Sales" button and a bunch of vague tier names like "Team" and "Enterprise," you know you're in for a fun ride of endless demos, non-disclosure shrouded quotes, and spreadsheet gymnastics to figure out what this will actually cost. Banyan is playing this game masterfully. Their marketing talks a big game about zero trust and replacing your VPN, but I can't find a single concrete, publicly listed price per user, per device, or per gateway hour.
So I'm turning to the trenches. Has anyone actually gone through a POC or procurement with them recently and can shed some light on the real numbers? Not the list price they start with, but the actual deal you negotiated. I'm particularly interested in the breakdowns because their model seems to be a Frankenstein of several dimensions:
* Is it purely per-user? If so, is that "user" defined as an individual human identity, or does a service account count? This matters immensely for machine-to-machine access.
* Is there a separate cost for "devices" or endpoints with the TrustScore daemon? Or is that bundled?
* What about the "Gateway" or "Access Tier" component? Is that a flat fee, an hourly cost based on usage, or a provisioned capacity model? If it's hosted by them, I suspect it's buried in the per-user cost, but if it's self-hosted on our own infrastructure (e.g., in our AWS VPC), is there still a licensing fee on top?
* Are there hard limits on the number of private resources (servers, databases, internal apps) you can secure, or is that unlimited once you're paying for the users/access?
I've been down this road with other "zero trust" platforms where the initial quote seemed manageable, only to find out that "advanced policy features" or "compliance reporting" require the "Enterprise Plus" tier, which is 3x the cost. Or that their definition of a "seat" changes during the renewal.
A fragment of a Terraform config or a CloudFormation snippet they provided during a trial would be incredibly telling. Sometimes the resource properties or the parameters required for their controller hint at the underlying licensed components.
Without real numbers, we're all just comparing slick demos and vague promises. I'd rather compare concrete failure modes and dollar figures. Anyone willing to share their actual experience?
Your k8s cluster is 40% idle.
Yep, exactly why I avoid these setups. Had a call with them a few months back. It's all of the above, that's the trick. They quoted us a per-user license, then added a separate line item for "gateway compute hours," and there was a minimum device count for the desktop client. So you're negotiating three numbers at once. The user cost was around $10/month but that was before any haggling. We walked away.
I've been looking into them for a small project and hit the same wall. That "Contact Sales" button feels like a locked door. It makes me wonder, if their pricing is so flexible and negotiable, why can't they at least publish a starting anchor price? Even a simple "starting at X per user/month" would set expectations.
Thanks for posting this, I'm really curious to see what others have found out too.
Completely agree on the breakdown being essential, especially for the machine-to-machine case. We looked at them last year for securing service accounts in our data warehouse workflows, and that's where the model gets truly murky.
Our initial quote defined a "user" as any entity with a credential, human or machine. That meant every service account running an ETL job would count, which was a non-starter given our volume. We pushed back hard, and they offered a different SKU for "non-human identities" at a lower rate, but it was still an added dimension. It felt like we were being charged for the pipeline nodes themselves.
The gateway compute hours were the real variable cost, though. That's where you need to model your expected traffic patterns, almost like forecasting cloud infrastructure spend. Without published rates, you're negotiating in the dark.
Extract, transform, trust
Oh good point about the breakdown. I was just thinking about human users, but you're right about machine-to-machine. If every service account counts as a user, that would get crazy expensive for us too. Did anyone get them to clarify that in writing?
How do you even start to estimate the "gateway compute hours" without running a full scale PoC first? Feels like they want you locked in before you know the real cost.
You're spot on about needing the breakdown. The Frankenstein analogy is apt because it creates a vendor lock-in effect through forecasting complexity. From my last procurement cycle, the "user" definition was indeed our biggest sticking point. We managed to get written clarification that standard human users in an enterprise plan were one SKU, but any automated system, CI/CD runner, or service principal required a separate "machine identity" license at approximately 60% of the human user cost. This wasn't offered upfront, it only came after three rounds of technical clarification.
The gateway compute hours are modeled on your expected egress from their managed cloud, similar to how you'd estimate a cloud provider's load balancer or NAT gateway costs. They wouldn't give us committed use discounts until we committed to a 36-month term, which is where the real cost obfuscation happens. You can't accurately benchmark the per-hour rate without knowing your traffic profile, but they want a term commitment before you can gather that data. It's a classic catch-22 designed to prevent apples-to-apples comparisons with more transparent per-user pricing from competitors.
show me the SLA
Yeah, that "starting at X" anchor price is such a basic expectation. Even a high number gives you a floor to work from. It makes me think the secrecy isn't about flexibility, it's about keeping you from walking away before the first call.