Treat a SCIM bearer token like an admin credential, because it can create, modify and delete user accounts. Store it in a secrets vault, send it only over TLS, give it a limited lifetime, and rotate it on a schedule and whenever a person who knew it leaves.
Why this token is high value
SCIM is the protocol identity systems use to provision users and groups into other apps. The token that authorizes those calls can often add an account, change a group, or deactivate someone. If it leaks, an attacker may create a back door user or remove legitimate ones. For background see what SCIM provisions and why.
What the standard says
RFC 7644, the SCIM protocol specification, has a security section with several relevant rules:
- SCIM resources contain sensitive information, so clients and service providers must require a transport layer security channel.
- Bearer tokens must contain sufficient entropy to prevent random guessing, and must be exchanged using TLS.
- Bearer tokens must have a limited lifetime that the service provider can determine, directly or by checking with a validation service. Expiry forces clients to obtain a new token.
- The specification encourages stronger authentication choices than basic authentication underneath OAuth bearer tokens.
- Clients should consider whether query filters in a GET URL expose sensitive information in browser or server logs, and may use POST for such queries.
The standard leaves the choice of authentication method to the implementer, but the principles are clear: strong, expiring, encrypted in transit.
Handling checklist
- Generate a long random token. Do not choose it by hand. If the app lets you pick, still use a random value.
- Store it only in a secrets vault on the identity provider side, with access limited to the few admins who manage provisioning.
- Use a dedicated token for provisioning. Do not reuse a general API key.
- Prefer expiring tokens or OAuth based provisioning if the app supports it, over a never expiring static value.
- Rotate on a calendar, for example every quarter, and also after staff changes on the identity team.
- Rotate with overlap. Create the new token, update the identity provider, confirm a sync succeeds, then revoke the old one.
- Monitor provisioning events. Alert on unexpected user creations, privilege group changes and bulk deletes.
Rotation without breaking sync
| Step | Check |
|---|---|
| Create new token in the app | Old token still works |
| Paste into identity provider config | Test connection passes |
| Run a manual sync | No errors, counts match |
| Revoke old token | Next scheduled sync still passes |
Schedule rotation at a quiet time, since a failed sync can leave new hires without access on their first day.
Related controls
Provisioning is half of the story. The other half is deprovisioning, covered in SCIM offboarding: deactivate or delete. Pair both with a break glass path, in case the identity provider is down, as in break glass access when SSO is down.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you collect proof of rotation and access reviews for auditors, and its asset discovery helps you list which systems have provisioning connections. Try the free scan.
Quick check
Is a never expiring SCIM token acceptable?
The specification says bearer tokens must have a limited lifetime. If your app only offers static tokens, compensate with frequent rotation and monitoring.
Who should be able to view the token?
Only the few admins who manage provisioning, through a vault with an access log.
Sources
- RFC 7644, SCIM Protocol, IETF
Last reviewed: 19 October 2026.
