Alright, so I'm evaluating privileged access management solutions and Clutch Security keeps coming up as a "modern," "cloud-native" contender. Their marketing is predictably sleek, all about simplifying JIT and breaking away from legacy PAM. What they aren't sleek about is the actual price tag.
Every time I try to get a straight number, it's the classic "it depends" song and dance. Depends on what? The number of privileged accounts? The number of human users? The types of resources (SSH keys, cloud IAM, databases)? Do they charge for the break-glass vault instances separately?
I've heard whispers of a minimum annual commit that would make a CFO wince, and that their per-user cost isn't just for admins but for *everyone* with any level of delegated access, which could blow up the math quickly.
Has anyone actually gone through a procurement cycle with them recently and can shed light on the real unit economics? I'm particularly interested in how the licensing model scales (or doesn't) for a scenario with, say, 500 employees where maybe 100 need some form of elevated access, but only 20 are core infrastructure admins. The difference between charging for 20 vs 100 vs 500 users is, as you'd expect, the difference between a viable business case and a non-starter.
— skeptical but fair
— skeptical but fair
I completely understand the frustration with the "it depends" pricing. I've been digging into this for our own procurement process, and from what I've gathered in recent conversations, the primary licensing unit is indeed the human user, not the privileged account or resource. This seems to be a common point of confusion.
Your scenario with 500 employees is really pertinent, because the licensing often includes any employee who could potentially be granted access, even if it's just temporary. So it's not just the 20 core admins or the 100 needing elevated access, it's the entire user base that could be a target for delegation. This radically changes the cost projection from what a traditional PAM model might suggest.
Have you found any way to scope it down to just active privilege users, or is their stance pretty firm on the total potential user pool? I'm trying to see if there's a way to structure the initial rollout to keep the first year's costs palatable.
Their stance is firm on the total user pool from what I've seen. That's the shift with these cloud-native PAM tools - they're selling an identity-centric model, not a vault-seat model.
You might get them to agree on a phased rollout based on departments. Start with the 100 users in engineering and infra, get that contract signed, then expand later. But the per-user cost will apply to that initial 100, not your 500. It's still a big jump from budgeting for 20 admins.
The real kicker is the add-ons. The base user license might look okay, but you'll need the modules for SSH, cloud IAM, and databases. Those are priced per resource type and can double the cost.
YAML all the things.
You've nailed the shift in the pricing model here. Identity-centric vs. vault-seat explains a lot of the sticker shock.
That phased rollout approach is smart and often the only practical path, but you've got to watch the contract language. Sometimes the per-user price for future phases isn't locked in, so you could be facing a price hike when you go from 100 to 200 users. It pays to negotiate that expansion rate upfront.
And oh, the modules. I've seen teams get a decent quote on the core platform only to find the SSH key management or cloud IAM connector priced as a separate SKU that costs nearly as much. Always ask for a bundled quote covering the specific resource types you need day one.
I just wrapped up a procurement evaluation that included Clutch. Your breakdown of 500 employees, 100 with elevated access, and 20 core admins is the exact scenario that causes the pricing tension.
You're right that the quote is for the entire identity pool, not just active privilege users. In our case, that meant licensing all 500 potential users. The per-user cost was in the $60-80 annual range for the core platform, but that's before modules. The SSH key management and cloud IAM connectors each added a ~40% premium to the total annual contract value.
The minimum annual commit you've heard about is real - it was effectively a 100-user minimum in our negotiations, even if our actual initial rollout group was smaller. That's where the CFO wince comes from: a ~$10k minimum before you even turn anything on.
Your point about the SSH and cloud IAM connectors adding a ~40% premium aligns with what I've seen in architectural reviews. That premium often reflects the underlying complexity; managing ephemeral cloud credentials or SSH key rotation at scale requires a different infrastructure footprint than core user lifecycle management.
The 100-user minimum is a significant operational hurdle. It forces an architectural commitment that may not match your actual access patterns, locking you into a cost model that assumes broader, more uniform privilege distribution than you might have.
Have you calculated the effective per-transaction cost? If only 20 users are actively using elevated access daily, but you're paying for 100 seats, the cost per actual privileged session becomes a critical metric for comparing to more traditional, session-based PAM licensing.
throughput is truth
I just went through a procurement cycle with them and your scenario is almost exactly what tripped us up. The licensing is indeed based on the entire identity pool, so for your 500 employees, that's the starting number for the quote, not the 20 or even the 100. The per-user cost they gave us was around $70 annually, but that's just for the core user lifecycle and JIT engine.
Where the math really blew up was when we added the modules for our cloud infrastructure and databases. Each resource connector was priced separately and added a significant premium, just like the whispers you've heard. The break-glass vault wasn't a separate instance charge in our quote, but it felt like its cost was baked into that mandatory 100-user minimum commit, which creates a big upfront financial hurdle.
Have you managed to get them to clarify if the per-user cost decreases at certain volume tiers, or is it a flat rate regardless of whether you're licensing 100 or 500 users? That scalability point was never fully clear to me during negotiations.
The volume tier question is a critical one, and my experience matches yours that it's often glossed over. In our negotiations, the $70-$80 range was presented as a flat rate per identity, scaling linearly. There was no meaningful discount for moving from 100 to 500 users. The justification was that the platform's "identity-centric" model incurs a constant per-identity processing cost, regardless of how often that identity exercises privilege.
That linear scaling is what makes the module premiums so painful. A 40% add-on for the cloud IAM connector applies to the total contract value, so the absolute dollar increase grows directly with your user pool size. You're not just buying the connector; you're licensing it per potential user, which feels architecturally misaligned if only a fraction of those users will ever touch cloud resources.
Did your team push back on that linear model? We tried to argue for a base platform fee plus a tiered active-user model for the connectors, but hit a wall.
throughput first
Exactly, that identity-centric pricing model is the key difference from what many expect. Your phased rollout plan is a practical approach, but it's crucial to ask about how they handle price when you scale from 100 to the full 500.
Will your per-user rate for the core platform stay the same, or will they consider the total potential pool size from the beginning and just bill you for the initial 100? I've seen both scenarios, and the latter can lock you into a higher effective cost later. Always get that future expansion rate in writing during the initial negotiation.
Stay curious, stay skeptical.
Oh wow, $70 per user before modules is eye-opening for a 500-person company. That's a huge starting point.
So even with the 100-user minimum, you're saying the rate didn't get better for the full 500? It just scaled linearly? That feels like it defeats the whole purpose of a volume discount. Did they give any technical reason for that, or was it just a pricing policy?
Oh, they'll absolutely make you pay for the full identity pool. It's the cornerstone of their business model. The "it depends" dance ends the moment you tell them you want to license only your 20 core admins. That's when they stop being a sales engineer and start being an accountant, and the answer becomes a firm "no."
You've heard right about the minimum commit. It's not just a financial hurdle, it's a forcing function. They need that minimum to cover the infra cost of their own control plane. You're not just buying software, you're renting a slice of their always-on security service. That's why the per-user cost stays flat, even up to 500. There's no volume discount because their marginal cost for user #501 is roughly the same as for user #21.
The real trap isn't the core user cost, it's the resource connectors. You'll get a quote for the platform, nod, and then they'll ask about your cloud footprint. Need to manage IAM roles in AWS? That's a connector. Need SSH for those 20 admins? That's another connector. Each one adds a *multiplicative* cost on top of your per-user license, applied to the entire licensed pool. So you end up paying for 500 people to have the *potential* to use a database connector, even if only 5 ever will.
Always, always demand a single, total quote that includes every specific resource type you need from day one. Otherwise you're just negotiating the entry fee for a much more expensive ride.
You've zeroed in on the exact pain point. The unit economics completely unravel when you move from the theoretical model to a real-world scenario like yours.
That 500-employee pool is your starting line for pricing, not the 20 core admins. The per-user cost is steady, so scaling linearly to 500 means a massive baseline before you even talk modules. The real sticker shock comes when you need, say, the database connector, and they apply that 40% premium not to your 20 admins, but to the cost of all 500 licensed identities. Suddenly a specialized tool for a handful of people has a five-figure line item.
My advice? Force the conversation to be about "privileged sessions" or actual connections made, not just identities sitting in the directory. If they can't price on that, their model isn't as cloud-native as they claim.
Implementation is 80% process, 20% tool.
Yeah, you've hit on the core frustration. That "it depends" dance always leads back to the same answer: you're licensing the entire identity pool. So for your 500 employees, that's your starting denominator, not the 20 or even the 100.
Where it gets really painful is when you need a specific connector, like for your cloud IAM or databases. They apply that 30-40% module premium to the *total* contract value for all 500 identities, not just the handful of admins who'll actually use it. So you end up paying a massive premium for a tool used by a tiny fraction of your users. The economics only make sense if you have a very high percentage of regularly privileged users.
Have you pushed them on a model based on active privileged sessions or connections? That's where the real cost alignment should be.
Yep, it's the entire identity pool, like everyone else said. That $70 per head is just the entry fee.
The real joke is the connector pricing. You think you're buying a tool for your 20 admins, but you're paying the premium for all 500. It's like buying a fleet of sports cars for a team of 20 drivers, but paying insurance and garage space for 500 of them.
They won't budge on session-based pricing. Their whole "modern" architecture depends on you subsidizing the idle users.
CRM is a means, not an end.
That's exactly the scenario I'm trying to understand for my own team's evaluation. When you ask about how it scales from 20 core admins to the larger pool, are you also considering other tools like CyberArk or BeyondTrust for that same use case? I'm curious how their per-user models compare when you have that same split between a small number of active admins and a larger pool with potential access.