Buyers asking for SSO want their staff to sign in to your product through their own identity provider. SCIM adds automatic creation and removal of accounts. Together they let a customer enforce their login rules and revoke access in one place when someone leaves.
The terms, defined
- SSO (single sign-on). Users authenticate at the customer's identity provider and your app trusts that result. Common protocols are SAML and OpenID Connect.
- MFA enforcement. The customer's identity provider requires a second factor, or your app does. Buyers often want to control this centrally, not per product.
- SCIM (System for Cross-domain Identity Management). An HTTP based protocol for managing identities across domains. RFC 7644 describes it as a standardized service that makes identity management easier to support, with enterprise to cloud service provider scenarios given as an example.
- Just in time provisioning. The account is created at first SSO login. Easier to build than SCIM but does not handle removal well.
- Role mapping. Groups at the identity provider map to roles in your product.
What buyers are really protecting against
The business reason is leaver risk. When an employee departs, the customer disables their directory account. If your product keeps its own passwords, that person may still have access until someone remembers to delete the account. SSO closes the login path. SCIM closes the stale account itself, and deactivates tokens tied to it.
The buyer's second concern is consistent policy. Password rules, session length, and MFA are set once, centrally, and every connected app inherits them.
A practical support ladder
Vendors rarely ship everything at once. This order tends to match buyer demand:
- SSO with one protocol, with the option to require it for all users of a tenant.
- Disable password login for tenants that turn on SSO, with a documented break glass path for admins.
- Role mapping from identity provider groups.
- SCIM for user and group provisioning and deprovisioning.
- Audit logs for sign-in, role changes and admin actions, exportable by the customer.
Be careful with API tokens and service accounts. They sit outside SSO and are a common leftover path. Document how a customer can list, scope and revoke them.
How to answer the questionnaire line
Answer by capability, not by label. For example: "SSO via SAML 2.0 and OpenID Connect; enforcement is configurable per tenant; SCIM 2.0 provisioning and deprovisioning supported; admin audit log exportable." If a piece is not built, say so and state the plan. The post on yes, no, or partial: how to choose questionnaire answers helps with the middle cases.
Pricing and packaging
Many vendors package identity features at a higher plan. That is a commercial decision. Whether to do it is discussed in should SaaS startups charge extra for SSO and audit logs.
Test the leaver path
Before a buyer does, run this test: create a user through SCIM, assign a role, disable them at the identity provider, and confirm access ends within the time you state. Check that sessions and API tokens end too, or document what remains.
For authentication assurance concepts beyond the product login, NIST's digital identity guidelines describe authenticator assurance levels, though they are written for federal systems and are not a requirement for commercial SaaS.
Safeguard's agent identity capability applies the same idea to AI agents, giving each its own identity so access can be scoped and revoked.
Quick check
Is SAML SSO enough, or do buyers expect SCIM too?
Many buyers accept SSO first, but larger ones ask for SCIM because it handles removal of accounts automatically. Ask which they expect in the deal.
What is a break glass account?
An emergency admin login that works if the customer's identity provider is down. Keep it limited, logged and protected with strong credentials.
Sources
- IETF, RFC 7644, System for Cross-domain Identity Management: Protocol
- NIST, SP 800-63B, Digital Identity Guidelines
Last reviewed: 19 October 2026.
