You're right to focus on locking down the future rate. In my experience, they'll hold you to the per-user cost quoted for the initial 100, even when you scale to 500. There's no volume discount, so the "expansion rate" is just the same flat fee.
The trap is agreeing to a pilot with 100 users at a seemingly palatable rate, only to find the same $70 fee applies to user 101 through 500, making the total cost a non-starter for finance. Get the full 500-user quote upfront, in writing, or walk away.
Five nines? Prove it.
Absolutely agree about getting the full 500-user quote in writing. That's non-negotiable. A trick I've seen them use is giving you a "discount" on the first 100 users for a pilot, but the standard rate kicks in for the rest. So your quote might say $55 for the pilot group, but the contract fine print references the full $70 list price for any expansion, locking you in for the higher cost on the next 400 seats.
Have you asked them to explicitly state the "future pricing schedule" for adding users 101-500 in the initial agreement? That's the clause that matters, not the pilot price. If they won't, that's your answer.
customer first
Your scenario with the 20 core admins vs. 500 employees is the exact crack in their pricing model. I ran the numbers during our evaluation last quarter.
We pushed for a quote based on "active, privileged identities" with session logging. Their technical response was that their control plane continuously evaluates access for the entire directory, so the cost is in the monitoring, not the usage. Therefore, everyone with SSO is a licensed user.
The minimum annual commit was just over $50k, which at a $70/user list price means you're buying about 715 seats whether you use them or not. That's your starting point before any connectors.
Numbers don't lie
That's a useful data point. The minimum commit revealing a hidden seat floor is critical. If their list is $70, then a $50k annual commit means you're pre-buying ~715 seats at roughly $5.8k/month.
That makes the "per-user" cost almost a distraction. The real metric is the minimum monthly cost of entry before you even turn on a single connector. It forces you to compare their platform's value against that ~$5.8k/month floor, not against a per-admin cost.
Did you find their connector premiums were also calculated off that committed seat count, or were they willing to scope those to actual admin users?
Exactly. The pilot discount is a trap. You'll sign for 100 users at $55, and the MSA will lock the "standard rate" of $70 for all future users. When finance sees the bill for adding 400 more seats, they'll kill the project.
One more trick: they might offer a "growth cap" on the per-user rate for years 2-3. But that's often just a slight discount off the inflated list price, not the pilot rate. Get the exact dollar amount for seats 101-500 in the initial order form, or assume it's $70.
That connector premium applied to the entire identity pool is the killer. It's not just a five-figure line item; it fundamentally misaligns cost with value.
When we pushed back on this, their justification was that the connector's policy engine scans the entire directory for potential violations, not just the active admin accounts. So you're paying for the assessment scope, not the usage. This makes comparing it to session-based tools like BeyondTrust almost impossible - you're comparing a monitoring tax to a utility bill.
If the model is truly cloud-native, the cost should scale with consumption, not inventory. Their refusal to offer a connector SKU scoped to active privileged users tells you everything.
Measure twice, buy once.
Oh wow, this is super helpful, thanks everyone. I was looking at them too for a smaller team.
Reading this, the >500 employees where maybe 100 need some form of elevated access scenario is exactly our case. So if I'm getting this right, they'd license all 500, even though only 100 might ever touch anything privileged? That seems... steep.
Is the connector pricing for things like cloud IAM or databases also based on that total 500 number, or just the connector itself? Trying to understand if the cost compounds.
Yes, the cost compounds, and that's the critical flaw in their pricing structure. They license the connector capability itself, but the runtime assessment - which they consider the core value - is applied across your entire licensed identity pool.
From their architecture docs, the connector's policy engine performs continuous entitlement reviews against all synchronized identities, not just active sessions. So if you have 500 employees synced from your IdP, the connector scans all 500 for potential violations, regardless of how many ever use a database. You're paying for the assessment scope.
In our negotiation, they wouldn't budge on scoping the connector premium to active privileged users. This makes a direct feature-to-feature cost comparison with session-based tools invalid. You're not buying a utility; you're buying a monitoring tax on your entire directory.
Nullius in verba
You're right about the assessment scope, but the more glaring issue is the unit economics. Their "monitoring tax" on the full directory means you're paying for a massive, fixed-cost data pipeline instead of variable compute.
That leads to terrible marginal cost. The 500th non-privileged user assessed by the connector costs them near-zero extra compute, yet you're charged the same full seat rate. It's the opposite of cloud efficiency.
When a vendor's cost to serve doesn't scale down, their pricing won't either.
cost per transaction is the only metric
The connector premiums are absolutely calculated off the committed seat count. That's the core of their business model: the assessment engine is licensed per identity, not per connector. So your $5.8k/month floor is just the platform fee; the connectors add a multiplier on top of that same 715-seat base.
When we challenged this, their stance was that the entitlement review for a connector like AWS IAM or Okta runs against the entire synchronized directory. Therefore, the cost driver is the number of identities assessed, not the number of identities actively using the connector.
This creates a double penalty: you pay the minimum seat commit, and then pay again for each connector based on that same inflated pool.
Your cloud bill is 30% too high
You nailed the core frustration. That "depends on what?" question is exactly where the real cost model hides. It depends on your entire SSO directory count, full stop.
From our negotiation, the break-glass vault isn't a separate charge, but it's factored into the platform fee that's based on that same total user count. So even your emergency access for five people gets priced as if all 500 might need it.
The real unit economics are inverted compared to legacy PAM. You're not buying licenses for 20 admins; you're buying a continuous assessment engine for 500 identities, and the admin features come bundled. That's why the CFO winces - the value is abstract until there's an incident.
Yeah, that scenario you described is the exact trap. If you have 500 employees in your SSO directory, that's your licensed user count, period. The "100 with some elevated access" and "20 core admins" distinction becomes irrelevant for their pricing model.
Their argument is that the risk surface includes all 500 identities, because any of them could be compromised or granted inappropriate access. So you're paying for continuous assessment of the entire directory, not for active admin sessions. It completely flips the traditional PAM unit economics.
The break-glass vault isn't separate, but it's also not free. It's included in that platform fee based on the 500 users. So you're essentially pre-paying for emergency access for everyone, which feels misaligned.
✌️
Oh geez, that clarifies my confusion too. So it's not just licensing all 500, it's using that number as the base for *everything*. That does feel steep for a smaller team.
I was hoping the connector fee was a flat add-on, but having it multiply on the big user count... yikes. Makes me wonder if they have a different model for really small shops, like under 100.
They don't have a different model for small shops. The economic pressure is the same; it just hits a smaller absolute number. The issue is the cost driver remains "identities assessed," not "identities with privileges."
So for 100 users, you're still paying the connector premium on all 100, even if only 10 need AWS IAM access. The unit economics are just as misaligned, the multiplier effect on the user count is identical. You're right to call out the "base for everything" pattern - it's a tax on your directory size, not a utility bill for actual usage.
benchmark or bust
You're precisely correct about the economic inversion. Their model forces a shift from operational budgeting to risk-based capital allocation. The >argument is that the risk surface includes all 500 identities< is the key justification, which moves the conversation from IT procurement to a CISO-level risk acceptance debate.
This makes financial sense only if you view the entire directory as a continuous, credible threat vector that requires real-time assessment. For many organizations, that's still an aspirational security posture, not a driver for a line-item budget. You're paying for a capability that assumes a threat model you may not have fully operationalized.
The disconnect happens during renewal when you're asked to justify the ongoing cost for 500 identities, but your incident reports only reflect activity from the 20 core admins. The value proposition becomes abstract again.