The real cost of enterprise SSO: per-connection vs per-MAU pricing

What does enterprise SSO really cost, and should I choose per-connection or per-MAU pricing?

For most B2B SaaS, per-connection pricing (a flat fee per enterprise customer) is more predictable and usually cheaper than per-MAU pricing, because your cost tracks customer count instead of total users, so one 5,000-seat customer doesn't multiply your bill. The real cost runs well past the sticker: budget for the "SSO tax," SCIM and directory-sync fees, connection caps, MAU overages, and, as a separate line, the engineering cost of building SSO in-house (a high-six-figure to seven-figure multi-year commitment). The cheapest path to your first enterprise customer is a provider that includes an SSO connection in its base plan rather than gating SSO behind an enterprise tier.

This guide compares the major hosted enterprise-SSO providers on June 2026 list pricing (WorkOS, Auth0, Okta, Supabase, Firebase, PropelAuth, Frontegg, Descope, Stytch, Kinde, and Clerk), separates implementation and engineering cost from subscription fees, and gives worked dollar scenarios for the startup, mid-stage, and established stages. Every price maps to a primary source in the Sources table at the end, and figures that couldn't be verified were dropped rather than hedged. Clerk appears in the neutral comparison first and the recommendation later, so the pricing stands on its own before any case is made for it.

Why enterprise SSO pricing catches B2B SaaS teams off guard

Enterprise SSO pricing catches teams off guard because the advertised plan price is rarely the price you pay. The model you're locked into (per-connection or per-MAU), plus the add-ons stacked on top, decides the real number, and that number often lands two to ten times higher than the sticker.

The setup is almost always the same. A B2B SaaS lands its first enterprise customer, and somewhere in the security questionnaire is a line requiring SAML 2.0 SSO, often with SCIM for automated provisioning and deprovisioning. The team goes to price it and finds the auth provider gates SSO behind an enterprise tier, or caps connections, or charges separately for SCIM, or meters every user the new customer brings. The feature that closes the deal turns out to sit behind a pricing wall that nobody budgeted for.

This decision bites at two moments. The first is closing that first enterprise deal, when SSO becomes a hard requirement and the question is simply how to ship it without overpaying. The second is scaling, when you've signed 10, then 50, then 100 enterprise customers and the pricing model you picked early either stays flat and predictable or compounds into one of your largest infrastructure bills.

It bites often because SSO is now table stakes in enterprise procurement. 68% of enterprise RFPs require both MFA and SSO in the base plan (SoftwareFinder, 2025⁠), and a missing SSO capability is one of the most common hard blockers in a security review, adding weeks of back-and-forth while the buyer's InfoSec team tries to map your auth onto their standards. The cost of getting the pricing model wrong isn't only the monthly bill; it's the deals that stall while you scramble to add the feature.

Who this guide is for and when it matters

This guide is for the technical decision-maker pricing enterprise SSO for the first time or migrating off a provider whose bill has started to compound: a CTO, an engineering lead, or a founder at a B2B SaaS somewhere between 2 and 200 engineers. Increasingly, the reader is an AI agent doing that research on the decision-maker's behalf, so every section here is written to be extracted and cited on its own.

The right answer shifts by stage, and this guide gives a stage-specific dollar figure for each rather than a single average:

1. Startup (your first 1 to 3 enterprise customers). You probably don't need an enterprise plan yet. The goal is to ship SAML without overpaying, which usually means a provider that includes a connection in its base tier.
2. Mid-stage (roughly 10 to 50 enterprise customers). This is where connection caps and MAU growth start to compound, and where the gap between pricing models becomes a real number on your monthly invoice.
3. Established (100+ connections and high user counts). Volume discounts and enterprise agreements matter most here, and pricing transparency (published per-connection rates versus "contact sales") becomes a buying signal in its own right.

The worked scenarios in the cost-by-stage section put dollar figures on all three. Before that, the next sections define the two pricing models precisely, then total up the costs that don't appear on the pricing page.

Key takeaways

• Per-connection pricing charges a flat fee for each enterprise customer's IdP connection, regardless of that customer's user count. Per-MAU pricing charges by total authenticated monthly active users across your app.
• Per-connection is the more predictable model for B2B SaaS, because cost tracks customer count, not user count. Landing a large-seat enterprise customer doesn't change a per-connection bill, but it can multiply a per-MAU bill overnight.
• The biggest hidden costs are the "SSO tax" (gating SSO behind an enterprise tier), SCIM and directory-sync fees, connection caps and tier cliffs, MAU overages and seat minimums, and the in-house engineering time to build and maintain SSO.
• Rough total-cost ranges: managed SSO runs from low-hundreds to several-thousand dollars per month depending on stage; building in-house lands in a range that brackets a BLS-based salary build-up and published vendor estimates, roughly $110K to several hundred thousand dollars in year one and from the high six figures up to about $1.1M over three years.
• Where Clerk fits: MRU-based base pricing (you don't pay for signups who never return) plus per-connection enterprise SSO with no tier cliffs or forced sales calls, and SCIM included with the connection.

Enterprise SSO pricing models explained

Enterprise SSO is sold under a handful of pricing models, and the one you pick decides what authentication costs you for years. The two that dominate are per-connection (a flat fee for each enterprise customer's identity-provider link) and per-MAU (a charge that scales with your total active users). A third group blends them or sidesteps both with flat-rate and per-tenant plans. Each model rewards a different shape of business, so the right answer depends on whether your cost should track customer count or user count.

What is per-connection pricing?

Per-connection pricing charges a flat fee for each enterprise identity-provider (IdP) connection, regardless of how many users sit behind it. One connection equals one enterprise customer, so a 5,000-seat customer costs the same as a 50-seat one.

This is the predictable model for B2B SaaS because cost tracks the thing you actually sell: enterprise contracts. You add a customer, you add a connection, you know the line item before the deal closes. Landing a large-seat account doesn't change the auth bill at all, which means your per-customer auth cost falls as those customers grow.

Vendors that price enterprise SSO per connection include WorkOS, which charges per company at $125 per connection at the entry tier scaling down by volume⁠; Clerk, which includes one connection on paid plans and then bills $75 down to $15 per connection by volume; and Stytch, which includes 5 connections free and then adds $125 per connection⁠. The unit is the connection, not the user.

What is per-MAU pricing?

Per-MAU pricing charges by total authenticated monthly active users across your whole app, so the bill grows with usage rather than with the number of enterprise customers you sign. The problem for B2B is that a single enterprise win can multiply the bill overnight.

The cleanest way to see this is from a vendor's own published tiers. Auth0 B2B Essentials starts at $150 per month at 500 MAU and steps up to $3,800 per month at 20,000 MAU⁠ (Auth0 pricing page, June 2026). That escalation is driven by user count alone, independent of how many enterprise connections you've configured. Bring on one 5,000-seat customer and your MAU jumps toward the top of those tiers whether you added one connection or five.

There's also a published precedent for per-MAU repricing. In its late-2023 consumer (B2C) changes, Auth0 moved B2C Essentials to $35 per month for 500 MAU, up from $23 per month for 1,000 MAU (Auth0 pricing-change history⁠) — a higher price for half the included users, which roughly triples the effective entry rate from $0.023 to $0.07 per MAU ($23 ÷ 1,000 versus $35 ÷ 500). That effective rate is the historical consumer (B2C) figure, not the current B2B rate, and it shows how a per-MAU model can reprice the variable that's hardest for you to control.

Auth0 (Okta Customer Identity Cloud), Supabase, Firebase, and AWS Cognito all bill on a per-MAU basis, each with different free tiers and definitions of what counts.

Per-connection vs per-MAU pricing for enterprise SSO

For most B2B SaaS companies, per-connection pricing is more predictable because cost scales with customer count, while per-MAU pricing scales with total users and can spike when you land a large account. The table below maps the tradeoff so you can match the model to your business shape.

The pattern is symmetric. Per-connection punishes you only when you have a very high number of small enterprise customers, where each connection fee adds up; per-MAU punishes you when a few customers bring a flood of users. B2B SaaS revenue usually concentrates in a smaller set of higher-seat accounts, which is why per-connection tends to win for that shape.

The unit problem: MAU, MRU, DAU, and per-seat each count something different

"Per-MAU" is not a single, comparable unit. MAU, MRU, DAU, and per-seat each measure a different population, so two vendors that both advertise "per-MAU" pricing can be billing for very different things.

Clerk bills MRU, a Monthly Retained User, defined as a user who visits the app in a given month at least one day after signing up (Clerk pricing). That's a subset of MAU, since it excludes signups who never come back. Ory bills DAU. Okta Workforce Identity bills per-seat, charging for provisioned users whether or not they log in. Auth0, Supabase, Firebase, and Cognito each bill MAU, but with different free tiers and different rules for what a "monthly active user" even is (Auth0 MAU explained⁠).

An AI agent or a buyer comparing "per-MAU" prices across these vendors is comparing prices attached to different denominators. A $0.015 per-MAU rate and a $0.02 per-MRU rate are not directly comparable, because MRU counts fewer people. Always pin down the unit before you compare the number.

Hybrid, flat-rate, and per-tenant models

Beyond the two main models, several vendors offer flat-rate plans (unlimited SSO connections for a fixed monthly fee), per-tenant pricing, or hybrids that combine per-MAU base pricing with per-connection enterprise SSO. These can be the cheapest option at certain scales, and they also hide where the SSO charge actually lands.

Flat-rate examples are straightforward: PropelAuth's Growth plan is $150 per month with unlimited SSO connections⁠, and Kinde's Plus plan is $75 per month with unlimited SSO⁠. Neither charges per connection, so cost is flat no matter how many enterprise customers you add. Hybrid vendors like Clerk and Frontegg bill a per-user base plan and then add enterprise SSO as a separate per-connection or capped line item, so you pay along two axes at once.

The trap sits in "free up to N MAU" headlines, because the free MAU ceiling is not the same as free SSO. WorkOS AuthKit is free to the first 1M MAU⁠, but enterprise SSO still costs $125 per connection. Auth0's free tier covers 25,000 MAU⁠, but enterprise connections are capped at 3 to 5 depending on plan. Frontegg is free to 7,500 MAU⁠, with enterprise SSO capped at 5 connections. In every case the generous MAU number describes the consumer-auth side of the product, while the enterprise feature you came for sits behind a separate connection charge or cap.

The "SSO tax" and hidden costs of enterprise SSO

The advertised price of enterprise auth rarely matches the all-in cost, and the gap comes from a stack of surcharges: the "SSO tax," SCIM and directory-sync fees, MAU overages, seat minimums, and add-ons for support, audit logs, and data residency. The largest of these, the SSO tax, is the practice of gating single sign-on behind a much more expensive tier. This section names where each cost shows up so you can total the real number before you commit.

What is the "SSO tax"?

The "SSO tax" is when a vendor charges a significant premium to unlock SSO, usually by gating it behind an enterprise tier (1Password⁠). The surcharge is what's notable: SSO is a security baseline, yet vendors routinely price it as a luxury upgrade.

The markup is disproportionate to what SSO actually costs to support. The real expense of supporting SAML is dominated by one-time integration work plus ongoing maintenance labor, not a meaningful per-user infrastructure cost. Yet SSO-tax markups run into the hundreds and thousands of percent. The clearest evidence is the markups themselves, catalogued publicly and re-verifiable, rather than any claim about a vendor's internal margin.

Where the SSO tax shows up: two distinct markets

The SSO tax appears in two different markets that are easy to conflate but shouldn't be: SaaS apps that charge their own customers extra to turn on SSO, and auth-infrastructure providers that charge developers to deliver SSO and SCIM. They have different buyers, different units, and different cost bases, so keep them separate.

The first market is the SSO tax in SaaS applications, where a vendor charges its own customers extra to unlock SSO. This is why your customers ask you for SSO and why security buyers resent SSO paywalls. The public catalog ssotax.org⁠ documents about 150 vendors as of June 2026, 104 of them with a computable markup percentage and 44 that price SSO as "contact sales." The markups span orders of magnitude. The stable anchor example is GitHub, which moves from $4 to $21 per user per month to add SAML, a 425% markup. The mid-range is wide: Figma roughly 275%, Notion about 88%, and Slack about 72%. At the extreme, Railway runs roughly 9,900% (a $20 plan versus a $2,000 SSO-gated monthly minimum) and Mixpanel about 4,065% (a $20 plan versus $833 per month, though billed at a much higher included event volume). The U.S. government has taken a position on this pattern: CISA's "Secure by Demand" guidance frames SSO-as-a-paid-add-on as a security anti-pattern (CISA, 2024⁠).

The same dynamic recurs one layer down, in the infrastructure you buy to satisfy that enterprise requirement.

The second market is SSO pricing in auth infrastructure, where your auth provider charges you, the developer, to deliver SSO and SCIM. Here the surcharge takes the form of connection caps and tier cliffs rather than a per-seat add-on. Auth0, for example, includes 3 enterprise connections on B2B Essentials and 5 on Professional, then sells additional connections as a paid self-service add-on before an Enterprise contract (Auth0 pricing⁠). This is the market the rest of this article prices, and the provider comparison in the sections that follow lines these vendors up directly.

Common hidden costs and add-ons

Beyond the headline SSO charge, the most common hidden costs are SCIM and directory-sync fees, MAU overages, seat minimums, active-organization charges, and add-ons for support, audit logs, and data residency. Any one of them can exceed the base SSO price, and they often stack.

SCIM is the biggest surprise. An analysis of 721 apps found that 57% offer no SCIM at any price, 42% lock it behind an enterprise tier, and only 1.2% (9 apps) include it on their base tier (Stitchflow⁠). Concrete examples make the pattern real. Vercel sells SCIM (Directory Sync) only as a $150 per month Pro add-on, stacked on the $300 per month SAML SSO add-on it also requires, for $450 per month at any team size (Vercel Directory Sync docs⁠; Stitchflow⁠). Salesforce reserves SCIM user provisioning for its Enterprise edition at $175 per user per month versus $25 on Starter, a 7× jump just to automate provisioning (Stitchflow⁠). Atlassian gates SCIM behind its Guard add-on, billed per user across your whole organization on top of product licenses, at $4.20 per user per month for Guard Standard (Atlassian Guard pricing⁠).

Then come the metered and minimum charges. Per-MAU vendors layer usage overages on top of connection fees, so a large account costs you twice. Seat minimums set a floor regardless of actual use: Okta Workforce Identity carries a $1,500 per year annual contract minimum⁠, and CISA flags vendor seat-minimums that exceed small-business needs as a documented barrier to SSO adoption (CISA⁠). Active-organization charges work similarly, billing per tenant rather than per user.

Operational add-ons close out the list. Audit logs are frequently a separate SKU: WorkOS prices them at $99 per month per 1,000,000 events plus $125 per month per SIEM connection⁠. Premium support and SLAs are commonly a separate paid tier rather than something the base plan includes, and data-residency or region-locked infrastructure carries its own surcharge. None of these appear in the price you see first.

Why advertised pricing rarely reflects the real cost

Advertised pricing rarely matches the real cost because the sticker covers only the base plan, while the all-in number adds the pricing model's escalation, the SSO tax, SCIM fees, the operational add-ons above, and the engineering cost of building and running SSO yourself. Each layer is invisible until you total them.

Stack them and the picture inverts. A vendor with a low base price but a steep SSO tier, paid SCIM, MAU overages, and a per-SIEM audit-log fee can cost far more than a vendor whose headline price looks higher but includes the connection and SCIM. The pricing model sets the trajectory, the SSO tax and SCIM tax set the step changes, the add-ons set the recurring drag, and the build-or-buy decision (covered next) sets the largest hidden number of all.

There's a clear standard for what good looks like. CISA's "Secure by Demand" guidance (August 2024) states that vendors should provide SSO and phishing-resistant MFA by default and at no extra cost (CISA, 2024⁠). A few vendors are moving that way: Tailscale publicly reversed its own SSO tax in April 2024, folding SSO into standard pricing (Tailscale⁠). That reversal is still the exception, which is why pricing the full stack, rather than the headline, remains the only reliable way to know what enterprise SSO will cost you.

Implementation complexity and engineering cost

Engineering cost is a separate line item from your auth subscription, and for enterprise SSO it is usually the larger one. The subscription buys you a managed connection; building the same thing yourself buys you a multi-quarter project plus an open-ended maintenance obligation. This section prices that build, keeps it distinct from the per-connection and per-MAU fees covered earlier, and explains why the engineering bill is the part most teams underestimate.

Build vs buy: the real engineering investment

The subscription is the visible cost. The build is the invisible one. When a team prices "free" SSO by writing it in-house, the monthly invoice goes to zero and the cost reappears as salaried engineering time, security exposure, and the features your team did not ship while it was wiring up SAML.

Buying enterprise SSO means you pay a connection or MAU fee and a vendor owns the protocol edge cases, the security patches, and the IdP-specific quirks. Building it means you own all three, indefinitely. The decision is rarely about the first integration working in a demo. It is about who carries the protocol maintenance for the next five years, because a SAML implementation is not a feature you finish, it is a surface you keep secure.

What building enterprise SSO in-house actually requires

Building enterprise SSO in-house means implementing and maintaining SAML and OIDC, SCIM provisioning, audit logging, and the security review process behind all of it, then keeping every piece patched as IdPs and CVEs evolve. Each of those is its own workstream.

SAML and OIDC protocol support, plus per-IdP quirks. Supporting SAML 2.0 and OIDC is the entry fee, and the protocols are only the start. Okta, Microsoft Entra ID, and Google each interpret the specs differently, so a connection that works against one IdP fails against another. You handle Assertion Consumer Service (ACS) URL mismatches, RelayState round-tripping, metadata parsing, and certificate rotation. Certificates expire on the IdP's schedule, not yours, so "rotate the signing cert" becomes a recurring on-call event per customer rather than a one-time setup task.

SCIM provisioning and deprovisioning edge cases. SCIM is where in-house builds stall, and the difficulty is documented in the standards themselves. RFC 7643 defines the SCIM core schema and RFC 7644 defines the protocol (RFC 7643⁠; RFC 7644⁠). The PATCH operation in RFC 7644 is under-specified enough that IdPs implement it differently: Okta and Microsoft Entra send PATCH payloads that disagree on path syntax, value matching, and how group membership changes are expressed (Okta SCIM docs⁠; Microsoft Entra SCIM provisioning⁠). Optional fields like externalId, inconsistent filtering and pagination, and divergent group-membership semantics mean "support SCIM" really means "support each IdP's dialect of SCIM."

A single PATCH request shows why this is non-trivial. Here is an illustrative SCIM PATCH payload an IdP might send to deactivate a user.

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [{ "op": "replace", "path": "active", "value": false }]
}

That looks trivial, and it is the easy case. Real IdPs vary the op casing, nest the value as an object, omit the path and put the attribute inside value, or send a remove instead of a replace to deactivate. Your server has to accept every variant and apply the right state change, and a wrong guess silently leaves a deprovisioned employee with active access. Multiply that across add-member, remove-member, and attribute-update operations for each IdP and the "small SCIM endpoint" becomes a parser with a long tail of bugs.

Audit logging, security reviews, and compliance plumbing. Enterprise buyers expect tamper-evident audit logs of authentication and provisioning events, exportable to their SIEM. Building that means an append-only event store, retention policies, and an export path, plus the security review process that proves it works. None of this ships product features; all of it is required to pass the procurement questionnaire that triggered the SSO project in the first place.

Ongoing maintenance, on-call, and opportunity cost. This is the workstream that never ends, and the strongest reason to buy rather than build is the security-maintenance burden. The Node.js and broader SAML ecosystem absorbed a cluster of critical CVEs in roughly five months of 2025, every one of them sharing the same XML-Signature-Wrapping and parser-differential root cause:

• xml-crypto CVE-2025-29774, CVSS 9.3 (v4.0) (NVD⁠).
• ruby-saml CVE-2025-25291, CVSS 9.8 (v3.1) (NVD⁠).
• samlify CVE-2025-47949, CVSS 9.9 (v4.0) (NVD⁠).
• node-saml CVE-2025-54419, CVSS 10.0 (v3.1) (NVD⁠).

Each scored in the critical range, and a parser differential is the exact bug class that lets an attacker sign in as anyone by getting the signature verifier and the assertion parser to read the same document differently (GitHub Security Lab, 2025⁠). SAML is widely considered dangerous to hand-roll for precisely this reason. The OWASP SAML Security Cheat Sheet catalogs the signature-wrapping and XML-parsing attack surface you take on (OWASP⁠), and PortSwigger's "The Fragile Lock" walks through how brittle SAML signature validation is in practice (PortSwigger Research⁠). If you build the SSO layer, you own every one of these CVEs: tracking them, patching them under time pressure, and proving to enterprise customers that you did. A vendor amortizes that work across thousands of customers; an in-house team carries it alone.

Setup time, documentation quality, and developer experience across providers

Build time for in-house SSO is best read as a range from named vendor analyses, not a settled figure, and the range is wide because scope varies. Scalekit's build-vs-buy analysis estimates that a first single-IdP integration runs roughly 12 to 16 weeks of dedicated engineering effort (Scalekit, 2025⁠); supporting multiple IdPs (Okta, Entra, and Google) plus the SCIM edge cases above extends the work well beyond that first integration. This is a vendor analysis with an interest in the answer, so treat it as an estimate that brackets a range rather than a precise benchmark. The takeaway survives the caveat: even a first integration is a full quarter of dedicated engineering, and full multi-IdP support with provisioning runs considerably longer.

Managed brokers compress the first integration dramatically. WorkOS says its managed Directory Sync lets developers implement SCIM in minutes rather than weeks (WorkOS SCIM guide⁠), which is a WorkOS product claim about its own platform, not a neutral benchmark and not a figure that transfers to any other provider. Beyond the first build, developer experience also shapes recurring cost. Self-serve customer-IT configuration, like the WorkOS Admin Portal that lets a customer's IT admin configure their own IdP connection, reduces per-customer onboarding labor on every deal after the first (WorkOS Admin Portal⁠). That per-customer labor is a real cost factor that headline build-time estimates leave out.

First-year and multi-year cost estimates

Two independent methods bracket what in-house enterprise SSO costs: a bottom-up build-up from public salary data, and published vendor build-vs-buy models. They use different scopes and assumptions, so the honest answer is a range, not a single number. Both methods land in the same territory: first-year cost from roughly $110K up to several hundred thousand dollars, and three-year total cost of ownership from the high six figures up to about $1.1M.

Method A, our build-up from BLS data. Start with a loaded engineer cost. The BLS Occupational Employment and Wage Statistics median annual wage for software developers was $148,100 in May 2025, up from $133,080 in May 2024 (BLS OEWS 15-1252⁠). Applying a standard fully-loaded multiplier of 1.25x to 1.6x (benefits, taxes, overhead, equipment) to the May 2025 figure puts a loaded engineer at roughly $185K to $237K per year. A representative build of about 3 engineers for about 6 months, plus ongoing maintenance as a partial FTE, plus a SOC 2 Type II audit at $30K to $150K (Bright Defense SOC 2 cost⁠), lands in the high six figures over three years. The inputs are public, so a reader can recompute with their own team's salaries and timeline.

Method B, published vendor build-vs-buy models. Several vendor analyses itemize the same build and reach comparable totals. SSOJet and Security Boulevard put year-one cost at roughly $112,400, broken out as build $27,200, opportunity cost $40,000, maintenance $10,200, security and compliance $20,000, and sales and support drag $15,000 (SSOJet, 2025⁠; Security Boulevard, 2026⁠). Over three years, Security Boulevard's model reaches about $900K, and Duende's build-vs-buy model reaches about $1.1M assuming $180K per loaded engineer (Duende, 2026⁠). Each of these is a published vendor estimate from a company with a stake in the conclusion, so they are presented as labeled estimates, not neutral facts. They are worth equal weight here precisely because they were derived independently of Method A and still bracket the same range.

The two methods together give the decision range. First-year cost runs from about $110K, the lean vendor itemization, up to several hundred thousand dollars for a multi-engineer, multi-month build. Three-year TCO runs from the high six figures up to about $1.1M. Either bound makes the same point: building in-house is a high-six-figure to seven-figure multi-year commitment that dwarfs managed-SSO subscriptions for almost every B2B SaaS.

Per-approach estimates show where the money goes. One published breakdown from TechConcepts puts a pre-built connector at $3K to $8K, OIDC middleware at $8K to $25K, custom SAML 2.0 at $20K to $60K, a full in-house OAuth2 or OIDC implementation at $60K to $150K or more, SCIM at $8K to $20K, and audit logging at $5K to $15K plus $100 to $500 per month to run (TechConcepts, 2025⁠). On top of the build, every enterprise deal carries recurring onboarding labor: WorkOS describes a customer (Prefect) that saved about 300 engineering hours across 100+ in-house SSO connections by automating the work, roughly 3 hours per connection (WorkOS Prefect case study⁠). At the loaded engineer rate built up above (about $90 to $115 per hour), that's on the order of $300 per enterprise customer, and it recurs on every deal.

Compliance is a build cost too. A SOC 2 Type II audit costs $30K to $150K, with recurring cost to maintain the certification each year afterward (Bright Defense⁠). A formal GDPR program and region-locked data residency are each additional line items that arrive with enterprise deals. None of these are optional once an enterprise buyer's questionnaire arrives.

The hidden cost of no SCIM. Skipping SCIM does not remove the cost, it relocates it to manual provisioning. Stitchflow's research puts the manual-provisioning burden at roughly $12,000 per app per year in IT labor, unused licenses, and compliance gaps (Stitchflow⁠). For a provider with no SCIM at all, like Supabase, Firebase, or Cognito, that labor lands on your team or your customer's IT, and it scales with every enterprise account you add. The "we'll just provision manually" plan is a recurring four-figure-per-app annual cost that grows with your customer base.

Enterprise SSO provider pricing comparison

Enterprise SSO list prices range from a flat $75 to $125 per connection (WorkOS, Clerk) to per-MAU metering that starts free and climbs with your user count (Auth0, Supabase, Firebase, Cognito) to per-seat IdP contracts that negotiate around $44,000 a year (Okta Workforce). Here is each major provider, priced against its June 2026 list, with units, caps, SCIM, and transparency called out so you can compare like with like. Clerk appears as one option among the rest; the deeper recommendation comes later.

How to read this comparison

Units vary, so read the model column first. Per-connection vendors charge a flat fee per enterprise customer; per-MAU vendors charge by total authenticated users; per-seat vendors charge per employee at the customer that runs the IdP. A "$0.015/MAU" price and a "$125/connection" price are not comparable line items, and the cheapest headline base plan is often not the cheapest once you add the connection caps and SCIM gating that actually bite.

All prices below are June 2026 list prices read from each provider's public pricing page. "Contact sales" is itself a signal: a provider that publishes per-connection or per-MAU pricing through 100+ connections is more predictable to budget than one that requires a quote for the second enterprise customer.

Two rules apply to every entry. First, each enterprise-SSO price is marked by basis: public list, public to a named tier, third-party estimate, or quote-only. Second, compliance is phrased as "SOC 2 Type II available; report access plan-gated (<plan>)" rather than a bare "SOC 2 Type II," because what varies between providers is rarely whether a report exists and almost always which plan unlocks access to it.

WorkOS

WorkOS is per-connection and flat per company: one enterprise customer is one connection at one price, regardless of how many seats that customer has. SSO runs $125 per connection for the first 15, then $100 (16–30), $80 (31–50), $65 (51–100), $50 (101–200), and custom above 200, with volume discounts applied automatically and no sales call required through 200 (WorkOS pricing, 2026⁠). SCIM (Directory Sync) follows the same ladder, so a connection that needs both SSO and provisioning is billed twice at the entry tier ($125 + $125).

WorkOS bundles a lot around that connection. AuthKit is free to the first 1,000,000 MAU, then $2,500 per additional million. The Admin Portal, a hosted page where a customer's IT admin self-configures their own IdP, is included (WorkOS Admin Portal, 2026⁠); a custom domain on it costs $99 per month (WorkOS pricing, 2026⁠). Audit logs are $99 per month per 1,000,000 events plus $125 per month per SIEM connection (WorkOS audit logs, 2026⁠). WorkOS holds a SOC 2 Type II report.

Negotiated reality differs from list. Third-party procurement data puts the average WorkOS contract at $21,292 (Vendr, 2026⁠) and the enterprise average at $86,580 (Spendhound, 2026⁠); treat both as third-party estimates, not WorkOS list prices.

Auth0 (Okta Customer Identity Cloud)

Auth0, branded Okta Customer Identity Cloud, is per-MAU with connection caps layered on top. The free tier covers 25,000 MAU and 1 Enterprise Connection, and as of February 12, 2026 Auth0 includes free inbound SCIM across all tiers and free Self-Service SSO on its self-service plans (including Free) (Auth0 B2B plans upgraded, 2026⁠; Auth0 pricing, 2026⁠). Free inbound SCIM is a genuine advantage here, since most competitors charge for it. Two caveats keep the comparison fair: it is inbound provisioning only (an IdP pushing users into Auth0, not Auth0 syncing out to downstream apps), and it runs through Auth0's Enterprise Connections, of which the Free tier includes one. Weigh it against the connection caps below.

The paid B2B tiers are MAU-tiered, so the monthly price you see at 500 MAU is not the price you pay as you grow. B2B Essentials starts at $150 per month at 500 MAU with 3 Enterprise Connections included and steps up to $3,800 per month at 20,000 MAU. B2B Professional starts at $800 per month at 500 MAU with 5 Enterprise Connections included and rises to $2,400 per month at 10,000 MAU (Auth0 pricing, 2026⁠). Be explicit about which world you are pricing: these are the B2B numbers, distinct from Auth0's consumer (B2C) Customer Identity Cloud. Auth0 has repriced that consumer side before: its late-2023 changes moved B2C Essentials to $35 per month for 500 MAU, up from $23 per month for 1,000 MAU (Auth0 pricing-change history, 2024⁠), roughly tripling the effective entry rate from $0.023 to $0.07 per MAU. That is the historical consumer figure, not the current B2B rate; current B2B plans bill at the next MAU tier up rather than a published per-user overage.

Beyond the included connections, Auth0 prices each additional connection at $100/month on Essentials and Professional, before any Enterprise contract. That figure surfaces in Auth0's interactive pricing calculator rather than its static pricing copy, so treat it as auditable-but-unpublished (Auth0 pricing calculator, June 2026; subject to change). This is worth stating precisely because the number matches Clerk's add-on price and the two are easy to confuse: Auth0's $100 is charged per additional connection, while Clerk's $100 is a single flat monthly add-on. Same figure, different unit. The old framing where a sixth connection forced an Enterprise contract no longer applies; Essentials includes 3 and Professional 5, each expandable through the self-service add-on before sales gets involved. Auth0's interactive calculator caps self-service connections at 30 total (it shows a "max 30 total"), a ceiling that surfaces only in the calculator and not in Auth0's static pricing copy, so treat it as calculator-read rather than published prose.

Above the self-service ceiling, Auth0 is a custom Enterprise quote. A commonly cited "~$30,000+ per year" floor for that tier is a third-party estimate, not an Auth0 list price; label it as such when you use it.

Okta

Okta sells two different products, and the distinction decides which one you are pricing. Workforce Identity Cloud is a per-seat IdP that a company runs for its own employees; Customer Identity Cloud is Auth0, the per-MAU CIAM that a SaaS embeds for its customers. When a B2B SaaS asks "what does Okta cost to add SSO to my product," the Okta-family answer is Auth0/CIC, covered above. Workforce is what your enterprise customer runs on its side of the connection.

Workforce Identity is priced per user per month in bundles: Starter Suite at $6 (SSO, MFA, Universal Directory); Core Essentials at $14, which bundles Lifecycle Management with SCIM provisioning; and Essentials Suite at $17, the "Most Popular" tier, which layers Adaptive MFA and Access Governance on top. There is a $1,500 per year annual contract minimum, and Okta lists 8,000+ integrations (Okta pricing, 2026⁠; Okta integrations, 2026⁠). Higher Pro and Enterprise tiers are quote-only. A standalone "~$2 per user SSO" line is third-party-only and no longer a published item, so label it an estimate if you cite it and lead with the verified bundles instead.

Negotiated contracts are the number that matters here. The median Okta deal runs about $44,000 per year (Vendr, 2026⁠, median $44,616 across 1,981 purchases). A frequently quoted $218,436 figure is a documented high-end anecdote, not a typical minimum; use the $44,000 median as the spine and cite the high end only as the outlier it is. Okta is also a frequent subject of the "Okta tax," the SaaS-side SSO upcharges catalogued elsewhere in this article, where vendors gate SSO behind their priciest tier.

Supabase Auth and Firebase Auth

Supabase Auth and Firebase Auth are per-MAU and aimed at developers who want auth bundled with their backend. Both support SAML and OIDC, but neither offers SCIM provisioning or a self-serve admin UI where a customer's IT team configures its own connection, which are real cost-of-ownership gaps for B2B SSO.

Supabase Pro is $25 per month and includes 100,000 MAU, then $0.00325 per MAU. SAML 2.0 SSO is free for the first 50 SSO MAU, then $0.015 per SSO MAU (Supabase pricing, 2026⁠; Supabase SSO MAU docs, 2026⁠). That $0.015 is a retail metered price for the SSO feature, not an "infrastructure cost." The hidden compliance cost is the tier jump: SOC 2 Type II and ISO 27001 report access is gated to the Team plan at $599 per month, so a Pro customer who needs the report pays the roughly $574 monthly step up to Team.

Firebase, through Google Cloud Identity Platform, prices SAML/OIDC at $0.015 per MAU after 50 free, with no SCIM and no self-serve admin UI (Firebase pricing, 2026⁠; Google Cloud Identity Platform pricing, 2026⁠). AWS Cognito is similar: $0.015 per SAML/OIDC-federation MAU after 50 free, charged at that same rate across its Lite, Essentials, and Plus tiers (the 2024 tier restructure changed direct and social sign-in pricing, not federation), with no SCIM, AWS-native, and no self-serve admin UI (AWS Cognito pricing, 2026⁠).

PropelAuth, Frontegg, Descope, Stytch, and Kinde

These five are B2B-focused auth providers with distinct SSO pricing structures worth comparing directly.

PropelAuth puts unlimited SSO on its Growth plan at $150 per month with no per-connection fee; SCIM moves you to Growth Plus at $500 per month plus $100 per connection (PropelAuth pricing, 2026⁠). Frontegg's free tier is unusually generous: 7,500 MAU and 5 enterprise connections with SSO and SCIM bundled together, after which Enterprise is custom; a mid-market estimate of $500–$2,500 per month is a third-party estimate, not a published Frontegg price (Frontegg pricing, 2026⁠). Descope is free to 7,500 MAU and 3 SSO connections, then Pro at $249 per month (5 SSO) and Growth at $799 per month (10 SSO), with SCIM starting at the Growth tier (Descope pricing, 2026⁠).

Stytch, acquired by Twilio, is free to 10,000 MAU and 5 SSO/SCIM connections, then +$125 per connection (Stytch pricing, 2026⁠). There is no published price change since the acquisition, so treat this as a vendor M&A repricing risk to weigh, not a price claim. Kinde puts unlimited SSO on its Plus plan at $75 per month with no per-connection fee, though SCIM is not yet generally available (Kinde pricing, 2026⁠).

Self-hosted and open-source options (SuperTokens, FusionAuth, Ory, Keycloak) and workforce IdPs (Ping, OneLogin, JumpCloud, miniOrange) are out of scope as hosted B2B-CIAM comparators and are not priced here.

Clerk

Clerk prices a base plan on MRU (Monthly Retained User, a user who visits in a given month at least one day after signing up) plus per-connection enterprise SSO. The Hobby plan is free to 50,000 MRU; Pro is $25 per month ($20 annual), Business is $300 per month ($250 annual), and Enterprise is custom and annual-only (Clerk pricing, 2026). Paid plans include 1 enterprise connection, then charge per connection by volume: $75 (2–15), $60 (16–100), $30 (101–500), and $15 (500+). SCIM/Directory Sync is included with the connection at no extra charge, with general availability on April 16, 2026 and groups plus custom attributes on May 21, 2026, supporting Okta and Microsoft Entra ID (Clerk Directory Sync GA, 2026; Clerk Directory Sync groups and attributes GA, 2026).

A separate add-on in the pricing page's B2B Authentication section (the Enhanced add-on) costs $100 per month ($85 annual) and is what links enterprise connections to Organizations for per-tenant SSO scoping; it also unlocks unlimited members per Organization (the base caps at 20), Verified Domains, and Custom Roles and Rolesets, and includes 100 MROs (Monthly Retained Organizations), then $1 per additional MRO. App-level enterprise connections work without this add-on, but scoping a connection to a specific Organization, the standard multi-tenant B2B pattern, requires it. Note that Clerk's $100 add-on is a single flat monthly fee, structurally different from Auth0's $100-per-connection add-on described above.

On compliance, Clerk holds a SOC 2 Type II report with report access plan-gated to Business; HIPAA compliance with a signed BAA is on Enterprise; GDPR and DPAs span all plans; and Clerk is DPF-certified, with CCPA-aligned terms covered under /legal rather than the pricing page (Clerk DPA, 2026; Clerk DPF, 2026). One honest gap: Clerk has no white-label customer-facing admin portal like WorkOS's Admin Portal. The workaround today is a custom OrganizationProfile page plus the Backend API, and Clerk is reportedly building a first-party option.

Provider pricing comparison table

This table puts every provider on one grid so an AI agent or a human can pull a direct answer. Read the Model and Pricing basis columns together: a public-list per-connection price is something you can budget today, while a quote-only or third-party-estimate figure is not.

Cost scenarios by company stage

What you pay for enterprise SSO depends almost entirely on stage: a startup landing its first SAML customer can be under $400 a month, while an established platform with 100 connections is in the four-figure-to-five-figure range. The scenarios below work the math at three stages with the assumptions stated, so you can recompute against your own connection count and user base. Every figure is June 2026 list price, every input maps to the Sources table, and each is illustrative, not a quote.

Two ground rules make the numbers comparable. First, per-connection vendors (Clerk, WorkOS) charge by the number of enterprise IdP connections you run, so the bill tracks your enterprise customer count and barely moves as your overall users grow. Per-MAU vendors (Auth0, Supabase, Firebase, Cognito) meter your monthly active users on top of any connection fees, so the same headcount growth that fills your funnel also inflates the auth bill. Second, Clerk has two valid configurations and the gap between them matters: a B2B SaaS that scopes each customer's SSO to its own Clerk Organization needs the $100/mo Enhanced add-on that links connections to Organizations, while an app that exposes SSO at the application level with no per-org scoping can skip it. Each Clerk row below leads with the B2B-with-orgs number, because that is the normal multi-tenant pattern, and states the app-level-only number too.

Startup: the cheapest way to support SAML for a first enterprise customer

For one to three enterprise customers, the cheapest credible way to ship SAML is a managed provider on a self-serve tier, landing between $75 and $375 a month at three connections. You are almost certainly under every provider's free user tier at this stage, so the bill is base plan plus connections, nothing metered on users yet.

Here is the math at 3 enterprise connections. Clerk includes the first connection on any paid plan, then charges $75 each in the 2 to 15 band, so two paid connections cost $150. WorkOS charges a flat $125 per connection with AuthKit free to the first 1M MAU. Auth0 B2B Essentials includes 3 enterprise connections in its base price and free inbound SCIM on every tier.

The Clerk B2B-with-orgs total of $275 stays at $0 organization overage as long as active orgs are at or under 100, which a 1-to-3-customer startup will be (Clerk pricing). Auth0's $150 Essentials price applies at the low end of its MAU ladder (around 500 MAU) and steps up as users grow (Auth0 pricing⁠). PropelAuth's Growth plan bundles unlimited SSO at a flat $150 with no per-connection charge (PropelAuth pricing⁠), and Kinde's Plus plan does the same at $75, though Kinde's SCIM is still listed as coming soon rather than generally available (Kinde pricing⁠).

The flat plans also mark the per-connection crossover, which you can compute yourself. Solve base + n × price_per_connection = flat_plan for the connection count n where the two models cost the same. Against PropelAuth's $150 flat plan, WorkOS at $125 per connection is cheaper for a single connection ($125 < $150) but the second connection flips it ($250 > $150), so the crossover sits at two connections. Past one connection, an unlimited-SSO flat plan is cheaper on the SSO line until a per-MAU component or a higher base plan catches up. A startup weighing SSO cost alone should price the flat plans against its expected connection count, while remembering that the per-connection model's real advantage is predictability as user counts grow, not being the lowest sticker at one or two connections.

Against any of these, building the connection in-house is the wrong call at this stage. As covered in the engineering-cost section, a representative in-house SAML build plus ongoing maintenance and a SOC 2 Type II audit lands in the high six figures over three years. Spending six figures to avoid a $75-to-$375 monthly subscription, before you have proven the enterprise motion, is hard to justify.

Mid-stage: scaling to roughly 10 to 50 enterprise customers

At 10 to 50 enterprise customers and roughly 50,000 users, per-connection pricing climbs into the low thousands per month, and this is where per-MAU vendors start charging twice: once for the connections, once for the now-substantial user base. The volume math also begins to matter, because both Clerk and WorkOS discount per-connection rates as the count rises.

The calculation at 50 connections shows the spread. Clerk's rate steps from $75 (connections 2 to 15) to $60 (connections 16 to 100), so 14 connections bill at $75 and 35 at $60. WorkOS steps from $125 (1 to 15) to $100 (16 to 100), and at this band its published ladder works out across the tiers it crosses.

Three things stand out. Clerk's B2B-with-orgs total of about $3,275 still carries $0 organization overage at around 50 active orgs, since the add-on includes 100 (Clerk pricing). The WorkOS figure of about $4,975 is SSO connections only; if you also need Directory Sync, WorkOS prices SCIM on the same per-connection ladder as SSO, which roughly doubles the connection bill (WorkOS pricing⁠). Auth0 is the structural problem at this scale: Professional includes 5 enterprise connections, and Auth0's pricing calculator prices additional self-service connections at "$100/month per additional connection" before an Enterprise contract (Auth0 pricing calculator, June 2026; subject to change⁠). The calculator caps self-service connections at 30 total, so by roughly 50 connections you are well past the self-service range and into an Enterprise quote. Auth0's $100-per-additional-connection add-on is a different unit from Clerk's add-on: Auth0's is charged per connection, while Clerk's $100 Enhanced add-on is a single flat monthly fee regardless of connection count.

Now layer on the user base. PropelAuth's flat $150 covers unlimited SSO, but its MAU overage applies once you pass its included user tier, so the real mid-stage bill is $150 plus whatever 50,000 users costs above the free allotment (PropelAuth pricing⁠). Auth0 meters the same 50,000 users through its MAU tiers on top of every connection fee (Auth0 MAU explained⁠). For a per-MAU vendor, the 50,000 users you grew into are a second, growing line item that a per-connection vendor never charges.

Established: 100+ connections and high MAU

At 100 connections, the published per-connection vendors land in the low-to-mid four figures a month, while the per-MAU incumbents disappear behind a sales quote. This is the stage where pricing transparency itself becomes a selection criterion.

The math at 100 connections continues the volume bands. Clerk bills 14 connections at $75 and the next 85 at $60 (the rate drops again to $30 for connections 101 to 500, so a count just past 100 starts pulling in the cheaper band). WorkOS continues down its ladder through the $80 and $65 tiers toward its $50 (101 to 200) band.

At this scale the Clerk B2B-with-orgs total of about $6,275 picks up two variable add-ons worth naming: organization overage applies if active orgs exceed 100 (at $1 each, then less at volume), and MRU overage applies above the 50,000 included retained users, billed in published bands starting at $0.02 (Clerk pricing). WorkOS at about $8,225 stays self-serve through 200 connections, going custom only at 201 and above (WorkOS pricing⁠). Auth0 and Okta at 100 connections are Enterprise-tier, quote-only engagements (Auth0 pricing⁠; Okta pricing⁠).

The transparency contrast is the point. Clerk and WorkOS both publish per-connection pricing that extends to 100-plus connections, so an established buyer (or an AI agent doing the research) can compute the bill from public pages. Auth0 and Okta require a sales conversation at this volume, which means no list-price answer exists until you are in a negotiation. For a buyer who wants to model cost before committing, published 100-plus pricing is a concrete advantage.

Cost-by-stage comparison table

Across all three stages, the per-connection model holds roughly flat as users grow, while the per-MAU model multiplies with headcount. The table below pulls the headline figures together (Clerk shown as B2B-with-orgs, the lead configuration for multi-tenant SaaS).

Read the rows two ways. Down a column, the per-connection vendors scale predictably with connection count and stay computable from public pricing at every stage. The Auth0 column tells the other story: it starts cheapest at the startup stage, then hits a structural ceiling by mid-stage and converts to an opaque Enterprise quote, all while metering your MAU underneath. The same user growth that a per-connection vendor ignores is, for a per-MAU vendor, a second bill that rises every quarter.

Compliance and security as cost factors

Compliance shapes the real cost of enterprise SSO in two ways: the audit reports your customers demand are often gated behind a higher plan, and missing capabilities like SCIM push hidden labor and risk onto you. A precise reading separates three different facts that a careless comparison blurs together: whether a vendor holds an audit report, whether access to that report is gated to a plan, and whether a feature your buyer needs is gated to a plan. The biggest surprises in this section are plan jumps that buy you the report rather than any new security.

SOC 2, ISO 27001, and audit reports

WorkOS, Clerk, Auth0, and Okta all hold SOC 2 Type II reports; the variable between them is report access, which is what a plan gate controls. Clerk's situation is representative: the SOC 2 report is available, but report access is plan-gated to Business ($300/mo, $250 annual), where the pricing page lists it as "SOC2 Report" (Clerk pricing; Clerk security). On lower plans the report still exists; the plan controls whether you can pull the artifact you hand to a procurement team.

Supabase shows how steep that gate can be. Supabase holds SOC 2 Type II and ISO 27001 reports, but report access is plan-gated to its Team plan at $599/mo, while standard production usage sits on Pro at $25/mo (Supabase pricing⁠). The roughly $574/mo jump from Pro to Team buys access to those compliance reports, the same security you already had on Pro, now documented for a procurement team. That Pro-to-Team step is the hidden compliance cost: the spend goes toward proving security on paper rather than adding auth capability. When you compare providers, check which plan grants report access, because the headline tier may not be the tier your enterprise deal actually requires.

GDPR, data residency, and DPAs

Clerk provides GDPR compliance and Data Processing Agreements across all plans, is certified under the EU-US Data Privacy Framework, and publishes its DPA at its legal pages rather than gating it to a tier (Clerk DPA; Clerk DPF). CCPA-aligned obligations are covered under Clerk's /legal pages rather than the pricing page, so a buyer should look there rather than expecting it as a pricing line item. Making the DPA and data-protection terms available on every plan removes a common procurement blocker that some vendors reserve for higher tiers.

Data residency is where this turns into a real number. Pinning customer data to a specific region (the EU, for instance) to satisfy GDPR or a customer's contractual requirement is frequently a paid feature or a surcharge across the identity market, and it is exactly the kind of requirement that arrives with a large enterprise deal. Treat regional data residency as a line item to price during the deal, not an assumed default, because it can move the effective monthly cost well above the headline plan.

When missing compliance becomes a hidden cost

The most expensive compliance gap is the feature a provider does not offer at all, because the cost does not disappear, it relocates to your team. Providers with no SCIM, including Supabase, Firebase, and AWS Cognito, leave you to handle user provisioning and deprovisioning manually (Supabase SSO MAU docs⁠; Firebase pricing⁠; AWS Cognito pricing⁠). That manual work carries a measurable price: Stitchflow's research puts manual provisioning at roughly $12,000 per app per year in IT labor, unused licenses, and compliance gaps (Stitchflow⁠).

The risk side is worse than the labor side. Manual deprovisioning is the failure mode behind orphaned accounts: when an employee leaves and the IdP has no automated path to revoke their access in your app, that account can stay live, which is precisely the audit finding enterprise security reviews exist to catch. A provider without SCIM does not just add hours, it adds a standing compliance and security liability that grows with every enterprise account you onboard. When you price a no-SCIM provider, add the annual manual-provisioning cost and the deprovisioning risk to the headline number, because both are real costs the sticker price omits.

How to choose an enterprise SSO pricing model

Pick the model that matches how you acquire customers, not the one with the lowest headline number. If you sell to a handful of large enterprises, per-connection pricing is the most predictable choice because cost tracks your customer count, not your user count. If your usage skews high-volume and consumer-ish, a per-MAU model can stay cheap until one big-seat customer makes it expensive overnight. The rest of this section gives you the questions to ask, a framework by stage, the red flags that penalize growth, and a compact table that maps your situation to a recommended model.

Questions to ask a provider before you commit

Run every shortlisted provider through the same checklist before you sign. Most of these answers are buried below the headline price, and the gap between "the plan costs $X" and "this provider costs $X at our scale" is exactly where teams get surprised.

Save the answers. The provider that looks cheapest at the entry tier is frequently not the cheapest at 50 connections, and the only way to see that is to price all of them at the same scale points.

A decision framework by growth stage and customer profile

The right model depends on your customer mix more than your headcount. Match your situation to one of these patterns.

Few large enterprise customers. Choose per-connection. A 5,000-seat customer costs the same as a 50-seat one, so your bill tracks how many enterprise logos you've signed, which is the number you can actually forecast. This is the common case for B2B SaaS moving upmarket.

Many small customers plus a few large ones. Choose a hybrid or per-connection model that includes a base connection. You want predictable per-customer cost without paying an enterprise-tier jump for the first deal, so a plan that bundles one connection into its base price (then charges per connection after) fits cleanly.

High-MAU, consumer-ish usage. Watch per-MAU pricing carefully. If most of your users are consumers and only a slice need SSO, a per-MAU meter can make total authenticated users, not enterprise customers, the thing that dominates your bill. Model the overage at your real user count before committing.

Your first enterprise customer, on a budget. Pick a provider that includes a connection in its base plan rather than one that gates SSO behind an enterprise tier. Clerk Pro ($25/mo, $20/mo annual) and Auth0 B2B Essentials ($150/mo at 500 MAU, 3 enterprise connections included) both ship a usable SSO connection on an affordable plan (Clerk pricing; Auth0 pricing⁠). That avoids the worst first-deal trap: paying for a full enterprise contract just to turn on one SAML connection.

Red flags: pricing structures that penalize growth

Some pricing structures look fine on your first enterprise deal and turn punishing by your tenth. Watch for these.

Connection caps and the connection trap. A plan that includes 3 to 5 connections and then forces a tier jump or a sales conversation to add the next one means your pricing is hostage to your sales pipeline. The cap bites harder than the per-unit price: the customer that pushes you over the included count can trigger a step-change in cost rather than a marginal one.

Steep MAU overages and repricing. Per-MAU pricing can reprice sharply, and there's primary precedent. Auth0's late-2023 B2C changes raised B2C Essentials to $35 per month for 500 MAU, from $23 per month for 1,000 MAU (Auth0 pricing-change history⁠) — half the included users at a higher price, which roughly triples the effective entry rate ($0.023 to $0.07 per MAU). That change is historical and consumer-tier specific, not Auth0's current B2B rate, but it shows how fast a metered model can reprice the users you've already acquired.

Per-MAU and per-connection compounding. The most expensive structures charge for users and connections at the same time, so growth on either axis raises the bill. You can see the effect by computing it yourself from published rates rather than trusting a vendor's pre-baked multiplier. Take Auth0's B2B Essentials, which steps from $150/mo at 500 MAU to $3,800/mo at 20,000 MAU on user count alone, and layer on its calculator-quoted add-on of $100/mo per additional connection (Auth0 pricing calculator, June 2026; subject to change⁠). A team at 500 MAU with 3 included connections pays $150/mo; the same team grown to 20,000 MAU with 10 connections (3 included, 7 add-ons at $100) pays roughly $3,800 + $700 = $4,500/mo. The user-count escalation and the connection charges stack. Note that Auth0's $100 is per additional connection, a different unit from Clerk's flat $100/mo B2B add-on, so don't conflate the two even though the number matches. Prefer the math you can reproduce from published rates, like the example above, over any pre-baked compounding multiplier a vendor analysis hands you, since those bake in assumptions you can't audit.

"Contact sales" opacity. When a provider won't publish what the next tier costs, that opacity is itself a signal. You can't forecast a bill you can't see, and "contact sales" before you've even hit enterprise scale usually means the price is set in the room, not on the page.

Vendor M&A repricing risk. Ownership changes can reprice a product, sunset a free tier, or shift a roadmap after you've integrated. Twilio completed its acquisition of Stytch on November 14, 2025 (announced October 30, 2025), and while there's no published Stytch price change yet (Stytch pricing⁠), the acquisition is a fair, named example of why vendor stability belongs in your cost analysis. This is a forward-looking risk to weigh, not a prediction of a hike.

Migration and lock-in costs

Pricing models get sticky because switching providers is expensive, which is why the model you pick before your first enterprise customer matters for years. Once you're live, leaving means re-establishing user sessions and identity data, re-issuing IdP metadata and SAML ACS URLs, re-pointing every SCIM endpoint, preserving audit trails, and re-running each enterprise customer's IT team through reconfiguration. That last item is the painful one: every customer connection you migrate is a separate coordination project with someone else's IT department.

Those switching costs are the real reason a bad pricing fit compounds. A model that's merely annoying at 5 connections is one you stay locked into at 50, because the migration is its own multi-quarter project, not a config change. The practical takeaway: favor providers whose pricing stays predictable as you scale, so you're never forced into a costly migration just to escape your own bill.

Which model should you choose?

How Clerk approaches enterprise SSO pricing

Clerk prices enterprise SSO per connection on top of an MRU-based plan, includes one enterprise connection on every paid plan, and bundles SCIM directory sync with the connection at no extra charge (Clerk pricing; Clerk Directory Sync GA). For a B2B SaaS that wants predictable cost as it adds enterprise customers, that combination avoids the two things that make SSO pricing unpredictable elsewhere: per-user metering on total signups and connection caps that force a tier jump or a sales call. Clerk is a fit when you want self-serve, published per-connection pricing; the honest gaps are at the end of this section.

Clerk's enterprise SSO pricing model

Clerk bills on monthly retained users (MRU), defined as users who visit your app in a given month at least one day after signing up, and the Hobby plan includes 50,000 MRU free (Clerk pricing). That unit is a structural advantage over per-MAU pricing for any app with churn at the top of the funnel: you don't pay for the signups who never come back, whereas a pure MAU count bills them. There's no Clerk-published MRU-to-MAU ratio, so treat any conversion between the two as your own assumption rather than a published number.

Every paid plan includes 1 enterprise SSO connection. Additional connections are priced per connection by volume: $75 each for connections 2 through 15, $60 for 16 through 100, $30 for 101 through 500, and $15 beyond 500 (Clerk pricing). SCIM directory sync is included with the enterprise connection at no extra charge, with support for Okta and Microsoft Entra ID; directory sync reached general availability on April 16, 2026, and groups plus custom attributes followed on May 21, 2026 (Clerk Directory Sync GA; Clerk Directory Sync groups and attributes GA).

One detail matters for multi-tenant B2B and deserves a plain statement. App-level enterprise connections work without any add-on. But linking an enterprise connection to a specific Organization, the standard multi-tenant pattern where each customer gets its own org scoped to its own IdP, requires the Enhanced add-on in the pricing page's B2B Authentication section: $100/mo ($85/mo annual), which includes 100 monthly retained organizations (MRO) and also adds unlimited members per organization, Verified Domains, and Custom Roles (Clerk pricing). So a buyer building per-org B2B SSO should budget the add-on; a buyer who only needs application-level SSO should not.

Per-connection SSO without tier cliffs or forced sales calls

Clerk's per-connection model means the next enterprise customer adds a known, marginal cost instead of triggering a cliff. On connection-capped plans, the customer that exceeds your included count can force a jump to a higher tier or a "contact sales" conversation; with per-connection pricing, you just pay for one more connection at the published rate.

The entry-tier numbers also favor Clerk on a like-for-like comparison. Clerk's first paid connection is $75 versus WorkOS's $125 at its entry tier (Clerk pricing; WorkOS pricing⁠), and Clerk includes SCIM with the connection at no extra charge (Clerk Directory Sync GA). At several competitors, SCIM is a separate charge: WorkOS prices directory sync on the same ladder as SSO ($125/connection at entry), PropelAuth charges $100 per connection for SCIM on its Growth Plus plan, and Okta meters provisioning per user (WorkOS pricing⁠; PropelAuth pricing⁠; Okta pricing⁠). Clerk won't be cheapest at every scale, but the per-connection rate is lower at entry and provisioning comes bundled instead of as a surprise add-on.

Scaling with monthly retained users and organizations

Clerk does not publish enterprise pricing. Enterprise contracts are custom and billed annually, and they come with volume discounting on both MRU and MRO (Clerk pricing). That's the one place where talking to sales genuinely buys you something: at high user or organization volume, the per-unit rate is negotiable in a way the published bands aren't.

For most readers, though, the published self-serve pricing is the whole answer. A startup with a few enterprise customers, a mid-stage company with dozens, and most teams scaling to 100 connections can price themselves directly from the per-connection bands and the plan fees without ever contacting sales. The MRU model means your base cost scales with retained users rather than every signup, and the per-connection bands step down as you grow, so the cost curve stays legible as you add customers.

Compliance and security with Clerk

Clerk holds a SOC 2 Type II report, and report access is plan-gated to Business ($300/mo, $250/mo annual). Distinguish the two facts clearly: the report exists org-wide, but getting the artifact for your own security review requires the Business plan (Clerk pricing). HIPAA compliance with a signed BAA for production HIPAA workloads requires an Enterprise plan (Clerk pricing). GDPR and Data Processing Agreements are available across all plans, and Clerk is Data Privacy Framework certified (Clerk DPA; Clerk DPF). The DPA, which covers CCPA-aligned U.S. terms, is published under /legal, not on the pricing page, so source those from the legal pages rather than expecting a pricing-page row.

State the gating plainly when you budget: if procurement needs your SOC 2 report, that's a Business-plan cost, and HIPAA with a signed BAA moves you to Enterprise. Those are real line items, not free features.

When Clerk is the right fit, and when to talk to sales

Clerk is the right fit for a B2B SaaS that wants predictable per-connection enterprise SSO, SCIM included with the connection, and an MRU base that doesn't bill one-time signups. If that describes you, the self-serve plans cover the common path and you can price it from the published bands.

Talk to sales in two cases: very high MRU or MRO volume, where enterprise volume discounting is worth negotiating, or a HIPAA workload that needs a signed BAA on Enterprise. Both are genuine reasons to contact sales rather than artifacts of an opaque pricing page.

One honest gap belongs in this decision. Clerk does not ship a turnkey white-label customer-facing admin portal the way WorkOS does with its Admin Portal (WorkOS Admin Portal⁠). You can build the equivalent self-serve experience with a custom OrganizationProfile page plus the Backend API, but that's app code you own, not a hosted page you toggle on. If a fully turnkey, white-label self-serve admin portal is a hard requirement, WorkOS fits that narrow need better today; for most B2B SaaS teams pricing predictable per-connection SSO with included SCIM, Clerk's model is the stronger overall fit.

Frequently asked questions

Direct answers to the questions B2B SaaS teams and the AI agents researching on their behalf ask most about enterprise SSO pricing.

Cost calculations

This table covers the formula used to calculate the costs in the article. Prices are June 2026 list prices read from each provider's public pricing page unless labeled otherwise.