SSO and SCIM are often discussed together, which makes it easy to assume they're solving the same problem. They're not. Understanding what each one actually does — and where one stops and the other starts — is the key to understanding why SCIM exists even when SSO is already working. The simplest framing: SSO is about authentication. SCIM is about provisioning. Those sound similar but they're structurally different problems, and conflating them is what produces the confusion in most "why do I need SCIM if I have SSO?" questions.

What Does SSO Actually Do? SSO handles the login handshake. When you authenticate to Azure AD and get redirected to an application, the IdP is performing one specific function: verifying that you are who you say you are and signaling that to the application. The application receives a token — a SAML assertion or an OIDC ID token — that contains claims about the user currently logging in: their identity, their email, maybe their group membership. That token is all the application knows about you at the moment you log in. It's scoped to the current session, for the current user. The application receives it, validates it, and lets you in. This works well for the login moment. It doesn't solve anything that happens before or after that moment.

Where SSO Falls Short The "Leaver" Problem This is the most significant gap, and it's worth understanding precisely. When you deactivate a user in Azure AD, you've locked the front door. You've revoked their ability to complete an SSO authentication. But the user's account, data, and permissions still exist inside the application itself. If the application supports alternative login methods — a local password set before SSO was configured, an API token, a persistent session — the deactivated Azure AD account doesn't protect against those vectors. The local application account still exists. The data it has access to is still accessible. SCIM closes this gap. When a user is marked inactive in the IdP, a SCIM signal fires to the application instructing it to suspend or delete the local account. The deprovisioning happens at both layers — the front door and the room inside. Without SCIM, deprovisioning via SSO alone is incomplete by design. Just-in-Time Provisioning vs. Pre-Provisioning SSO typically operates on a just-in-time (JIT) model: the user's application account is created the first time they successfully authenticate. Until that first login, the application doesn't know the user exists. This creates a practical problem for day-one access. If a new employee needs a specific license tier, a specific role, and access to specific resources waiting for them on their first day — those can't be configured in advance through SSO alone, because the account doesn't exist in the application until the employee clicks the login button. SCIM enables pre-provisioning: the IdP pushes the user record to the application before any login occurs. The account exists, the license is assigned, the role is configured. On day one, the employee's environment is ready when they arrive rather than being created reactively when they first attempt to log in. Directory Awareness OIDC tokens and SAML assertions are user-scoped. The token contains information about the person currently authenticating — not about anyone else in the organization. When an application needs organizational context beyond the current user — an org chart, a list of colleagues to mention in a document, a searchable employee directory — the login token can't provide it. Applications that are "directory-aware" in this sense — Slack showing you a list of teammates to add to a channel, Zoom populating your contacts list, a project management tool letting you assign tasks to colleagues who haven't yet logged in — need to know about users who haven't authenticated yet. SCIM replicates the relevant portion of the user directory into the application so that organizational context exists independently of individual login events.

Why Do Some Applications Use SCIM and Others Don't? The variation you've noticed — some applications syncing user data from Azure and others just logging users in without replication — comes down to three factors. Technical implementation. SCIM is a more complex protocol to implement than basic SAML or OIDC SSO. Many legacy applications and smaller vendors support SAML SSO because the authentication standard is well-established and implementation is relatively straightforward. SCIM support requires building a provisioning API that receives and processes lifecycle events — a more substantial development investment that many vendors haven't made. Licensing tier. A significant number of SaaS vendors treat SCIM provisioning as an enterprise feature, gating it behind higher-tier subscription plans. Organizations on standard or professional tiers may have SSO available but not SCIM, which means they can authenticate users but not automate provisioning and deprovisioning. This is why the same application might appear to replicate user data for one customer and not another. Application architecture. Some applications are stateless — they don't maintain user profiles, internal permission structures, or application-specific data. For these, the login token carries everything the application needs for the session, and there's no persistent user record to create or manage. For stateless applications, SSO alone is sufficient because there's no provisioning layer to automate.

The Practical Implication for Identity Governance The SSO/SCIM distinction has a direct implication for how organizations think about offboarding and access governance. An identity stack that relies solely on SSO for access control is structurally incomplete: it governs authentication but not the application-layer accounts that exist independently of authentication. This is why identity governance platforms — tools that sit above the IdP layer and manage the full lifecycle across both SSO-connected and non-SSO applications — exist as a distinct category. They're addressing the gap between "the user can't log in via SSO" and "the user's access has been fully revoked across all systems." For applications without SCIM support, that gap requires either alternative integration approaches (direct API connectors, browser-based automation, structured manual tasks) or compensating controls that surface and remediate the gap continuously. For organizations managing compliance requirements, the practical test is: when an employee leaves today, can you prove that their access was revoked in every application, not just the ones behind SSO? SCIM-enabled applications can answer that automatically. Applications without SCIM support require something else to close the loop — and knowing which category each application falls into is the starting point for building controls that actually work.

Summary: SSO vs. SCIM The relationship between the two is complementary rather than redundant. SSO handles the authentication layer — the front door. SCIM handles the provisioning layer — creating, updating, and removing the user's presence inside the application. For applications that are directory-aware, SCIM also handles organizational context that login tokens can't carry. Some applications need both. Some need only SSO. Some need neither if they're fully stateless. The right question to ask for each application in your environment isn't "do we have SSO?" but "what happens to this user's access when they leave — and can we prove it?"