Skip to main content
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. If the card says SCIM is set up and managed in the setup wizard, use SCIM Provisioning.

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