What enterprise buyers actually check before they'll sign off on your SSO

Every SaaS vendor claims SSO support on their pricing page. Fewer than half survive the procurement conversation without a follow-up call from the buyer's security team, asking why provisioning is manual, why there's no SCIM endpoint, or why the app treats "SSO" as a login button rather than an identity boundary. We've sat on both sides of that call. The pattern is consistent: teams bolt SSO onto an authentication system never designed to have an identity provider sitting in front of it, and the seams show up exactly when a $200k deal is on the line.

Enterprise buyers aren't asking if you have SSO

They're asking a specific set of questions, usually from a security questionnaire that's been through their compliance team, not from curiosity. The ones that actually block deals:

Does the IdP control account lifecycle, or does your app maintain its own shadow user table that drifts from the IdP's roster? If someone is terminated and deprovisioned in Okta on a Friday, does their session in your app die on Friday or does it quietly work until the JWT expires next Tuesday? Buyers with SOC 2 obligations of their own will fail their own audit if a vendor can't answer this cleanly.

Do you support SAML and OIDC, or only one? Mid-market buyers on Okta or Azure AD will often accept either. Larger enterprises with federated identity across acquisitions often need SAML specifically because that's what their legacy IdP speaks, and "we only do OIDC" reads as a maturity gap even when it's a reasonable engineering choice.

Do you support SCIM for provisioning and deprovisioning, or is onboarding a manual "send us a CSV" process? At 50 users, manual provisioning is an annoyance. At 2,000 users across a dozen business units, it's a compliance finding, and it's the most common gap between "SSO supported" marketing copy and what's actually shipped.

Can the customer rotate their own IdP metadata and signing certs without a support ticket that takes your team two weeks to action? Security teams rotate SAML certs on a schedule. If that requires you to manually update a config value in your admin panel, you've become a dependency in their compliance calendar, and that gets flagged.

The architecture mistakes that made this hard

Almost every painful retrofit traces back to one root cause: authentication and authorization got fused into a single user-identity model early, one that assumed exactly one login path.

The first mistake is storing a single password_hash column and treating SSO as an alternate path that skips the password check. This works for the demo. It breaks the moment a customer wants to require SSO for their org, because per-tenant login-method enforcement isn't in the schema. Fix this early: model identity as accounts with one or more linked authentication methods, not a user row with a password.

The second is conflating the identity provider's assertion with your application's session. Teams trust whatever attributes SAML hands back at login (email, groups, role) and never touch them again until the next login, sometimes weeks later. If a user's group membership changes in the IdP, your app doesn't know until they log out and back in, and most enterprise users never voluntarily log out. This is how a revoked "Admin" role stays live in your app for a month. The fix is short-lived sessions with a defined re-validation window, not indefinite trust in a token minted once.

The third, and the one that actually kills procurement timelines, is skipping SCIM because it looks like an SSO nice-to-have rather than infrastructure. SCIM is a separate lifecycle API from SSO login; you can ship OIDC login without it and plenty of teams do. But without it, every enterprise customer's IT team ends up managing your user list by hand, outside their identity system of record: exactly the shadow-IT problem their security policy exists to prevent. Build SCIM before you need it, because designing a provisioning API under deadline pressure while a customer's onboarding clock is running is a bad way to write software.

The fourth is treating "multi-tenant" and "multi-IdP" as the same problem. They aren't. A tenant might have one IdP today, but the architecture needs per-tenant IdP configuration, metadata URL, cert, attribute mapping, as first-class data, not environment variables or a global SAML config with a tenant ID smuggled into a custom attribute. We've inherited codebases where adding the second enterprise customer required a code deploy, because the first customer's settings were hardcoded.

None of this is exotic. It's ordinary identity architecture, done in the order that avoids a rewrite. The teams that get burned aren't the ones who chose OIDC over SAML; they're the ones who let a login button define the identity model before anyone in the room had seen an enterprise security questionnaire.