Why Enterprise Customers Cost More Than Consumer Users

The slide was called "Identity Unit Economics" and it had one number on it: $0.31 per user per month.

It had been produced honestly: pull everything attributable to authentication out of the cloud bill across both product lines — the consumer app with four million monthly actives, and the B2B platform with two hundred enterprise tenants and six hundred thousand seats — divide by total users, put it on a slide. The CFO's follow-up was the reasonable one: so which users should we go get more of?

Nobody could answer it, because the number was an average across two populations whose cost structures have nothing in common, and averaging them had destroyed exactly the information the question needed.

Here is what the same quarter looked like disaggregated. The consumer product authenticated roughly 32 million times and cost about $41,000 a month, all-in, including the humans. That is about one cent per monthly active user, and about 90% of it was support contacts, not infrastructure.

The enterprise arm cost roughly $194,000 a month for 600,000 seats — thirty-one times more per seat. And within the enterprise arm the spread was worse than the gap between the two arms. A 41-seat regional insurer, closed the previous September, had consumed in nine months: a 214-row security questionnaire, a DPA negotiation with two engineering review cycles, a bespoke SAML connection against an ADFS instance owned by a subsidiary that had opinions about NameID formats, a certificate rotation that required three scheduled calls with their IdP administrator, an EU residency clause, and a "quick architecture call" that turned into four. Their contract was $2,900 a month. Their cost to serve was higher than that, and it was higher in the first month and every month after.

Meanwhile the 47,000-seat manufacturer — the largest logo, the one everyone was nervous about — cost less per seat than the consumer product did.

That is the whole article in one paragraph, and the arithmetic behind it has an uncomfortable ending for anybody whose pricing page has a per-seat number on it.

This is the closing piece of a series doing arithmetic on identity infrastructure. The Hidden Cost of Audit Logs established the method; session storage, password hashing, token introspection, SCIM and key rotation each priced one subsystem; What Does One Login Actually Cost You? assembled them per authentication. This one re-assembles the same line items along a different axis — per customer class — and finds the axis matters more than the total. It is the economics companion to Why Enterprise Identity Is Fundamentally Different From Consumer Authentication, which argued the two are different products with opposing objective functions. Here is what the difference costs, and it is not where the architecture argument suggests.

The assumptions, published so you can re-run it

Same constants as the rest of the series, so the numbers compose.

Two of those do more work than they look like. The $104/hour converts every meeting, questionnaire row and escalation into a comparable figure, and it is why most of this article's dollars are payroll. The 38-month contract life is what makes onboarding cost look small; halve it and small-tenant economics get twice as bad — which is exactly what happens in the segment where churn is highest.

The consumer baseline: variable, predictable, engineerable

Start with the cheap population, because its shape is the thing enterprise cost will be measured against.

Four million monthly actives, eight authentications each, 32 million logins a month. 70% still use a password.

$0.0103 per monthly active user. Infrastructure alone is $0.00012 — a hundredth of a cent, which is the number people quote when they say identity is basically free.

Two properties of this column matter more than its size.

It is continuous. Every line moves smoothly with traffic. Add 10% more users and you add roughly 10% more cost. Remove them and it goes away. The hashing pool genuinely idles at 3 a.m. Forecasting next year's consumer identity bill is a traffic model and a multiplication.

It is engineerable. The dominant line — 6,400 support contacts — is not fixed. Ship a better account-recovery flow and 30% of it disappears, permanently, across all four million users, from one piece of work: a $138,000/year return on a two-sprint project. Move 40% of the base to passkeys and the largest infrastructure line goes to zero. Consumer identity cost responds to engineering with high leverage, because one change touches the entire population.

Hold onto that word: leverage. It is what the enterprise column does not have.

The enterprise tenant: a fixed stack with a seat count attached

The mistake in the opening slide was not arithmetic. It was the model. It assumed

cost = per_user_cost × users

when the enterprise cost function is

cost = F + (v × seats) + (g × group_cardinality)

where F is a per-tenant fixed cost that exists whether the tenant has 10 seats or 10,000, and g is a term nobody has on their dashboard at all. Let me build all three.

F: what a tenant costs before anybody logs in

These are the costs that arrive with the contract, not with the users. One-time items are amortised over the 38-month median contract; everything else is a monthly share of a shared function divided by 200 tenants.

The federation rotation line deserves its derivation, because it is the clearest example of a cost that is per-tenant by construction. The Cost of Key Rotation describes an annual SAML signing-certificate rotation across 190 counterparty IdPs that consumed fourteen weeks of one engineer plus a slice of four account managers. Price that: 3.2 months of engineer ($53,400) plus roughly one FTE-quarter of account management ($40,000) is about $93,400 for one rotation cycle across 190 federations. $492 per federation per rotation — $41/month at annual cadence.

Note what happens if a framework mandates 90-day rotation. The signing-key rotation is a cron job that takes forty seconds. The federation rotation is $492 of coordination per counterparty, four times a year: $164/tenant/month, from a line item that appears in no budget under any name.

v: the per-seat variable cost, which is genuinely higher than consumer

Enterprise seats do cost more than consumer users to run — just not nearly enough to explain anything.

That table contains the most under-appreciated fact in enterprise identity economics, and it points the wrong way for my thesis, so: enterprise customers absorb their own tier-1 support. When an employee cannot log in, they call their own service desk, who fixes it in the customer's own IdP, and you never hear about it. In the consumer product that same event is a $6 contact, 6,400 times a month. Per seat, enterprise support is nearly free and consumer support is the entire bill.

So the "enterprise users are needier" story is false at the level of users. It is the tenant that is expensive, and the tenant's cost does not care how many users are behind it.

g: group cardinality, the multiplier that appears in every subsystem

This is the term that surprises people who have already accepted everything above, and it is the one place where a single customer can move your infrastructure bill without buying a single additional seat.

An enterprise identity arrives carrying group memberships, and they propagate into the session record, both tokens, every audit event that snapshots authorization context, every SCIM payload, and every projection. They are not a field; they are a fan-out factor applied to every representation of a user you hold.

Two things in that table are worth more than the dollars.

First, the memory effect is not linear, because storage engines have encoding thresholds. The Cost of Session Storage works through the Redis case in detail — a single field longer than 64 bytes converts a compact listpack into a real hashtable and multiplies the overhead on every other field in the record. The consequence observed there: one tenant was 14% of users and 61% of session memory. Group cardinality does not degrade gracefully; it steps.

Second, the 120-group row is where it stops being a cost and becomes an outage. Eight kilobytes of group DNs in a bearer token exceeds the 4 KB cookie limit, and once you move it to an Authorization header you meet the next wall: nginx's default large_client_header_buffers at 8 KB, and a 16 KB header cap on several managed load balancers. The failure is a 431 or a 400 from a proxy, for some users of one tenant — specifically the ones with the most group memberships, which is to say their administrators and their most senior people. It is untestable with synthetic users, unreproducible in staging, and it arrives on the day a customer completes an acquisition and merges two directories.

The fix is the same one 13.2 reaches: do not carry group state in the session or the token. Carry an identifier and resolve entitlements against projected state on the paths that need them. What that buys is not memory — it is removing your largest customer's org chart from your capacity model. Right now, for most platforms, a number that sets your session memory, your token size, your audit volume and your header-limit failure mode is chosen by an Active Directory administrator you have never met, at a company that will reorganise next quarter without telling you.

The shape

Put F, v and g together across tenant sizes. F is not perfectly constant — large tenants bring more federations, more SCIM targets, more SIEM destinations and a real TAM — but it grows far slower than seats do.

The strategic tenant's F is built the same way: four federations for four subsidiaries, thirty SCIM targets, three SIEM destinations, nine bespoke configuration points, a dedicated TAM at 0.4 FTE, a four-month procurement with three questionnaires amortised over a 48-month contract, and an EU partition. Seventeen times the micro-tenant's fixed cost — for 4,700 times the seats.

Which is the opposite of the intuition that produced the slide:

Cost per seat falls by 156× from the smallest tenant to the largest. Cost per tenant rises by 30× over the same range. Both are true, and per-seat pricing can only see the first one.

The portfolio arithmetic, which is the uncomfortable part

Now hold total seats constant at 600,000 and vary only how they are distributed across tenants. Same revenue under any per-seat price. Same users. Same logins.

Identical seat counts. Identical per-seat revenue. A 16.5× spread in cost to serve, driven entirely by a variable that appears on no pricing page: how many contracts the seats are divided into.

Portfolio D is not a strawman. It is what a successful product-led-growth company looks like three years after adding SSO to the Business tier: thousands of small tenants, each with a federation, a questionnaire, and an admin who wants a session-timeout setting. Every one of those deals was individually rational. The portfolio is structurally unprofitable, and the P&L will attribute it to "sales inefficiency."

Price it at a $6/seat/month list:

There is the number that should be on the internal wiki of every B2B company and is on almost none:

S_min = F / (p − v)

At F = $563, p = $6 and v = $0.075, the minimum viable enterprise tenant is 95 seats. Below it you are paying for the privilege of the logo. Above roughly 500 seats you are at software margins and the per-seat price is essentially arbitrary.

And note the character of the error. Per-seat pricing is not noisy about cost — it is biased, monotonically, in tenant size. It systematically overcharges the tenants that are cheapest to serve and undercharges the ones that are most expensive, and the error grows without bound in both directions. That has two consequences that show up years apart.

The near one: your small-tenant segment is subsidised by your large-tenant segment, and because it is subsidised it looks like it is working, so you invest in growing it.

The far one: a competitor who prices on the actual cost structure — a platform fee plus a small seat price — quotes your strategic account a number you cannot match, because you are funding six thousand 100-seat tenants out of that account's margin. You experience it as losing on price. It is an allocation problem that became a price problem.

Why enterprise cost does not respond to engineering the way consumer cost does

The distinction is not size. It is shape, and shape determines what engineering can do about it.

Those last two rows are the whole finding compressed. In the consumer product, users are the cost driver. In the enterprise product, users are almost free and tenants are the cost driver — and the per-seat price is a measurement of exactly the wrong quantity.

The engineerability gap is the part worth sitting with. A consumer optimisation has leverage: one change, four million beneficiaries. An enterprise fixed cost has none, because it is per relationship. You cannot cache a security questionnaire, batch a DPA negotiation, or put a CDN in front of an architecture call. A 214-row questionnaire costs fourteen engineer-hours no matter how fast your runtime is, and the eight hundredth costs the same as the first unless somebody deliberately changed the process — which is a hint, and I will come back to it.

Irreducible, or self-inflicted?

Every line in F gets treated as a cost of doing business. Roughly half of them are not. Sorting them is where the strategy is.

Look at what is in the self-inflicted column. It is not runtime. It is the absence of self-service for exactly the operations that generate support load.

That is not a coincidence. It is the predictable outcome of a sequencing decision every platform makes without noticing: onboarding is done by hand for the first ten customers, because a form is not worth building for ten — and it is still done by hand at customer four hundred, because by then "onboarding" is a team with a runbook and it works. The manual path never fails. It just never stops costing $104 an hour.

The investment implication, with numbers

So where should an enterprise identity team spend a quarter?

Take two candidate projects, both plausible, both the kind of thing that gets proposed.

Project A: make the runtime 20% cheaper. Caching improvements, a better claims-resolution path, a leaner session record. Real work, a full quarter for two engineers.

The saving is 20% of the variable cost across the whole enterprise arm: 0.20 × 600,000 × $0.075 = $9,000/month. It scales with seats.

Project B: make SSO connection setup, certificate rotation and audit-export configuration self-service. One form, one sandbox that decodes and diffs an assertion, one rotation page, one export status view with a gap alarm. Less engineering than Project A.

The saving:

Nearly twice Project A, for less work. But the magnitude is not the interesting part — the derivative is. Project A's saving grows with seats; Project B's grows with tenants. For almost every B2B company tenant count grows faster than seats per tenant, so the two diverge over time in Project B's favour, fastest in exactly the segment where the margin problem lives.

Project B also has a term the cost model cannot contain: it removes engineering latency from the sales cycle. A self-service SSO setup a customer's IT team completes in an afternoon converts a two-week scheduling dependency into zero. That lands in revenue, not cost, and is invisible to every FinOps exercise ever run.

Which gives the general rule this article exists to argue:

The highest-return engineering work in enterprise identity is almost never making the runtime faster. It is making an operation self-service — because runtime work divides v, and self-service work divides F, and F is what your economics are actually made of.

This inverts the instinct of most good infrastructure engineers, including mine. Runtime optimisation is measurable, satisfying, and technically interesting. Building an assertion-debugging sandbox for other people's ADFS instances is none of those things. It is also worth roughly twice as much and gets more valuable every quarter.

One architectural note, affiliation disclosed: I work on ClavionX, which gives each tenant its own OIDC issuer and signing keys. The reason that matters here is narrower than it sounds — it is a cost-structure argument, not a security one. When keys are per-tenant, "rotate ours" is an operation that can be offered to one customer without a cross-tenant blast radius, which is the precondition for making it self-service at all. A global signing key does not make rotation more dangerous so much as it makes rotation a centrally coordinated event, and centrally coordinated events are exactly the ones that stay in the F column forever. Isolation is usually argued on blast radius; it also determines which of your operations can ever leave your engineers' hands.

A framework for what an enterprise tenant should cost

Four measurements, none of which need new tooling, all of which are probably in a ticket system already.

1. Onboarding hours per new tenant. Measured, not estimated — pull the last twenty and add up the calendar, including the questionnaire, the calls, the connection work and the first two escalations. Most teams guess 6 hours and measure 30.
2. Tenants per support human. Headcount ÷ tenants, priced. A TAM covering 25 tenants is $500/tenant/month whether or not anyone calls.
3. Federation and connector maintenance FTE ÷ tenants. The people whose week goes to SCIM dialects, certificate calendars and IdP quirks.
4. Release hardening hours attributable to per-tenant configuration ÷ tenants. "Hardening" is discovery of your occupied configuration set: a per-tenant cost wearing a release-process costume.

Sum them into F. Compute S_min = F / (p − v). Then three things follow.

Price the shape you actually have. A platform fee plus a seat price is not rent extraction; it is a description of the cost function. A pricing page that is purely per-seat with volume tiers is approximating a curve with steps that go the wrong direction — the discount deepens exactly where the cost per seat was already falling.

Publish S_min internally. Not to block deals, but so that a below-threshold deal is a decision rather than an accident. There are excellent reasons to take one; there is no good reason not to know.

Re-run it for internal platforms. If you are an internal identity team charging divisions per seat, the same arithmetic says your chargeback model is inverted. A 12-person team with its own IdP connection and its own compliance regime costs you roughly what a 3,000-person division costs. Per-seat chargeback makes you look expensive to the divisions that are cheap to serve and free to the ones that are not.

When the number is bigger than the deal

It will be, several times a year. In rough order of preference:

flowchart TD
    A["Cost to serve > contract value"] --> B{"Is the cost in F<br/>and self-inflicted?"}
    B -->|Yes| C["Make it self-service.<br/>Fixes it for every tenant, forever."]
    B -->|No| D{"Will they pay for it<br/>as a named line item?"}
    D -->|Yes| E["Price the exception:<br/>one-time onboarding fee,<br/>residency SKU, premium support"]
    D -->|No| F{"Is there a stated<br/>strategic reason?"}
    F -->|Yes| G["Take it at a loss deliberately.<br/>Named sponsor, stated expiry,<br/>written down."]
    F -->|No| H["Decline with a number,<br/>not an apology."]

A few notes on the branches, because the phrasing matters more than the logic.

Option two is more available than people think. Enterprise buyers are accustomed to implementation fees; the systems-integration industry runs on them. What they will not accept is a surprise. A $12,000 onboarding fee disclosed in the first pricing conversation is normal; the same fee raised in week six is a trust event.

Option three needs an expiry and a name. "Strategic logo" is a real reason, and also the phrase that has funded every unprofitable customer in history. Write down who sponsored it, the expected return, and the date somebody checks. A loss-making deal with a review date is an investment; without one it becomes a permanent line item nobody can argue against, because the approver has moved on and the customer is now a reference.

Option four is not "we can't." The version that works: "Our SSO tier is built for organisations above about a hundred seats — below that, setup and ongoing configuration cost more than the subscription and we would serve you badly. Here is the self-service tier that fits you now, and exactly what changes at a hundred seats." True, checkable, and it does what a refusal cannot: it leaves a path back. Some of them take it eighteen months later at 400 seats.

The closing thought

Every article in this series found the same thing wearing different clothes. Session storage was a write-amplification bill, not a memory bill. Token format was a payroll question, not a CPU question. SCIM had no meaningful infrastructure cost at all. Key rotation was five orders of magnitude apart across operations a compliance document treats as one.

The pattern underneath all of them: the infrastructure cost of identity is measurable, small, and the part that matters least. The real cost is human, fixed, and lands per relationship rather than per request.

Everywhere else in the series that was an interesting observation about where to point your optimisation effort. Here it stops being an observation and becomes a pricing error, because the industry has standardised on a denominator — the seat — that measures the cheap term and is blind to the expensive one. It is not slightly wrong. It is wrong by two orders of magnitude at the bottom of the range, it is wrong monotonically, and the error is largest exactly where most companies are trying hardest to grow.

You cannot optimise your way out of a security questionnaire. But you can answer it once and reuse the answer, and you can build the form that means nobody has to schedule a call to upload a certificate. That is unglamorous work that no conference talk has ever been given about, and in enterprise identity it is worth more than your entire compute bill.

The number you want is not cost per user. It is cost per tenant. Nobody's pricing page has that column, and every P&L is shaped by it.