SAML Gets Them In, SCIM Gets Them Out: The Gap Teams Miss

SAML and OIDC are authentication protocols, they answer whether someone attempting to log in is who they claim to be, verified against the customer's own identity provider. Neither one, on its own, does anything about what happens after that person's employment or role changes at the customer's company.

SCIM is the piece that closes that gap, a provisioning protocol that lets an identity provider push user lifecycle events, someone added, someone removed, someone's group membership changed, into your application automatically. A lot of teams ship SAML for an enterprise deal and stop there, leaving the lifecycle side entirely manual.

Without SCIM, deprovisioning depends on someone at your company noticing that a customer's employee left and manually removing their access, a step that works fine the first few times and quietly stops happening as the number of enterprise customers grows past what anyone is tracking by hand.

That's precisely the gap a SOC 2 access review is designed to surface: can you show that access is removed promptly when someone leaves. An auditor asking for evidence of that control is a bad time to discover the answer is "usually, when someone remembers."

Okta, Microsoft Entra ID, and Google Workspace all implement SAML and SCIM slightly differently in practice, claims formatted differently, group sync behaving differently, edge cases in how a removed user actually gets reported. Testing against only the identity provider your own company happens to use leaves those differences undiscovered until a real enterprise customer's onboarding surfaces them.

Set up a free or trial account with a second major identity provider and run your SSO and SCIM flows against it before you're doing that debugging live during a customer's first week, when the pressure to get it working fast is much higher than it needs to be.

Checks worth running against Okta, Microsoft Entra ID, and Google Workspace:

• Compare how each provider formats claims, since small differences between them break assumptions that held for your own company's identity provider.
• Confirm group sync behaves the way your role mapping expects when someone's group membership changes.
• Test how a removed user is actually reported, because deprovisioning edge cases differ across providers and are the ones an access review looks for.
• Verify that a failed or malformed SCIM sync does not leave your user table quietly disagreeing with the identity provider.

A SCIM sync webhook that fails silently, a network blip, an unhandled error response, a malformed payload, leaves your user table and the identity provider's actual state drifting apart without either side knowing it happened. Someone removed at the identity provider still shows as active in your app, or someone added there never gets created in yours.

Treat the sync as something that can fail rather than something that always works, and build in a reconciliation check, comparing your table against the identity provider's current state periodically, as a backstop for exactly this kind of silent drift. Waiting for someone to notice the mismatch manually means it usually gets noticed during an audit instead of before one.

Building SAML and SCIM support yourself against the underlying specifications is a real option, and a real amount of ongoing work, keeping up with each identity provider's particular quirks, handling malformed or unexpected payloads gracefully, maintaining the mapping between their user model and yours.

A compliance platform like Vanta's access review feature can check that a user removed at the identity provider actually lost access in your app, instead of you finding the gap during an audit, and identity infrastructure tooling can absorb much of the provider-specific variance for you. The build-versus-buy call mostly comes down to how many enterprise customers you're supporting today against how much engineering time keeping this working correctly is worth, a question worth revisiting as that number changes. If you're evaluating compliance platforms more broadly, comparing a few options is a reasonable next step.