The Real Cost of SSO and SCIM: Look Beyond Per-Connection Pricing

When companies evaluate SSO (Single Sign-On) and SCIM (System for Cross-domain Identity Management), the most common trap is focusing on the "per-connection price." That number looks straightforward and makes it easy to compare vendors side by side—but what actually determines your final bill is often the variables hidden behind the quote.

Why Per-Connection Pricing Misleads You

The per-connection price is usually the number vendors are most eager to show: $X per enterprise customer per month, seemingly clear and transparent. The problem is that this number is rarely the actual billing basis.

Take SSO as an example. Many vendors define a "connection" very differently. Some count by identity provider (IdP) instance, some use tiered pricing based on active users, and others charge for SCIM auto-sync as a separate add-on module. When you stack these dimensions together, the actual cost can be several times the initial quote.

SCIM is even more complex. It involves user lifecycle management—from automatically creating accounts during onboarding to instantly revoking access upon offboarding. The value of this capability rises sharply as enterprise customer size grows, but the corresponding pricing models are often more opaque.

SCIM (System for Cross-domain Identity Management) is an open standard based on HTTP/REST (RFC 7642/7643/7644) for automatically syncing user and group data between enterprise identity providers (IdPs) and SaaS applications. It solves the "user lifecycle management" problem: automatically creating accounts and assigning permissions on the application side when a new employee joins, immediately deactivating or deleting accounts upon departure, and adjusting access levels when roles change. Without SCIM, these operations typically rely on manual administrator work or CSV import/export, which is slow and error-prone. SCIM is usually used alongside SSO: SSO solves the authentication problem of "log in once to access multiple applications," while SCIM solves the provisioning problem of "when accounts are created, modified, and deleted." The two use different protocols and different pricing models, which is why vendors often charge for SCIM as a separate add-on module—and why the article emphasizes accounting for them separately.

A Cost Estimation Framework Across Three Scale Tiers

The original article proposes a practical worksheet approach: estimating enterprise authentication costs across three tiers—5, 25, and 100 enterprise customers. The value of this framework is that it forces you to think about how scale effects change the cost structure.

5 Customers: Hidden Fixed Costs Dominate

At very small scale, your biggest costs are often fixed in nature: SSL certificates, domain configuration, compliance audit preparation, and operations manpower. These costs are independent of how many customers you serve, but they significantly inflate per-customer costs.

The key question at this stage is: are you adding SSO capability to your own product, or providing customers with a standalone authentication service? The cost structures are completely different.

25 Customers: The Tipping Point of Tiered Pricing

When your customer count grows to around 25, you likely hit the first tier in your vendor's pricing model. Many authentication service providers start charging based on active users or API call volume in this range, rather than simple connection counts.

SCIM configuration complexity also begins to show at this stage. Different customers may use different identity providers (Okta, Azure AD, Google Workspace, etc.), and each additional IdP type requires extra adaptation and testing work.

100 Customers: Negotiating Leverage and the Build-Option

At 100 customers, you finally have leverage to negotiate with vendors. Volume discounts, custom contracts, and dedicated support can all become tools for reducing costs.

More importantly, at this scale the "build vs. buy" decision starts to make sense. If authentication is a core differentiating capability of your product, building may be more cost-effective; if it's just a nice-to-have feature, continuing to buy is usually wiser.

SSO implementation depends on several identity protocols, and understanding their differences helps assess integration effort. SAML 2.0 is the earliest XML-based authentication protocol widely adopted by enterprises, supported by mainstream IdPs like Okta and Azure AD, but it's cumbersome to configure and difficult to debug—a single attribute mapping error can cause login failures. OIDC (OpenID Connect) is built on OAuth 2.0, uses JSON and JWT, is more lightweight and easier to debug, and is gradually replacing SAML as the first choice for new projects. There are also older protocols like WS-Federation and CAS, still used by customers in some industries. Supporting each protocol or each IdP type means additional adaptation, testing, and documentation work—this is the technical root of the article's point that "each additional IdP type adds cost." So when selecting a vendor, don't just ask "do you support SSO"—ask "which protocols and which IdPs do you support."

Easily Overlooked Cost Dimensions

Beyond the vendor's direct quote, the following cost items are often missed in initial estimates:

Engineering integration time: SSO and SCIM integration is not one-time work. Each new customer's identity provider configuration, debugging, and launch can consume hours to days of engineering time.

Ongoing maintenance costs: Identity protocol version updates (such as the SAML-to-OIDC migration trend), security patches, and API changes in customers' own IdPs all require continuous investment.

Support ticket volume: Authentication issues are often the highest-priority and hardest-to-troubleshoot category in customer support. When enterprise customers experience SSO login failures, the impact is on the entire organization's access—these tickets cost far more than ordinary feature issues.

Compliance and audits: In certifications like SOC 2 and ISO 27001, identity management is a key audit area. Related documentation, processes, and external audit fees should all be factored into total cost.

SOC 2 and ISO 27001 are two common certifications for enterprise SaaS, and identity management is a key audit area in both. SOC 2 is developed by the AICPA, built around five trust service principles—security, availability, processing integrity, confidentiality, and privacy—with reports issued by independent auditors, typically updated annually. ISO 27001 is the International Organization for Standardization's ISMS (Information Security Management System) standard, requiring organizations to establish and continuously operate a complete set of security governance processes. Auditors focus on: whether access permissions follow the principle of least privilege, whether departed accounts are promptly revoked, whether privileged accounts have additional controls, and whether identity changes have traceable logs. This means you not only need to buy SSO/SCIM tools but also invest manpower in building supporting processes, retaining evidence, and cooperating with audits. Audit fees themselves can range from tens of thousands to hundreds of thousands of dollars, and increase with customer scale and compliance requirements—a classic hidden cost.

Build Your Own Cost Estimation Spreadsheet

Rather than relying on vendor pricing pages, build your own estimation framework. Include at least the following columns:

• Customer scale tiers: Estimate separately at the 5/25/100 nodes
• Vendor direct costs: Including base subscription, add-on modules, overage usage
• Integration engineering hours: Adaptation time per IdP type × engineering hourly rate
• Annual maintenance investment: Estimated as a percentage of initial integration cost
• Support cost allocation: Expected monthly tickets per customer and handling cost

Add these items up, and you'll find that "per-connection price" may account for far less of total cost than you expected. What really drives the bill are often the numbers that never appear on the vendor's website.

Vendor Selection Recommendations

When comparing SSO and SCIM vendors, ask for complete pricing details, not just the starting price. Specifically:

1. Clarify the billing unit definition of a "connection"
2. Ask whether SCIM is billed separately and whether there's a user cap
3. Understand tiered pricing beyond the package
4. Confirm whether technical support is included, and support response times
5. Ask about contract terms and renewal price adjustment mechanisms

The value of this worksheet isn't in precisely predicting future spending, but in helping you identify which vendors' pricing models best match your business growth curve. A solution that looks cheap at 5 customers could become the most expensive choice at 100 customers—and vice versa.

One-line Summary

SSO/SCIM selection can't rely on per-connection pricing alone—hidden costs are what determine the final bill.

Paragraph Summary

The article points out that when evaluating SSO and SCIM, companies most easily fall into the trap of comparing "per-connection prices," while what really drives the final bill are variables hidden behind the quote. The author recommends estimating costs across three scale tiers—5, 25, and 100 enterprise customers: at small scale, fixed costs (certificates, compliance, operations) dominate; at medium scale, you hit tiered pricing thresholds and face the complexity of multi-IdP adaptation; only at large scale do you have negotiating leverage and can re-evaluate "build vs. buy." Beyond direct costs, integration engineering time, ongoing maintenance, support ticket volume, and compliance audits are the four most easily overlooked cost categories. The article concludes with a vendor selection checklist, emphasizing the need to request complete pricing details and build your own cost estimation spreadsheet, incorporating both vendor fees and indirect investments into the comparison to identify whether pricing models match your growth curve.