> ## Documentation Index > Fetch the complete documentation index at: https://docs.genesiscomputing.com/llms.txt > Use this file to discover all available pages before exploring further. # SCIM Security > Security controls, risks, and production recommendations for inbound SCIM provisioning. This page covers the security posture of inbound SCIM in Genesis: the controls that ship by default, the residual risks you should consider for your environment, and the production recommendations for a deployment that will serve customer-facing SCIM traffic. ## Scope Inbound SCIM is exposed at: * `/scim/v2` — the SCIM 2.0 service-provider surface used by customer IdPs. * `/api/config/scim` — the [admin endpoints](/docs/Setup/SCIM-Admin-API) used to manage tokens and group-to-role mappings. ## Security controls (built in) * **Distinct credential type.** The SCIM bearer token is separate from Genesis user sessions and personal access tokens. SCIM bearer tokens cannot authenticate any Genesis API outside `/scim/v2`. * **Token storage.** Persisted SCIM tokens are stored as hashes. Plaintext tokens are returned **only once**, in the response to `POST /api/config/scim/tokens/rotate`. * **Token revocation.** `POST /api/config/scim/tokens/revoke` deactivates persisted tokens for the tenant immediately. * **Tenant scoping.** Group-to-role mappings and persisted tokens are scoped to the tenant identifier configured via `GENESIS_SCIM_TENANT_ID`. Mapping keys are normalized before persistence. * **SCIM-managed user lock.** Users carrying SCIM metadata (`settings.scim`) are protected from manual role mutation through the UI, the role API, and admin-facing tools. The SCIM actor remains authoritative for these users' role memberships. * **Soft deprovisioning.** Genesis never hard-deletes users or roles in response to SCIM operations. Deprovisioning sets `active=false`. * **Login admission gate.** When `GENESIS_SCIM_REQUIRE_PROVISIONED_USERS=true` is set, inactive SCIM users are denied login and only active SCIM-provisioned users may sign in. In a Databricks App the variable is ignored (with a startup warning): SCIM is refused there, and who may sign in is the App's `CAN_USE` permission. * **Audit logging.** `SCIM_AUDIT_LOG` rows include tenant, operation, resource type, resource id, external id, before JSON, after JSON, and timestamp. * **SCIM-shaped errors.** Invalid tokens, rate-limit events, and SCIM route errors return SCIM-compliant error payloads with proper status codes, `scimType`, and `detail`. ## Risks and recommended production controls | Risk | What ships today | Recommended production control | | - | - | - | | Token disclosure | Plaintext returned once at rotation; persisted as hash. | Store generated tokens in the customer IdP's secret field and your deployment secret manager. Rotate on staff turnover or incident response. | | Token replay | Long-lived bearer tokens are supported. | Always require TLS on the Genesis hostname. Rotate tokens periodically. Consider IP allowlists or WAF rules restricting SCIM traffic to the customer IdP's egress ranges. | | Tenant boundary mistakes | Tenant id is included on persisted token rows and mapping rows. | Complete a tenant-isolation review before enabling many tenants in a single shared deployment. Today the tenant boundary is suitable for single-tenant deployments and small numbers of well-known tenants. | | Rate-limit bypass across replicas | In-process per-token rate limiter (default 600 req/min). | For multi-replica deployments, enforce strict global limits at ingress, WAF, API gateway, or a shared limiter such as Redis. | | Accidental mass deprovision | Audit rows expose `active=false` changes; pilot validation surfaces unintended changes. | Add alerting on deprovision spikes (see [Monitoring](/docs/Setup/SCIM-Monitoring#suggested-alerts)). Require staged rollouts on the IdP side for large group changes. | | Mapping abuse | Admin permission (`ACCESS_CONFIG_PANEL`) is required for mapping APIs. | Review which Genesis users hold the admin role. Require change-management review for group-to-role mapping updates. | | Audit export gaps | Audit rows are stored in Genesis metadata storage. | Configure SIEM export or scheduled audit extraction for regulated customers. See [Monitoring → SIEM export](/docs/Setup/SCIM-Monitoring#siem-export-guidance). | ## Verification checklist Run these checks during pilot validation and again before promoting an integration to production: * An invalid SCIM bearer token is rejected at `/scim/v2` with a SCIM-shaped `401`/`403`. * A SCIM bearer token cannot authenticate normal Genesis user APIs (for example, `/api/rbac/me/permissions` rejects the token). * A non-admin Genesis user cannot manually edit roles for a SCIM-managed user through the UI or the role API. * The SCIM actor can reconcile SCIM-managed roles by re-pushing groups. * Once SCIM-only admission is enforced, deactivated SCIM users have no roles and cannot sign in. * Removing a member from a mapped group does not deactivate the user. * Deleting a mapped group from the IdP does **not** revoke the baseline user role from active users when that group maps to the baseline role. * Audit rows are written for token rotation, token revocation, mapping replacement, user changes, group sync, group delete, and user deactivation. ## Production rollout recommendation Inbound SCIM is suitable for production customer use when **all** of the following are in place for the deployment: 1. The [Pilot Runbook](/docs/Setup/SCIM-Pilot-Runbook) has been completed end-to-end, including the conformance harness. 2. At least one IdP product has been validated against the deployment for the customer's intended provisioning shape. 3. Monitoring and alerting are wired up per the [Monitoring](/docs/Setup/SCIM-Monitoring) page. 4. For multi-replica deployments, strict global SCIM rate limits are enforced at ingress, WAF, API gateway, or a shared limiter. 5. A documented rollback path exists, and a SCIM token rotation procedure is owned by the customer's IdP admin. 6. The verification checklist above passes against the deployment. For deployments that will host **many tenants in a single Genesis instance**, complete a tenant-boundary review with your Genesis contact before broad rollout. Today the tenant model is suitable for single-tenant and small multi-tenant deployments; broader multi-tenant production rollouts may need additional isolation controls. ## Related pages * [SCIM Admin API](/docs/Setup/SCIM-Admin-API) * [SCIM Pilot Runbook](/docs/Setup/SCIM-Pilot-Runbook) * [SCIM Monitoring](/docs/Setup/SCIM-Monitoring) * [Genesis Agent Security Controls](/docs/Security-Controls/Genesis-Agent-Security-Controls)