# SCIM Provisioning and Deprovisioning
SCIM (System for Cross-domain Identity Management) is an open standard protocol, currently at version 2.0, that enables automated creation, modification, and deletion of user accounts across multiple systems from a single authoritative source. When an employee joins a company, SCIM creates their accounts in every integrated application simultaneously. When they leave, SCIM deletes or disables every account, across every application, in seconds.
The protocol was developed because organizations were drowning in a manual, error-prone account lifecycle problem that only grew worse as the number of SaaS applications per organization increased. An organization using 50 SaaS tools needs user accounts created in 50 places when someone joins, and needs those same 50 accounts terminated when they leave. Doing this by hand, through IT tickets, is not just slow; it is structurally guaranteed to fail. SCIM replaces that process with a machine-to-machine protocol that operates automatically, reliably, and with an auditable log.
SCIM 2.0 is defined in RFC 7642, RFC 7643, and RFC 7644. It uses REST APIs and JSON, making it straightforward to implement and integrate with modern web services. The standard defines a schema for user and group objects, a set of REST endpoints (for create, read, update, delete, and search), and a protocol for how the identity provider pushes changes to connected applications.
The SCIM architecture has two roles: the provisioning source (the authoritative identity system, typically an Identity Provider like Okta, Azure Active Directory, or JumpCloud) and the provisioning target (any SaaS application or system with a SCIM endpoint, such as Salesforce, GitHub, Slack, ServiceNow, or Zoom).
The identity provider maintains the canonical record of who works at the organization, what department they are in, and what groups or roles they hold. This data comes from HR systems: when a new hire is entered into the HRIS (Workday, BambooHR, ADP), that event triggers a SCIM provisioning cycle.
Provisioning (joining): When a new user record appears in the IdP, the SCIM protocol executes a POST request to each connected application's SCIM endpoint, sending a JSON payload containing the user's attributes (name, email, department, manager, role). The application creates the account and returns a success response. The IdP logs the operation. The user gains access to all 50 applications before their first day, without a single IT ticket.
Profile synchronization (changes): When an existing user changes department, gets a promotion, or moves to a different team, the HR system updates the HRIS record, the IdP receives the change, and SCIM sends PATCH requests to every application, updating the user's attributes and group memberships accordingly. Privilege creep, where users accumulate permissions from previous roles without having the old ones removed, is structurally prevented because role changes trigger immediate updates everywhere.
Deprovisioning (termination): When an employee is terminated in the HRIS, the IdP marks the user as inactive and executes SCIM DELETE (or PATCH to set active: false, depending on the application's preference) across all connected applications. This happens within seconds of the HR termination action, not days or weeks later. The terminated employee's session tokens are also revoked through the IdP's session management layer.
Groups and entitlements: SCIM also manages group membership, which is the primary mechanism for controlling what users can do within an application, not just whether they have an account. A user added to the "Engineering" group in the IdP automatically gains the corresponding permissions in every SCIM-integrated application that maps to that group.
The deprovisioning failure mode is one of the most persistent and underestimated access control problems in enterprise security. A 2023 study found that the average employee retains access to three to five SaaS applications for 30 or more days after their employment ends. In some organizations, the window extends to months or years. This is not a hypothetical risk; it is a documented source of real breaches, insider threat incidents, and compliance findings.
The failure is not malice on the part of IT teams. It is structural. Manual deprovisioning requires someone to know about the termination (not always immediate), to know which applications the employee used (rarely fully documented), and to execute the necessary account changes in every system (time-consuming, repetitive, and easy to miss). Each of these steps is a failure point. SCIM eliminates all of them by automating the entire chain.
From a compliance standpoint, access control for terminated employees is explicitly addressed in virtually every major framework. SOC 2 Type II, ISO 27001, PCI DSS 4.0 (Requirement 7 and 8), HIPAA, and NIST CSF all require documented processes for timely access revocation. Auditors specifically look for evidence that terminations trigger access removal. A SCIM integration with audit logs is direct, automatable evidence. A manual IT ticket queue is a finding waiting to happen.
Privilege creep is a slower-burning version of the same problem. Without automated provisioning, users accumulate access as their role evolves. The engineer who joined as a junior developer and spent six months in a DevOps rotation still has production database access, even though they moved to product management two years ago. SCIM, tied to role-based groups in the IdP, ensures that access tracks role, not tenure.
Consider the math for a mid-size organization. Five hundred employees. Fifty SaaS applications. Annual attrition of 15 percent, meaning 75 employees leave each year. Without SCIM, that is 3,750 individual account deletions that must be manually executed annually, across 50 different application admin consoles, each requiring a login, a search, and a deletion action. Even at two minutes per application per user, that is 125 person-hours of deprovisioning work per year, none of it value-adding, all of it prone to omission. A single SCIM integration replaces that work with automation that executes more reliably and in a fraction of a second. The case for automation is not only security-driven; it is operationally obvious.
SCIM schema: The core user object in SCIM 2.0 includes standard attributes (userName, name, emails, phoneNumbers, title, department, manager) and supports custom extensions for application-specific attributes. Groups are a separate schema object. Applications declare which schema elements they support in their service provider configuration endpoint.
Authentication between IdP and SP: SCIM endpoints are protected by bearer tokens or OAuth 2.0. The IdP authenticates to the application's SCIM endpoint using a long-lived token issued by the application during initial setup. This token must be stored securely in the IdP and rotated periodically.
SCIM vs. Just-in-Time (JIT) provisioning: JIT provisioning creates a user account the first time the user logs in via SSO, using attributes from the SSO assertion. JIT is simpler to set up than SCIM and handles provisioning adequately. However, JIT does not handle deprovisioning. A user whose SSO access is revoked stops being able to log in, but their existing account in each application persists, potentially with data, session tokens, and API keys attached to it. SCIM deprovisioning removes the account entirely. The best architecture uses JIT for initial provisioning simplicity and SCIM for deprovisioning, or full SCIM for both.
Coverage gap: Not all SaaS applications support SCIM. Many legacy applications, niche vertical tools, and older enterprise software have no SCIM endpoint. For these applications, the options include manual lifecycle management (the problem SCIM was designed to solve), custom API-based automation (write scripts that call the application's native API on termination triggers), a SCIM bridge (a middleware layer that translates SCIM to the application's native API), or accepting the gap and compensating with periodic access reviews.
Soft delete vs. hard delete: Some applications prefer to deactivate accounts (set active: false) rather than delete them, preserving audit history, data attribution, and the ability to re-activate if a termination is reversed (a re-hire, for example). Others prefer hard deletion. SCIM supports both patterns; the IdP should be configured to match each application's preference.
Reconciliation: IdPs with mature SCIM implementations perform periodic reconciliation runs, comparing the IdP's user directory against what the application reports as its current user list. Any accounts present in the application but absent from the IdP (orphaned accounts created outside the SCIM process, or SCIM failures that left accounts behind) are flagged for remediation.
Error handling and retry: SCIM provisioning operations can fail for mundane reasons: the target application is temporarily unavailable, the API rate limit is exceeded, or an attribute value violates the application's validation rules (a display name that is too long, for example). A production SCIM integration must handle these failures with retry logic, alerting, and idempotency. An operation that fails silently is worse than a manual process that fails visibly: the silent failure creates the illusion of successful deprovisioning while the account remains active. IdPs like Okta and Azure AD expose SCIM provisioning logs and error dashboards for exactly this reason. Those dashboards should be reviewed as part of regular security operations, not left unmonitored.
SCIM is the operational implementation of a core Zero Possession Architecture (ZPA) principle: entitlement must be active and current, not historical. ZPA's formulation, "Trust nothing. Possess nothing. Verify everything," applies directly to account existence: a user should not possess an account in a system unless they currently hold an entitlement that justifies it. SCIM ensures that possession tracks entitlement with minimal lag.
CDA evaluates SCIM coverage as part of the IAT domain's mission set. A client organization with 50 SaaS applications but only 20 with SCIM integrations has a 30-application orphaned account risk. That gap is a concrete, measurable finding, not an abstract concern. The remediation path is specific: identify which of the 30 non-integrated applications have SCIM endpoints (many do, the integration just has not been configured), build SCIM bridges for those that do not, and establish quarterly manual access reviews for the residual gap that cannot be automated.
Particular attention is warranted for applications with elevated privilege: code repositories (GitHub, GitLab), cloud infrastructure consoles (AWS, GCP, Azure), ticketing systems with customer data (Zendesk, ServiceNow), and finance platforms (Expensify, NetSuite). A terminated employee's orphaned account in Slack is a data exposure risk. An orphaned account in AWS with an IAM role attached is an active attack surface.
The measurement for SCIM coverage is straightforward: for every SaaS application in the organization's inventory, it is either SCIM-integrated, covered by an alternative automation, or an accepted and documented gap with compensating controls. Any application that is none of those three is an unmanaged risk.