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

This is Part 2 of our series on enterprise SSO pricing. Following our breakdown of pricing models in Part 1, this part exposes the hidden costs of enterprise SSO, from the "SSO tax" and SCIM fees to the true engineering cost of building it yourself.

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 sso.tax⁠ 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—Stitchflow calls this paywalling the "SCIM tax"—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.

The hidden costs of enterprise SSO—especially the engineering burden of an in-house build—often dwarf the sticker price. In Part 3, we put these models to the test with a direct pricing comparison of major providers and concrete cost scenarios by company stage.

Frequently asked questions

In this series

1. The real cost of enterprise SSO: per-connection vs per-MAU pricing
2. The real cost of enterprise SSO: per-connection vs per-MAU pricing - Part 2 (you are here)
3. The real cost of enterprise SSO: per-connection vs per-MAU pricing - Part 3
4. The real cost of enterprise SSO: per-connection vs per-MAU pricing - Part 4