Enterprise
SCIM provisioning from your identity provider
Joiners, movers and leavers flow from your IdP automatically — no manual account admin, no orphaned access waiting to become an audit finding.
SCIM provisioning connects Ciao to your identity provider so user accounts are created, updated and deactivated automatically as your directory changes. Unlike manual account administration, SCIM removes the human step where offboarding fails: when a user is deactivated in your IdP, the change propagates to Ciao, and the surrounding admin actions land in the append-only audit trail your reviewers can inspect.
Published 2026-07-03 · Last updated 2026-07-03
Orphaned accounts are audit findings waiting to happen
Every access review finds them: accounts belonging to people who changed roles or left months ago, still active because deprovisioning depended on a ticket someone never filed. In most SaaS tools that is an exposure problem. In a platform where a signed-in user can prompt changes to production software, it is also a change-control problem — an account nobody owns, with the ability to propose changes to systems your business runs on.
SCIM exists to remove the manual step. Your identity provider is already the source of truth for who works here and what group they belong to; SCIM makes Ciao a subscriber to that truth instead of a separate list an administrator must remember to reconcile.
Auditors have converged on the same view: access reviews that depend on manual reconciliation collect findings, and lifecycle automation is the accepted fix. If your organization already runs SCIM for its other systems of consequence, extending it to the platform that builds and deploys software is the consistent move — and if Ciao would be your first SCIM integration, the rollout steps below are deliberately conservative.
What SCIM provisioning covers
Coverage spans the lifecycle events your access reviews actually test:
- Account creation — Users assigned to Ciao in your IdP get accounts provisioned automatically — no request queue, no manual creation.
- Attribute updates — Name and profile changes flow from the directory, so the account record follows the person without admin intervention.
- Group-to-role mapping — IdP groups can map to Ciao roles, so role-based access control is driven by the directory structure your team already governs.
- Deactivation — When your IdP deactivates a user, their Ciao access is removed as part of the lifecycle flow — the step manual offboarding most often misses.
- An audit record — Provisioning changes are admin actions, and admin actions are recorded in the append-only audit trail alongside prompts, merges and deploys.
How a rollout works
1. Start from SSO
SCIM assumes SSO via SAML or OIDC is in place, so authentication and provisioning share one identity source.
2. Connect the IdP
Configure the SCIM integration in your identity provider during onboarding, with the enterprise team working alongside your identity engineers.
3. Map groups to roles
Decide which IdP groups correspond to which Ciao roles and project scopes, and record the mapping — it becomes part of your access-control documentation.
4. Pilot with one group
Assign a small group, then verify create, update and deactivate events land as expected before expanding. Include at least one deactivation in the pilot — it is the event that matters most and the one teams most often forget to test.
5. Verify in the audit trail
Confirm provisioning events appear as admin actions in the append-only trail, so your access reviews have evidence rather than assumptions.
SCIM, SSO, RBAC and the audit trail as one system
These four controls are designed to be reviewed together. SSO answers how people authenticate; SCIM answers how accounts come to exist and cease to exist; role-based access control answers what an authenticated person may do; and the append-only audit trail records what they actually did — prompts, merges, deploys and admin actions. A reviewer can trace a single person from directory group to Ciao role to a specific recorded action, which is the traceability story most access-control frameworks are really asking for.
In practice, the combination changes the texture of an access review. Instead of interviewing administrators about what they believe happened, the reviewer reads what happened: the directory event, the resulting role, the actions taken under it. Review time shifts from evidence-gathering to judgment, which is where it belongs.
Lifecycle events and their effect
Use this as the checklist for your pilot: run each event with a test user and verify the effect.
| Lifecycle event | What happens in Ciao | Where you verify it |
|---|---|---|
| User assigned in IdP | Account provisioned with mapped role | Admin actions in the audit trail |
| Attributes change | Account record updated from the directory | Account detail and audit trail |
| Group membership changes | Mapped role and scope follow the directory | RBAC configuration and audit trail |
| User deactivated in IdP | Ciao access removed via the lifecycle flow | Audit trail and access review |
| Workspace content | Apps and code remain owned by the workspace | Code export available at any time |
Verification notes
Provisioning is a control your team should test, not take on faith. During evaluation, run the lifecycle end to end with a test user — assign, update, deactivate — and watch the results in the audit trail. Integration specifics for your IdP are covered during onboarding, and the security pack, available on request via the contact page, documents identity architecture for reviewers who need the detail in writing.
If your rollout has unusual constraints — shared accounts to eliminate, contractors on a separate IdP, staged migrations — put them in writing to the enterprise team before the pilot, so the configuration is designed against your reality rather than adjusted after it.
Frequently asked questions
Which identity providers can drive SCIM provisioning?
SCIM is a standard, and the identity providers enterprises typically run — Okta, Microsoft Entra ID and similar — implement it. Confirm your specific IdP and configuration with the enterprise team during onboarding.
What happens to a person's work when they are deprovisioned?
Their access is removed; the work does not vanish. Applications and code belong to the workspace, with 100% code ownership and export to your own repo available at any time — offboarding a person never strands the software.
Does SCIM replace just-in-time provisioning?
They solve different halves. JIT creates an account at first sign-in; SCIM manages the ongoing lifecycle including updates and deactivation. Many rollouts use JIT during pilot and SCIM for the full deployment.
Are provisioning and deprovisioning actions logged?
Yes. They are admin actions, recorded in the append-only audit trail alongside prompts, merges and deploys — so access reviews can cite recorded events rather than screenshots.
How do we validate SCIM before rolling it out company-wide?
Pilot with a test group: assign, change attributes, move groups, deactivate, and verify each event in the audit trail. The enterprise team supports the pilot, and the security pack documents the identity architecture under review.