Enterprise-Ready SaaS in 2026: SSO, SCIM, Audit Logs and the SSO Tax

The first time a large customer sends a security questionnaire, most SaaS teams discover that "enterprise ready" is not a feature, it is a list. I have read enough of these questionnaires to know the list is surprisingly stable: single sign-on over SAML or OIDC, SCIM provisioning so leavers lose access the same day, audit logs the customer can export, role-based access control that maps to their org chart, and an answer to where the data lives. This post explains what each item really means for an enterprise-ready SaaS product in 2026, why SAML is still on the list, what CISA now says about charging for SSO, and what it costs to buy the plumbing from WorkOS, Auth0 or Clerk versus running Keycloak yourself. If you want the hands-on version, the companion Keycloak OIDC and SAML setup guide builds the self-hosted option step by step.

What does "enterprise ready" actually mean for a SaaS product?

Strip away vendor marketing and procurement asks five groups of questions. They come from the customer's IT team (who must operate your app alongside 200 others), their security team (who must prove access is controlled), and increasingly from government guidance that buyers now quote back at vendors. The EnterpriseReady checklist has said much the same for years; what changed is that buyers now treat these as table stakes rather than as reasons to upgrade.

Requirement	What the customer actually asks	Typical blocker if missing	Source
SSO (SAML 2.0 or OIDC)	"Can our employees log in through Okta or Entra ID, with no local passwords?"	Security review fails outright	CISA Secure by Demand
SCIM 2.0 provisioning	"When we fire someone, do they lose access automatically?"	Manual offboarding flagged as a control gap	RFC 7644
Audit logs	"Can we see who did what, export it, and keep it?"	Incident response cannot be evidenced	CISA Secure by Demand
RBAC	"Can we restrict billing and admin to named groups?"	Least-privilege requirement unmet	Customer security policy
Data residency	"Which region stores our data, and who are your subprocessors?"	Legal or regulatory veto	Customer DPA

None of this is exotic. It is the identity and accountability layer that a B2C product never needed and a B2B product cannot sell without. The multi-tenant SaaS architecture post covers the tenancy model these features sit on.

SAML vs OIDC: which SSO protocol should you support?

Both protocols do the same job: the customer's identity provider authenticates the user and hands your app a signed statement saying who they are. They differ in era and encoding. SAML 2.0 is an OASIS standard from 2005 that passes XML assertions through browser POSTs. OpenID Connect Core 1.0 sits on OAuth 2.0 and passes JSON Web Tokens, which every modern web framework, mobile SDK and API gateway already understands.

For your own application, implement OIDC. Libraries are better maintained, tokens are easy to inspect, and the same machinery covers APIs and machine clients. But you will still need SAML, because plenty of customers run IdP setups and app catalogues that were built around SAML and see no reason to change for you. The practical answer is to speak OIDC internally and let a broker (a managed service or Keycloak) translate whatever the customer brings.

The reason not to hand-roll SAML is XML signature validation. In March 2025, GitHub Security Lab disclosed CVE-2025-25291 and CVE-2025-25292 in ruby-saml, where two XML parsers disagreed about the same document. An attacker holding one valid signature from an organisation could forge assertions and log in as any user. That bug lived in a widely used library maintained by people who know SAML well. Your weekend implementation will not do better.

What is SCIM provisioning and why do customers insist on it?

SSO answers "who is this person right now". It does not answer "should this account still exist". If a customer's employee leaves and their IdP account is disabled, they can no longer log in through SSO, but their account in your app, their API tokens and their ownership of resources live on. SCIM (System for Cross-domain Identity Management) closes that gap. The customer's directory pushes creates, updates and deactivations to a REST API you expose, defined by RFC 7643 for the schema and RFC 7644 for the protocol, both from 2015.

A SCIM create request from Okta or Entra ID looks like this, and your endpoint has to accept it, return the stored resource, and handle the later PATCH that sets active to false:

# POST https://auth.example.com/realms/acme/scim/v2/Users   (SCIM 2.0, RFC 7643/7644)
# Authorization: Bearer <token issued to the customer's directory, scoped to one tenant>
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "j.doe@globex.example",
  "externalId": "00u1a2b3c4",
  "name": { "givenName": "Jane", "familyName": "Doe" },
  "emails": [{ "value": "j.doe@globex.example", "primary": true }],
  "active": true
}
# Later, on offboarding, the directory sends:
# PATCH /Users/<id>  {"Operations":[{"op":"replace","value":{"active":false}}], ...}
# Your app must then revoke sessions, refresh tokens and API keys for that user.

The alternative many startups ship first is just-in-time (JIT) provisioning: create the account on first SSO login. JIT is fine for onboarding and useless for offboarding, which is the part auditors care about. SCIM also matters more now that non-human accounts multiply; the non-human identity post covers why agent credentials need the same lifecycle discipline as people.

Self-hosted options caught up this year. Keycloak promoted its SCIM API from preview to supported in 26.8.0 on 1 October 2026, then shipped several SCIM permission fixes in that same release. That is a good reminder that SCIM endpoints are an authorisation surface, not just a sync feature.

What should SaaS audit logs include?

Audit logs are where many products quietly fail review. The customer does not want your debug logs. They want an append-only record of security-relevant events in their tenant: logins and failures, SSO configuration changes, role grants, API key creation, data exports, deletions, and admin impersonation, each with actor, target, timestamp, source IP and outcome. They want to query it in your UI, export it, and ideally stream it into their SIEM.

The bar has a number on it now. The CISA and FBI Secure by Demand guide (August 2024) says SaaS providers should retain security logs and make them available to customers for at least six months at no additional charge, in the baseline version of the product. Buyers quote that line. If your plan tiers keep 7 days of logs on the cheap tier, expect the question.

Two design choices save pain later. First, make actors explicit types (user, service account, API key, agent acting for a user) rather than a free-text string, because "who did this" is the first incident question. Second, write audit events in the same transaction as the change, or through an outbox, so a crash cannot produce a change with no record.

RBAC and data residency: the questions after SSO

Once SSO is in, the next round of questions is about authorisation. Customers want roles they can map to IdP groups (so "Finance" in Entra ID becomes "billing admin" in your app automatically), the ability to restrict admin actions to a few people, and preferably custom roles. Shipping three fixed roles (owner, admin, member) with group mapping covers most early deals. Fine-grained, resource-level permissions can wait until a customer's requirements actually justify them.

Data residency is less about code and more about deployment. The question is usually "which region holds our data, which subprocessors touch it, and can you keep it in the EU". If your architecture already supports a separate cell or region per tenant group, the answer is a configuration choice. If everything lives in one US database, the honest answer is a roadmap item, and you should say so rather than improvise. Note that your identity provider is part of the answer: a hosted auth vendor storing user profiles in another region is a subprocessor the customer will ask about.

The SSO tax: is charging for SSO still defensible?

The "SSO tax" is the practice of putting SSO only on an enterprise tier priced far above the base plan. The sso.tax wall of shame has tracked it for years, and its listed examples are stark, though several entries are dated, so check the vendor's current pricing before you quote them.

The vendor argument is real: enterprise customers cost more to support, SSO tickets are fiddly, and SSO is a reliable signal that a customer has budget. The counter-argument got official backing. CISA's 2024 report on barriers to SSO adoption for small and medium businesses (dated May 2024) found that SSO is often available only as a premium enterprise service with custom pricing and minimum seat counts, and named that cost as a key barrier for smaller organisations. The Secure by Demand guide then told buyers to ask whether a vendor supports standards-based SSO "at no additional cost".

My view: gate the expensive parts, not the security baseline. Charge for SCIM at scale, custom roles, extended log retention, dedicated regions, or premium support. Do not make a 40-person customer buy an enterprise contract to stop using passwords. It is a worse security outcome, and it is increasingly a question on the questionnaire itself.

Build vs buy SSO: WorkOS vs Auth0 vs Clerk vs Keycloak

Building SAML, OIDC brokering, SCIM and audit streaming yourself from libraries is a large project, followed by permanent ownership of the CVE feed. Most teams should buy or self-host a proven server. Here is what the options cost as listed on 31 October 2026:

Option	Entry price	Enterprise SSO	SCIM / directory sync	Audit logs	Source
WorkOS	AuthKit free to 1M MAU	$125 per connection (1 to 15), down to $65 (51 to 100)	Same tiers as SSO	$125/mo per SIEM stream; $99/mo per 1M events retained	WorkOS pricing
Auth0	Free to 25,000 MAU, 1 enterprise connection	B2B Essentials $150/mo at 500 MAU (3 connections); Professional $800/mo (5)	Inbound SCIM on all plans	Log retention 1, 5, 10 or 30 days by plan	Auth0 pricing
Clerk	Pro $25/mo, 50,000 MRU included	1 connection included, then $75/mo each (2 to 15)	Pro and Business, billing starts 1 Jan 2027	Admin logs on Business only, 30 days	Clerk pricing
Keycloak 26.8	$0 licence (Apache-2.0)	Unlimited OIDC and SAML brokers	SCIM API supported since 26.8.0	Login and admin events; you build retention	Keycloak 26.8.0 notes

Per-connection pricing (WorkOS, Clerk) tracks the number of enterprise customers, which maps neatly to revenue. Per-MAU pricing (Auth0) gets expensive for products with many users per customer. Keycloak moves the cost to operations: PostgreSQL, two or more instances, upgrades, and a security patch cadence that is not optional. The 26.8.1 release alone fixed more than a dozen CVEs, including privilege escalation through fine-grained admin permissions. Self-hosting is a good choice when you need data to stay in your own regions, have many enterprise customers, or already run stateful services well. It is a poor choice for a three-person team without on-call.

Whichever you pick, keep your app's integration on plain OIDC. That keeps migration between these options to a configuration change and a user re-link, instead of a rewrite.

FAQ

What is the difference between SSO and SCIM?

SSO handles authentication: proving who a user is at login, via SAML or OIDC. SCIM handles lifecycle: creating, updating and deactivating accounts in your app when the customer's directory changes. You need both, because SSO alone leaves accounts and API tokens alive after an employee leaves.

Should a B2B SaaS support SAML or OIDC first?

Build your app on OIDC, then add SAML through a broker or managed provider before your first enterprise deal. Customers choose the protocol based on their IdP setup, not your preference. Avoid writing SAML signature validation yourself.

How long should SaaS audit logs be retained?

CISA's Secure by Demand guide sets the reference point at six months, available to customers at no extra charge. Many enterprise contracts ask for a year or more, often satisfied by streaming events to the customer's SIEM. Retention beyond the baseline is a reasonable paid add-on.

Is charging extra for SSO bad practice?

It is legal and common, but CISA now explicitly tells buyers to ask for standards-based SSO at no additional cost, and its research links the SSO tax to weaker security at small companies. A defensible model includes basic SSO on business plans and charges for SCIM scale, custom roles and extended log retention.

If I were making a B2B product enterprise ready this quarter, I would ship OIDC login through a broker in week one, add SAML and SCIM through the same broker before chasing the first large customer, and design the audit event table, with typed actors and six months of retention, before writing the second admin feature. Then I would put SSO on the business plan and spend the pricing creativity on things that actually cost me money to run.

Related: Multi-Tenant SaaS Architecture Explained: Silo, Pool, Bridge, Cells (2026), Who Is This Agent? Non-Human Identity in 2026, From the RFCs to the Breaches and MCP Authorization Explained: OAuth 2.1, RFC 9728 and CIMD in 2026.