Enterprise SSO in B2B SaaS: when to build it before a customer asks

A prospect goes quiet after a demo that went well. A week later, their IT or security team sends a questionnaire. One line near the top asks whether your product supports SAML single sign-on. If the answer is no, the deal often does not die outright, but it stalls, gets pushed to “next quarter”, or gets quietly reassigned to a competitor that answered yes. For a small software team building a B2B product, this is usually the first time single sign-on stops being a nice-to-have and becomes a commercial blocker.

The question worth asking early is not “do we need SSO?” but “when do we need it, and what does building it in now versus later actually cost us?” Those are engineering questions with a real answer, not a sales question to defer indefinitely.

What “enterprise SSO” actually covers

The phrase gets used loosely, so it helps to separate the pieces a security review is actually checking for:

SAML 2.0 — the older but still dominant protocol for enterprise identity providers (Okta, Azure AD/Entra, OneLogin, Ping). Most enterprise buyers assume this exists.

OIDC (OpenID Connect) — a newer, simpler protocol built on OAuth2. Increasingly preferred by identity providers and easier to implement than SAML, but not yet a universal substitute in procurement checklists.

SCIM provisioning — automated user creation and deactivation from the customer’s identity provider, so their IT team does not manually manage accounts in your product. This tends to matter once a customer has more than a handful of seats.

Just-in-time provisioning — creating an account automatically on first SSO login, without SCIM, which covers a good portion of what customers actually want with less engineering effort.

These are not one feature. A product can reasonably support SAML with just-in-time provisioning and defer SCIM until a customer’s headcount and turnover make manual account management genuinely painful for them.

The signal that actually matters

Company size is a weak proxy. A twelve-person startup with a security-conscious founder can ask for SAML on day one; a three-hundred-person company with a lax IT function might never ask. The reliable signal is who is in the buying conversation. If procurement, IT or a security team reviews the purchase before it closes, SSO support is likely to come up regardless of the buyer’s headcount. If the buyer is a single department head with a card and no procurement process, it usually will not.

For a product still selling mostly to individual teams or smaller companies, building SSO speculatively is often the wrong call — it is real engineering time spent on a feature most current customers will never touch. The moment the pipeline includes companies with a formal security review step, or the sales team can point to a specific deal stalled on this exact question, the calculation flips.

Why retrofitting costs more than building it in

This is the part that catches teams out. SSO is not a login button you add later; it touches assumptions baked into the rest of the system:

Identity model. If a user’s identity has always been “one row in a users table with an email and password hash”, introducing a second authentication path means deciding how SSO-authenticated users map to existing accounts — including the case where someone already signed up with a password using their work email before their company turned SSO on.

Session and permission assumptions. Code that assumes every session originated from your own login form (for password resets, email verification flows, or account recovery) needs auditing once a session can also originate from a third-party identity provider.

Multi-tenancy boundaries. SSO is configured per customer organisation, not per user. If the product’s data model does not already have a clean concept of “organisation” as a first-class entity, SSO configuration forces that modelling work to happen under deadline pressure from a live deal, rather than deliberately.

Enforcement, not just support. Enterprise buyers frequently want to mandate SSO for their organisation and block password login entirely. That is a different, stricter requirement than simply offering SSO as an option, and it needs its own migration path for existing users.

None of this is a reason to build SSO before it is needed. It is a reason to keep the organisation and permissions model clean from early on, so that adding SSO later is a contained piece of work rather than a rewrite of the auth layer under a signed contract’s deadline.

Build it, or buy it

Rolling SAML support from scratch is one of the less appealing ways to spend engineering time in a small team. The protocol is XML-based, fiddly to test against real identity providers, and the failure modes (clock skew, certificate rotation, subtly malformed assertions) are the kind that surface once with an enterprise customer’s IT team on the call, not in your own testing.

Third-party identity platforms exist specifically to absorb this work — you integrate once against their API and they handle the protocol-level detail against Okta, Entra, Google Workspace and the rest. The trade-off is a recurring cost, usually priced per organisation or per active connection, which needs to be weighed against the deal size it unlocks. For a product selling five-figure annual contracts to mid-sized companies, that cost is trivial next to what a stalled deal represents. For a product with a lower average contract value, the same recurring fee can erode the margin on exactly the customers it was meant to win.

There is also a well-known pattern worth being deliberate about rather than copying by default: charging a steep premium for SSO as a separate add-on tier. It is common enough in the market that enterprise buyers expect it and rarely push back, but it is a pricing decision, not an engineering one — worth making on purpose rather than inheriting from whichever identity platform’s default packaging you land on.

A decision checklist

Before committing engineering time to enterprise SSO, it is worth being able to answer these:

Has a specific, named deal actually stalled on this, or is it a guess about what enterprise buyers might want?

Does the product’s data model already treat “organisation” as a distinct entity from “user”, separate from billing?

Do existing users sign up with a personal login flow that would need a defined path to merge with an SSO identity later?

Is the realistic near-term need SAML with just-in-time provisioning, or does the pipeline already include large, high-turnover customers that will ask for SCIM too?

At the contract values currently being sold, does a per-connection fee from a third-party identity platform make sense, or does the volume justify building SAML support directly?

Will SSO be optional per customer, or does at least one prospect require enforcing it and blocking password login entirely?

Answering these honestly usually points to a clear next step — either the deal pipeline does not yet justify the work, or there is a specific, scoped piece of engineering to schedule, rather than an open-ended “add enterprise features” line item that never gets prioritised against everything else competing for the same sprint.