Plenty of SaaS vendors only offer single sign-on on their most expensive plan. The practice is common enough that a public site, sso.tax, lists vendors that charge extra for SSO and argues that security shouldn't be a premium feature. Security-minded IT admins know it, and some will raise it on a call. If your own SSO sits on an enterprise tier and the buyer only learns that from the order form, the deal can go sour fast.

Treat SSO questions as two topics: login and provisioning. If you're working out how to answer SSO questions on your next call, start by finding out which of the two the admin means, and what your plan includes for each.

Login

SSO lets an employee sign in once through the company's identity provider (IdP), such as Okta, Microsoft Entra ID or Google Workspace, and reach other apps without a separate password. Your product is the service provider (SP).

Two standards cover most setups. SAML 2.0 is an XML-based OASIS standard (core specification). OpenID Connect is an identity layer on top of OAuth 2.0 (OpenID Connect Core). Enterprise IT teams often ask for SAML by name, so know whether you support it, OIDC, or both.

The setup itself is an exchange of details between the two sides. For SAML, your product gives the admin an Assertion Consumer Service (ACS) URL, where the IdP sends the signed login response, and an entity ID that identifies your app. The admin gives back their IdP's sign-in URL, its entity ID and a signing certificate, often bundled as a metadata XML file. When an admin asks "how long does setup take?", that exchange is what they're picturing. If your product has a setup guide for their IdP, send it in the recap; it answers most of their follow-ups before they ask.

Provisioning

Admins often care more about who gets an account than how they log in.

There are two common approaches. Just-in-time (JIT) provisioning creates a user account the first time someone signs in through SSO, using attributes from the SAML assertion. It's simple, but it does nothing when an employee leaves. SCIM, the System for Cross-domain Identity Management, lets the IdP push changes directly: a new hire gets an account, and a leaver gets deactivated. The protocol is defined in RFC 7644 and the user schema in RFC 7643.

The leaver case is what security teams worry about, since an account that outlives someone's employment is an obvious risk. So when an admin asks "do you support SCIM?", they're often asking whether deprovisioning is automatic. If your product offers JIT only, say so clearly and explain how admins remove users today.

Check which IdPs your SCIM integration has been tested with, and whether it's on the same plan as SSO. If you can't confirm either on the call, say you'll come back in writing with your SE's answer.

Expect the lockout question too: if the IdP goes down, how does the account owner get in? Admins assume a fallback login exists, and they'll want to know how it's protected.

Questions like that are usually the first sign a security review is coming, and our guide to SOC 2 questions for sales reps covers what buyers ask once it starts.

Packaging

Bring up pricing yourself, as soon as SSO is mentioned. If SSO and SCIM are on your enterprise plan, say so before the buyer builds a budget around a cheaper tier. If SCIM costs extra on top of SSO, say that too. A buyer who hears it on call two can plan for it; one who finds it in the order form will remember the sso.tax list and wonder what else you left out.