![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Dec 8, 2025
\nThis featureis available for the Standard, Premium, and Enterprise plans.
\nTailscale supports System for Cross-domain Identity Management (SCIM) to integrate with several identity providers, as described in the following topics:
\nWhen you enable SCIM, if you already had any users from your identity provider using Tailscale, the users stay in Tailscale. You can review these users when you enable SCIM in your identity provider, such as Okta or Microsoft Entra ID, and decide what action to take for them.
\nIf you are using the same app for single sign-on (SSO) and SCIM (that is, you're not using a custom Microsoft Entra ID app), users can sign up for Tailscale only if they are allowed to by the identity provider (if they have the app assigned).
\nIf you are using different apps for SSO and SCIM, we recommend you use\r\nuser approval to restrict which users are authorized to join your tailnet.
\nWhen syncing a user suspension:
\nWhen syncing a user deletion:
\nFor Okta, you cannot sync deletions from Okta to Tailscale.
\nFor Microsoft Entra ID, when you delete a user, they are first soft deleted (suspended in Tailscale), then 30 days later they are hard deleted (deleted in Tailscale).
\nFor Google Workspace, if you delete a user, they are suspended in Tailscale. When you recreate a previously deleted user in Google Workspace, Tailscale treats them as a new user.
\nYou can also manually delete users from your tailnet, including users created prior to enabling provisioning, synced users who have been suspended in Tailscale, and users from other domains. You cannot manually delete users who are being synced, as they will get recreated at the next sync.
\nTailscale syncs group membership from SCIM-integrated identity providers to Tailscale. You can use the same\r\nhuman-readable group names you have in a SCIM-integrated identity provider to refer to groups in your\r\naccess control policies. For example, if Alice and Bob are in the \"security-team\" group in a SCIM-integrated\r\nidentity provider, then the access rule can refer to the \"security-team\" group:
\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"group:security-team@example.com\"],\\\r\n \"dst\": [\"tag:logging\"],\\\r\n \"ip\": [\"*\"]\\\r\n }\\\r\n ],\r\n \"tagOwners\": {\r\n \"tag:logging\": [\"group:security-team@example.com\"]\r\n }\r\n}\nYou can use the visual policy editor to manage your tailnet policy file. Refer to the visual editor reference for guidance on using the visual editor.
\nWhen someone's role changes, instead of updating their permissions in every application you manage, you\r\ncan instead make a single change in the SCIM-integrated identity provider, to update what applications\r\nthey should have access to, and with which permissions.
\nSynced groups cannot be used to assign user roles.
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}