> ## Documentation Index > Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt > Use this file to discover all available pages before exploring further. # Living Security SCIM > How Living Security SCIM creates, updates and deactivates people from your identity provider, how it differs from SSO, and where your data is stored. > [!NOTE] > > **Which SCIM setup applies to you?** These pages describe **Living Security SCIM**. Open the SCIM card in your settings. If the card shows **Set up SCIM**, or its **Mode** row says **Native SCIM**, these pages apply. If **Mode** says **Current SCIM**, your organization still uses the earlier SCIM setup. An admin can move it: see [Move from the earlier SCIM setup](https://docs.livingsecurity.com/features/settings/scim/connection.md#move-from-the-earlier-scim-setup). If the card says SCIM is set up and managed in the setup wizard, use [SCIM Provisioning](https://docs.livingsecurity.com/features/settings/scim.md). > [!NOTE] > > Don't see Living Security SCIM? It's rolling out gradually. Contact your account manager to request access. Living Security SCIM connects your identity provider (IdP), such as Microsoft Entra ID or Okta, to the Living Security Platform. Your IdP creates, updates, deactivates and deletes people and groups through the SCIM 2.0 standard (RFC 7643 and RFC 7644). You do not import or edit those people by hand. ## What SCIM does * **Creates people.** When you assign a person to the Living Security app in your IdP, the person appears in **Workforce → People**. * **Keeps profiles current.** Name, title, department, manager and the other mapped attributes follow your directory. * **Removes access.** When your IdP deactivates or deletes a person, their access ends at once. * **Sends groups.** Groups your IdP pushes become directory groups that you can use in cohorts. See [Groups and cohorts](https://docs.livingsecurity.com/features/settings/scim/groups.md). ## SCIM, SSO and just-in-time sign-in | | What it does | When it runs | | - | - | - | | **SCIM** | Creates and maintains the person's account and profile. | When your IdP pushes a change, before the person signs in. | | **SSO** | Signs the person in with your IdP. | Each time the person signs in. | | **Just-in-time (JIT) sign-in** | Creates an account at the first SSO sign-in. | Only at sign-in. It does not update or remove anyone. | SCIM and SSO are separate. You can use SCIM without SSO: people then sign in with their email address. When you use both, the person's SCIM `userName` and the NameID your SSO sends must be the same value, the person's email address. See [SSO, multiple connections and sub-organizations](https://docs.livingsecurity.com/features/settings/scim/sso-and-sub-organizations.md). ## How a change flows 1. Your IdP sends a SCIM request to your organization's regional base URL with its token. 2. Living Security checks the token, the request and the limits, saves the change, and answers your IdP at once. 3. Living Security applies the change to the person in **Workforce → People** and to their sign-in account, usually within a minute. When your IdP sends many changes at once, this can take a few minutes. A deactivation or delete applies to the person in the same request, so their Living Security access ends at once. 4. If a policy stops a change, for example because it would remove your last owner, the IdP still gets a success response. The change is held and shows on the SCIM card. See [Held changes](https://docs.livingsecurity.com/features/settings/scim/user-lifecycle.md#held-changes). ## Regional base URLs Each organization has one data residency region, chosen when the organization is created. The SCIM base URL belongs to that region: | Region | SCIM base URL | | - | - | | United States | `https://api.us-east-1.livingsecurity.ai/scim/v2` | | European Union | `https://api.eu-west-1.livingsecurity.ai/scim/v2` | | Asia Pacific | `https://api.ap-south-1.livingsecurity.ai/scim/v2` | | Australia | `https://api.ap-south-2.livingsecurity.ai/scim/v2` | Copy the base URL from the SCIM card. A token sent to another region's URL is refused with `401`. The response does not say which region is correct. ## What is stored where | Data | Where it is kept | | - | - | | Every attribute your IdP sends for users and groups | Living Security, in your organization's region. Living Security returns each resource as your IdP sent it. | | The person's profile in **Workforce → People** | Living Security, built from the SCIM attributes it reads. | | The person's sign-in account | The sign-in service receives only a login identifier, the primary email, your organization and whether the account is enabled. It does not receive names, phone numbers, roles, groups or other attributes. | | A record of each SCIM request | Living Security, for 30 days. Passwords and secrets are removed first. | Living Security never stores a `password` your IdP sends. It discards the value. SCIM `roles` and `entitlements` are stored but never grant access in Living Security. ## Organizations that already use SCIM When you set up SCIM in an organization that has no SCIM connection, it uses Living Security SCIM. An organization that already provisions people through the earlier SCIM setup can move itself: an admin selects **Set up SCIM** on the SCIM card. Living Security first copies your current SCIM users and groups, and keeps the user and group IDs your IdP has stored, so you do not assign people again. People keep their accounts and sign in the same way. The earlier connection turns off automatically at the first change your IdP sends with the new token. See [Move from the earlier SCIM setup](https://docs.livingsecurity.com/features/settings/scim/connection.md#move-from-the-earlier-scim-setup). ## Next steps * [Set up a connection](https://docs.livingsecurity.com/features/settings/scim/connection.md): Create the token, share a setup link, rotate and revoke. * [User lifecycle](https://docs.livingsecurity.com/features/settings/scim/user-lifecycle.md): What happens on create, update, deactivate and delete. * [Groups and cohorts](https://docs.livingsecurity.com/features/settings/scim/groups.md): Use the groups your IdP sends. * [SSO and sub-organizations](https://docs.livingsecurity.com/features/settings/scim/sso-and-sub-organizations.md): How SCIM people sign in, and parent and sub-organizations. * [Security and best practices](https://docs.livingsecurity.com/features/settings/scim/security.md): Protect the token and roll out safely. * [Attribute reference](https://docs.livingsecurity.com/features/settings/scim/attributes.md): Every attribute, what it updates on the person, and how to map it. * [Test your SCIM setup](https://docs.livingsecurity.com/features/settings/scim/testing.md): The checklist, one test user, the dry run and the mapping check. * [API reference and limits](https://docs.livingsecurity.com/features/settings/scim/api-reference.md): Endpoints, filters, pagination, PATCH, Bulk and rate limits. * [Set up Microsoft Entra ID](https://docs.livingsecurity.com/features/settings/scim-microsoft-entra-id.md): Step-by-step Entra ID guide. * [Set up Okta](https://docs.livingsecurity.com/features/settings/scim-okta.md): Step-by-step Okta guide. * Other identity providers: [OneLogin](https://docs.livingsecurity.com/features/settings/scim-onelogin.md), [JumpCloud](https://docs.livingsecurity.com/features/settings/scim-jumpcloud.md), [PingOne and PingFederate](https://docs.livingsecurity.com/features/settings/scim-ping.md), [SailPoint](https://docs.livingsecurity.com/features/settings/scim-sailpoint.md), [Google Workspace](https://docs.livingsecurity.com/features/settings/scim-google-workspace.md), and [any other SCIM 2.0 client](https://docs.livingsecurity.com/features/settings/scim-generic.md). ## Related topics - [SCIM security and best practices](https://docs.livingsecurity.com/features/settings/scim/security.md) - [SCIM and Google Workspace](https://docs.livingsecurity.com/features/settings/scim-google-workspace.md) - [SCIM groups and cohorts](https://docs.livingsecurity.com/features/settings/scim/groups.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.