Single sign-on and SCIM solve different problems. SSO helps a person authenticate to an application through an identity provider. SCIM helps systems create, update, and manage user accounts and related information. A product can offer one without fully solving the other.
For HR, the difference matters when somebody joins, changes role, or leaves. Being able to sign in with a familiar account does not tell you how that account was created, which permissions it has, or how quickly access will change after an employment update.
Separate the three questions
Ask who the person is, whether an account exists, and what the account is allowed to do. Authentication, provisioning, and authorization are related, but they are not interchangeable.
Microsoft’s single sign-on overview describes SSO as a way to use one set of credentials to access applications. Its SCIM provisioning documentation describes a standardized approach to managing users and groups between systems. The distinction is more useful than treating either acronym as a general security badge.
| Question | Typical area | What to verify |
|---|---|---|
| How does the person sign in? | SSO and authentication | Supported identity provider, login paths, and recovery |
| How is the account created or changed? | Provisioning, which may use SCIM | Source, identifiers, mappings, timing, and failures |
| What can the person see or do? | Application authorization | Roles, record scope, exports, and delegated access |
| How does access end? | Provisioning plus application behavior | Disablement, active sessions, local accounts, and exceptions |
The last row often needs the most attention. Disabling a directory account and removing every possible route into an application are not necessarily the same event.
Draw the employee journey
Start with the HR record. Which system decides that someone is an employee, what their start date is, and who manages them? Follow that information to the identity service and then to the application. Record which changes travel automatically and which require a person.
A new hire may need an account before their employment start date so they can complete selected onboarding tasks. An employee who moves departments may need new access and removal of old access. A person leaving may need work access removed while retaining a controlled route to appropriate employment documents.
These are policy and service decisions first. The technical configuration should implement them. Use the HRIS integrations guide to agree sources, ownership, and the direction of each data flow before asking IT to connect everything.
Ask what the connector actually supports
“SCIM supported” is the beginning of the conversation. Ask which user attributes, groups, and lifecycle operations are supported in the proposed connection. Check how the application matches an incoming person to an existing account and how it handles changes to names or email addresses.
Try a rehire, two people with the same name, a missing manager, and an employee with multiple assignments. Find out what happens when a required value is missing. Does the account fail visibly, arrive with a default role, or enter an exception queue?
Ask about timing. A scheduled synchronization, an event-triggered change, and an immediate manual action have different operating characteristics. Agree how urgent access changes will be handled if the normal connection is delayed.
Test the routes around the main login
Check whether local passwords remain available, whether there are privileged accounts outside the normal identity flow, and how mobile sessions behave. Ask IT and the supplier to explain token and session handling for the specific application rather than assuming a directory change closes every session instantly.
Include support and administrator access in the review. A service account used by an integration is not an employee account, but it may have broad access to employee data. Give it a clear purpose, appropriate permissions, and a responsible owner.
The offboarding automation guide is useful here: record the actual access change, not only the request asking somebody to make it. Keep a way to identify failures and resolve them promptly.
Plan for failures and recovery
What happens if the HR feed stops, a mapping changes, or the application rejects an update? Ask to see the error reporting and the process for retrying safely. A dashboard that says “connected” can coexist with individual employee failures.
Test whether a retry creates duplicates or overwrites a deliberate correction. Agree which team investigates first and what information they need. Avoid a support arrangement in which HR, IT, and the supplier can each point to a different successful step while the employee remains locked out.
For new starters, connect these checks to the onboarding workflow. The employee’s experience is the result of the whole chain: a correct record, a correctly provisioned account, a usable login, and appropriate access. Buying SSO or SCIM as a checkbox will not, by itself, deliver that result.
