Start with a scenario, because SCIM only makes sense once you feel the pain it removes. A company hires forty people in a quarter. Each new hire needs an account in fifteen tools. Someone in IT creates those accounts by hand, sets the right access in each one, and repeats it forty times. Then a few of those people leave, and the same someone has to remember every tool they touched and turn each account off before the person keeps a working login into company data. That manual list is where security quietly fails. SCIM exists to make that list disappear.
Before going further I want to be direct about one thing, and I will repeat it later so there is no confusion. wrxstack does not offer SCIM today. This post is an explainer written by the person who builds wrxstack, not a claim that wrxstack provides the feature. I write these guides because buyers ask me what SCIM is, and a plain answer is more useful than a sales pitch. Where wrxstack fits into this picture is a small and honest part near the end.
What the letters actually mean
SCIM stands for System for Cross-domain Identity Management. Ignore the mouthful and hold onto the word "management." SCIM is an open standard, defined in public specifications, that describes how one system can manage user records inside another system over an ordinary web connection. It defines a common shape for a user, a common shape for a group, and a small set of actions: create this user, update this user, deactivate this user, add this user to that group. Because the shape and the actions are standardized, any tool that speaks SCIM can be managed by any identity provider that speaks SCIM, without a custom integration built for each pair.
The two sides have names worth learning. The system that holds the master list of people is the identity provider, often shortened to IdP. The application receiving the instructions is the service provider. When your IdP tells a connected app to create an account, it is acting as the source of truth, and the app is doing what it is told. That direction matters, because it means the master list of who works here lives in one place, and every connected tool follows it rather than keeping its own separate copy that slowly drifts out of date.
Provisioning, deprovisioning, and the word that scares auditors
The full lifecycle has three moments, and each one maps to a real risk. Provisioning is account creation. When a person joins, or moves to a new team, the IdP tells each connected app to create the right account with the right group membership. Updating keeps that account accurate over time, so a promotion or a department change flows outward automatically instead of being retyped in fifteen places. Deprovisioning is the one that keeps security teams awake. When a person leaves, the IdP tells every connected app to switch their account off, at machine speed, without anyone having to remember which tools they used.
Deprovisioning is the reason SCIM is not a convenience feature. A former employee with a live login is one of the most common ways data walks out of a company, and it usually happens not through malice but through forgetting. Manual offboarding depends on a human recalling a full list under time pressure, and humans are bad at that. Automated deprovisioning removes the memory step. The moment the account is disabled in the IdP, the connected apps follow. This is the same instinct behind least privilege: the fewer standing doors into your data, the smaller the surface an attacker or an accident can use.
Directory sync is the same idea with a friendlier name
If you have shopped for enterprise software, you may have seen "directory sync" on a pricing page and SCIM in the technical documentation, and wondered whether they are two different things. In practice they usually name the same capability from two angles. SCIM is the protocol, the machine-level standard. Directory sync is the buyer-facing description of what that protocol delivers: your company directory, the list of people and their teams, stays in sync with the tool automatically. A directory such as one built on your IdP holds the people. Directory sync keeps the tool's copy matching it. Under the hood, that syncing is very often SCIM doing the work.
The reason the friendly name exists is that the people who buy software are rarely the people who implement the protocol. An IT leader wants to hear that onboarding and offboarding are handled and that the tool respects the company directory. The engineer setting it up wants to know which standard is spoken so they can wire it to the IdP. Both are describing one outcome. When you read a vendor's enterprise page, treat "directory sync," "user provisioning," and "SCIM" as close cousins and ask which specific actions are supported, because the depth varies between vendors even when the label is identical.
SSO is login. SCIM is the account. They are not the same.
This is the single most common confusion, and clearing it up is most of the value of this post. Single sign-on lets a person log in to an app using their central company identity, so they do not keep a separate password for every tool. SCIM decides whether that person has an account in the app at all, and what access it carries. One is about the door handle, the other is about who is on the building's roster. You can have either without the other, and many tools ship SSO long before they ship SCIM, which is exactly the position wrxstack is in.
Picture the gap this creates. A company uses SSO with a tool but not SCIM. An employee leaves. The IT team disables the person in the identity provider, which stops that person from logging in through the front door. Good. But the account still exists inside the tool, and if it also had a local password set before SSO was enforced, or if the tool allows a fallback login, the account can remain a live path into data. SCIM closes that gap by removing the account itself, not just the sign-on route. SSO governs entry. SCIM governs existence. A serious offboarding process wants both. You can read the companion explainer on what single sign-on is for the login half of the story.
| SSO | SCIM | |
|---|---|---|
| What it controls | How a person logs in | Whether the account exists and what it can access |
| The question it answers | Is this the right person, right now? | Should this person have an account here at all? |
| When it runs | Every time someone signs in | When people join, change roles, or leave |
| Main security win | One strong identity, fewer passwords | Instant offboarding, no orphaned accounts |
| If you only have this | Old accounts can linger after someone leaves | People still need a way to log in day to day |
| Common vendor label | SSO, SAML, OIDC | Directory sync, user provisioning |
Why it matters more as a company grows
At five people, none of this is worth the setup effort. You can onboard by hand and you will remember who left because you had lunch with them. The math changes with scale. Every new tool multiplies the manual work, and every new hire multiplies it again, so the cost of doing it by hand grows faster than headcount. Somewhere past a few dozen people across a dozen tools, manual provisioning stops being tedious and starts being a genuine risk, because the number of accounts nobody is tracking grows quietly in the background.
There is a compliance dimension too. Auditors do not simply ask whether you can turn off an account. They ask you to prove that former employees no longer have access, and to show how quickly access is removed after someone departs. Automated provisioning turns that from a nervous manual review into a repeatable process you can demonstrate. This is one of the concrete controls behind the badges people chase, and it is worth remembering, as I argue in a separate post on what a SOC 2 report proves, that the paperwork is a description of habits like this one, not a substitute for them.
What to ask a vendor before you trust the checkbox
Not all provisioning support is equal, so a checkmark on a feature grid is only the start. Ask which specific operations are covered. Create and deactivate is the baseline; full support also updates attributes and syncs group membership so that team changes flow through automatically. Ask which identity providers have been tested against, since a standard in theory can still be rough in practice with a particular IdP. Ask what happens to a user's data and their created work when their account is deactivated, because deactivation should suspend access without silently destroying records someone else may still need. The quality of these answers tells you how seriously a vendor has taken the account lifecycle, not just the login screen.
Where wrxstack honestly stands
Here is the plain statement I promised at the top, and I will not soften it. wrxstack does not offer SCIM or directory sync today. If your procurement process requires automated provisioning from your identity provider, wrxstack is not the right fit for that requirement right now, and I would rather tell you that here than let you find out after a demo. wrxstack is an AI work platform, not an identity or authentication vendor, and it would be dishonest to present it as one.
What wrxstack does offer on the identity side is single sign-on through standard protocols and an audit log that records who did what and when. Those cover login and accountability, which are real and useful, but they are not the same as SCIM, and I will not blur the line. If SCIM is on your must-have list, keep looking at tools built for it, and use this guide to ask them sharper questions. You can see exactly what wrxstack does and does not provide on the security page, which is written to the same honest standard as this post.
Does wrxstack support SCIM or directory sync?
No. wrxstack does not offer SCIM or directory sync today. It offers single sign-on and an audit log, which handle login and accountability but not automated account provisioning. If SCIM is a hard requirement for you, wrxstack is not a fit for that requirement right now.
What is the difference between SSO and SCIM?
SSO controls how a person logs in using a central identity. SCIM controls whether the person has an account in the app at all and what access it carries. SSO runs at every login; SCIM runs when people join, change roles, or leave. A strong offboarding process wants both.
Is directory sync the same as SCIM?
In most cases yes, described from two angles. SCIM is the technical standard. Directory sync is the buyer-facing name for keeping a tool's user list matched to your company directory, and that syncing is very often SCIM doing the work underneath.
Why do enterprise buyers care so much about deprovisioning?
Because a former employee with a live login is a common way data leaves a company, and manual offboarding depends on a human remembering every tool under time pressure. Automated deprovisioning removes that memory step and disables accounts the moment the person is switched off in the identity provider.