SSO and SCIM as Security Features: What Buyers Check and Why

NIST published SP 800-63B-4, the authentication volume of its Digital Identity Guidelines, in July 2025, and it supersedes the 2020 edition. Among its rules: email shall not be used for out-of-band authentication, and SMS or voice codes are allowed only under restrictions. Buyers who read that start asking vendors a simple question: can we put your product behind our own identity provider, and can we remove people automatically?

SSO and SCIM are the two features that answer it.

What's affected

SSO lets customers sign in to your product through their own identity provider, using SAML or OpenID Connect. The security value: the customer's MFA, password policy and conditional access apply to your product too, and a leaver loses access when their directory account is disabled.

SCIM is the System for Cross-domain Identity Management, defined in RFC 7643 (schema) and RFC 7644 (protocol), both from September 2015. It lets the customer's identity provider create, update and delete users in your product through a REST API. RFC 7644 defines the HTTP methods: POST to create, PUT or PATCH to modify, and DELETE to remove. The User schema in RFC 7643 includes an "active" attribute, a Boolean for the user's administrative status, which is how most providers disable a user without deleting them.

Without SCIM, a customer who removes an employee from their directory still has a live account in your product until someone remembers to delete it. That is exactly the gap access reviews and auditors look for.

How to check if you're exposed

Walk through what a customer security reviewer will test:

1. Can a customer enforce SSO and disable password login for their tenant?
2. Does a user disabled in the identity provider lose access, including active sessions and API tokens?
3. Is the SCIM endpoint authenticated? RFC 7644's security considerations say implementers should avoid basic authentication and combine it with other factors, and that bearer tokens may be used with TLS and a token framework such as OAuth 2.0.
4. Are SCIM requests rate limited and logged? The RFC recommends limiting how many requests a client may make in a period of time.
5. Does an admin in your product still have a local password that bypasses SSO?

Test item 2 yourself with a throwaway tenant.

What to do now

1. Support SAML 2.0 or OIDC, and let customers require it for their whole tenant.
2. Offer SCIM user provisioning and deprovisioning at minimum, and group mapping to roles if you can.
3. On deprovisioning, revoke sessions and tokens at once, not at next login.
4. Authenticate SCIM with a long random bearer token over TLS, scoped to one tenant, rotatable by the customer.
5. Log every provisioning event with actor, time and result, and make the log visible to the customer.
6. Document it in a short public page with the supported providers you have actually tested.

How to avoid this trap

The common trap is a half-built SSO that leaves a back door: local admin passwords, API keys that outlive the user, or invites that skip the identity provider. Remove those paths for SSO tenants.

If you do not support SCIM yet, do not say "yes". Say "SSO is supported via SAML. SCIM is planned for a stated quarter. Until then, customers can remove users in the admin console or through our API." That is a complete, honest answer.

Why it matters

Identity is where most customer security reviews end up. SSO moves your authentication policy to the customer, where they can enforce phishing-resistant methods. SCIM closes the leaver problem. Together they remove two of the most common audit findings for SaaS products: shared accounts and stale access.

They also help you. Fewer password resets, fewer orphaned accounts and a defensible answer to "how do customers control access to their own tenant".

Try it yourself

Create a test user in a sandbox tenant, sign in, then disable them in your test identity provider. Time how long the session survives. Anything over minutes is your real answer to questionnaire item 2.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
• RFC 7644, SCIM Protocol
• RFC 7643, SCIM Core Schema