> ## 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.

# SCIM security and best practices

> How Living Security SCIM protects your directory data and token, and how to roll out provisioning safely.

> [!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).

## How Living Security protects SCIM

**The token**

* The token is shown once. Living Security stores only a hash, so no one at Living Security can read it back.
* Tokens start with `lsscim_` and end with a checksum, so secret scanners can detect a leaked token.
* A token works only for one organization and only on that organization's regional base URL. The organization always comes from the token, never from the URL or the request body.
* Every refused token gets the same `401` response, whether it is unknown, revoked, expired or sent to the wrong region. The response gives an attacker nothing to learn from.
* HTTP Basic authentication is refused without TLS. The SCIM base URL accepts HTTPS only.

**Your data**

* SCIM data stays in your organization's data residency region.
* The sign-in service receives only a login name, the primary email, your organization and whether the account is enabled.
* Living Security discards any `password` your IdP sends and never stores it.
* SCIM `roles` and `entitlements` never grant access. SCIM never changes roles or parent organization access.
* Request records keep a copy of each request for 30 days, with passwords and secrets removed. Error messages never repeat a value you sent.
* Logs keep counts and IDs only.

**Limits**

* Each token can send 50 requests per second. Each organization can make 25 changes per second. Requests without a valid token are limited per client address. Over a limit, Living Security answers `429` with a `Retry-After` header.

**Audit**

The audit log records:

* connection created and deleted, token created, rotated and revoked, and expiry notices sent
* setup links created, revoked and used
* SCIM event receivers created, changed and deleted
* every change SCIM makes to a person, with the connection as the actor

## Best practices

**Before the first sync**

* Assign at least two owners in Living Security, so SCIM can never remove your last owner.
* Make the SCIM `userName`, the primary email and the SSO NameID the same value: the person's email address. See [Identity requirements](https://docs.livingsecurity.com/features/settings/scim/sso-and-sub-organizations.md#identity-requirements).
* Use **Troubleshoot SCIM → Validate** to dry-run a sample request, and **Check an Entra mapping** if you use Microsoft Entra ID.
* Turn off **Send welcome email when SCIM provisions a new user** for a first import of people who already use Living Security. Turn it on when you want new people to get a welcome email.

**Roll out in steps**

1. Assign one test user in your IdP.
2. Check **Troubleshoot SCIM → Checklist** and the **Attributes** tab. Confirm that the person appears in **Workforce → People** with the attributes you expect.
3. Have the test user sign in with SSO.
4. Assign a small group, check again, then assign everyone.

**Protect the token**

* Treat the token as a password. Keep it in your IdP's provisioning settings only. Do not paste it into tickets, chat or email.
* Send a [setup link](https://docs.livingsecurity.com/features/settings/scim/connection.md#send-a-setup-link-to-your-it-administrator) to the person who configures your IdP instead of the token. Revoke the link when they are done.
* Rotate the token before it expires, and when someone who saw it leaves your team. Finish the rotation only after the card shows your IdP has used the new token.
* If a token leaks, rotate it and finish the rotation at once, or revoke it.

**Watch the connection**

* Check **Troubleshoot SCIM → Health** after changes in your IdP, and when **Held accounts** is above zero.
* Expiry notices go to the recipients set for API access key notices. Make sure someone receives them.

## Related

* [Set up a SCIM connection](https://docs.livingsecurity.com/features/settings/scim/connection.md)
* [API reference and limits](https://docs.livingsecurity.com/features/settings/scim/api-reference.md)
* [Audit log](https://docs.livingsecurity.com/features/settings/audit-log.md)


## Related topics

- [Living Security SCIM](https://docs.livingsecurity.com/features/settings/scim/overview.md)
- [Set up a SCIM connection](https://docs.livingsecurity.com/features/settings/scim/connection.md)
- [Test your SCIM setup](https://docs.livingsecurity.com/features/settings/scim/testing.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.