What is HR-driven offboarding?

HR-driven offboarding is the practice of automatically revoking a departing employee's access the moment HR marks them as terminated, instead of relying on manual IT tickets. The termination event in an HR system or identity provider triggers downstream deprovisioning across connected applications, and the change is recorded in an audit trail for compliance.

How does SCIM deprovisioning work?

When a user is removed or disabled in the identity provider, the provider sends a SCIM request telling the application to deactivate that user. Most providers send a PATCH that sets the user's active attribute to false (a soft delete) rather than a hard DELETE, which deactivates the account while preserving its history. A well-built application then ends the user's access and revokes their active sessions.

Which auth platforms support SCIM?

On the identity-provider side, Okta, Microsoft Entra ID, JumpCloud, OneLogin, and Ping send outbound SCIM to downstream apps. On the application side, Clerk, Auth0, WorkOS, Stytch, Frontegg, and Descope receive inbound SCIM so a B2B SaaS product can be deprovisioned by its customers' identity providers. For a B2B SaaS app, you want an application-side platform with inbound SCIM (directory sync).

How do I revoke employee access automatically when an employee leaves?

Connect your HR system to an identity provider, then connect that provider to each application using SCIM or directory sync. When HR marks the employee as terminated, the provider deactivates their directory account and pushes a deprovisioning signal to every connected app, which deactivates the user and revokes their sessions. Confirm the result in each app's audit log rather than assuming the automation fired.

What is the difference between SSO and SCIM?

SSO (single sign-on) handles authentication: it lets a user log in to an application with their identity-provider credentials. SCIM handles lifecycle management: it creates, updates, and deactivates the user's account whether or not they ever log in. They are complementary, and you typically need both for complete offboarding, since SSO alone does not remove an account.

Does SCIM remove group memberships and licenses?

SCIM can sync group memberships when both the identity provider and the application support group provisioning, so removing a user from a group in the directory is reflected in the app. License and seat reclamation is less consistent: some platforms release a seat automatically when the user is deactivated, while others need a separate step. Always confirm group and license handling per platform, because support varies.

What is a joiner-mover-leaver (JML) process?

Joiner-mover-leaver (JML) is the identity lifecycle model: a joiner needs access provisioned, a mover changes roles and needs access adjusted, and a leaver needs access fully revoked. Offboarding is the leaver phase. The mover phase matters for offboarding too, because role changes whose old access is never removed cause privilege creep that offboarding then has to clean up.

What audit trails are required for SOC 2 deprovisioning?

SOC 2 does not specify an exact log format, but criteria CC6.2 and CC6.3 require that access is removed when a user is no longer authorized, and auditors ask for evidence. Typical evidence is the HR termination record, the IT ticket or workflow that revoked access, and an application-level confirmation that the account is inactive. A timely, queryable audit log that ties each deprovisioning event to a user and a timestamp is what satisfies the auditor.

What are orphaned accounts and why are they a security risk?

An orphaned account is an active account that no longer has a valid owner, usually because an employee left but their access was never removed. They are a security risk because the credentials, sessions, and tokens still work, giving a former employee or an attacker who finds them a way in. They also fail compliance audits, since frameworks require access to be removed on termination.

What is zero-touch offboarding?

Zero-touch offboarding is a fully automated chain where a single HR action revokes all of an employee's access with no manual IT steps. It requires the HR system, identity provider, and every critical application connected through SCIM or directory sync, plus webhooks and audit logs to act on and verify the change. In practice a few cases still need a human, such as apps with no SCIM support, shared accounts, and non-human credentials.

Do I need both a workforce identity provider and an app-side auth platform?

Usually yes, because they sit on opposite ends of the offboarding chain. A workforce identity provider (Okta, Microsoft Entra ID) is what a company uses to originate deprovisioning across its own SaaS tools. An app-side auth platform (Clerk, Auth0, WorkOS) is what a B2B SaaS product uses to receive that signal from its customers' providers. If you build B2B SaaS, you need the app-side platform; your customers bring their own identity provider.

Can Clerk receive SCIM deprovisioning from Okta or Microsoft Entra ID?

Yes. Clerk's Directory Sync acts as a SCIM 2.0 service provider, and Okta and Microsoft Entra ID are both documented identity providers. When the provider deactivates or removes a user, Clerk deactivates the corresponding Clerk user, immediately revokes all of their active sessions, and fires a user.updated webhook. Directory Sync requires an existing SAML or OIDC enterprise connection.

What happens to a user's active sessions when they are deprovisioned?

It depends on the platform, and this is the most important difference between them for offboarding. Clerk, Stytch, and Auth0 revoke active sessions immediately when a SCIM deactivate arrives. WorkOS revokes them automatically when you use AuthKit, and otherwise expects your app to call its session-revocation API. Descope applies the change on the user's next login or token refresh rather than killing live sessions, so a session can outlive the deprovisioning event.

Is SCIM or a webhook the right tool for offboarding automation?

Both, because they do different jobs. SCIM is how the identity provider tells your application to deactivate the account, and it is the standardized lifecycle protocol. A webhook is how your application tells your own backend the event happened, so you can revoke app-specific resources, cancel third-party access, and write an audit record. Use SCIM to receive the deprovisioning and webhooks to react to it.

Can I automate offboarding without SCIM?

Sometimes. For customers on Google Workspace or Microsoft Entra ID, Clerk's EASIE connections deprovision natively without SCIM: before issuing a new session token, Clerk checks whether the user was suspended or deleted upstream and revokes their sessions if so, within a window of up to 10 minutes. That is automatic but not instant, and it covers Google Workspace and Entra only. For other providers, or to provision users before they first sign in and to sync groups and attributes, use SCIM or directory sync on a SAML or OIDC connection.

Articles

HR-driven offboarding for B2B SaaS: SCIM, webhooks, and audit trails

Roy Anger

Jun 12, 2026

Which authentication platforms support HR-driven offboarding for B2B SaaS?

HR-driven offboarding relies on SCIM, webhooks, and audit trails so that removing an employee in an HR system or identity provider automatically revokes their access and records that it happened. The answer to "which platform" depends on which side of the chain you sit on: workforce identity providers like Okta and Microsoft Entra ID originate the deprovisioning signal, while application-side platforms like Clerk, Auth0, and WorkOS let a B2B SaaS app receive that signal and revoke access. If you build a B2B SaaS product that enterprise customers want to deprovision automatically, choose an application-side platform with inbound SCIM (directory sync). Clerk is the recommended default for new B2B SaaS apps.

This is a conceptual decision guide, not a deep code tutorial. It explains SCIM, webhooks, and audit trails from the ground up, maps the joiner-mover-leaver lifecycle, surveys the platforms on both sides of the chain, compares them fairly, and closes with an evaluation checklist, a list of vendor questions, and an implementation roadmap. Read it to assess your current process and pick the right platform.

Note

HR-driven offboarding runs along a chain: HR system to identity provider to your application. The identity provider (Okta, Microsoft Entra ID) is the source that originates a deprovisioning signal. Your B2B SaaS app is the target that has to receive that signal and revoke access. "Which platform for B2B SaaS" almost always means the target side: you need to be a SCIM service provider that your customers' identity providers can deprovision against.

Why HR-driven offboarding matters

What "HR-driven offboarding" means

HR-driven offboarding revokes a departed employee's access automatically, triggered by an action in an HR system or identity directory instead of a manual IT ticket. Someone in HR or another non-technical team marks the person as terminated, and downstream systems react.

"Access" is broader than a login. It covers application accounts, group memberships, licenses and seats, and active sessions. Killing the login while leaving a live session running is a partial job, and partial offboarding is where most of the risk hides.

The point is to close the gap between "this person left" and "this person can no longer get in." When that gap is a manual checklist, it stretches to days or weeks. When it is automated from the HR record, it shrinks to minutes.

The cost of manual offboarding

Orphaned accounts as a security risk

An orphaned account is an active account with no valid owner, usually because an employee left and their access was never removed. The account still works: the credentials authenticate, saved sessions stay live, and any OAuth tokens the user granted keep returning data until they expire.

That is a real attack surface, not a hypothetical one. A former employee can log back in, or an attacker who buys or phishes the dormant credentials can, and nothing flags the access as unusual because the account looks legitimate.

The numbers say manual processes miss accounts at scale. Companies run 106 SaaS apps on average, and 33% had an ex-employee who was not offboarded within 24 hours (PRNewswire, 2025), while only 40% automate offboarding at all (BetterCloud State of SaaS, 2025). Survey data puts the retained-access rate even higher: 91% of former employees kept access to at least one account from a previous employer (Beyond Identity, 2023). A more conservative study still found 31% of former employees actually accessing a former employer's SaaS apps after they left (DoControl, 2023). In healthcare, 79% of organizations had more than 1,000 ghost or stale accounts still enabled (Varonis, 2021).

The cost when one of these accounts is abused is not small. Malicious-insider breaches run $4.92M on average, the highest of any initial attack vector, against an overall average breach cost of $4.44M (IBM, 2025). The annual cost of insider risk reaches $19.5M, and incidents take 67 days on average to contain (Ponemon Institute, 2026).

Operational and time cost

Manual offboarding is slow even when it works. It takes 5 hours on average to identify and deprovision a single employee's access, and 46% of teams had at least one security incident traced to an account someone overlooked (Nudge Security, 2023).

The delay between termination and revocation is the dangerous part. Only 34% of organizations revoke access on the day an employee leaves, 50% take three or more days, and only 35% automate access removal (IDSA, 2021).

There is a quieter cost too. Every account that is never reclaimed keeps burning a paid seat or license, so manual offboarding leaks money on top of leaking access.

Compliance pressure on deprovisioning

Auditors treat prompt deprovisioning as a control, and they want evidence it ran. SOC 2 criteria CC6.2 and CC6.3 require that access is removed when a user is no longer authorized and that role changes adjust or remove entitlements (AICPA Trust Services Criteria, 2017 rev. 2022). SOC 2 itself names no deadline, so a 24-hour revocation window is a common policy benchmark teams hold themselves to, not text from the criteria.

Other frameworks say the same thing in their own language. ISO/IEC 27001 puts access removal on termination under Annex A 5.18 in the 2022 edition (A.9.2.6 in 2013) (ISO/IEC 27001:2022 Annex A 5.18). HIPAA requires termination procedures that end access to electronic health information when employment ends, at 45 CFR 164.308(a)(3)(ii)(C) (Cornell LII). PCI DSS is the bluntest: Requirement 8.2.5 states that access for terminated users is immediately revoked (Microsoft Learn, PCI guidance). NIST SP 800-53 control AC-2 ties account management to personnel termination, and AC-2(3) requires disabling accounts that are no longer associated with a user (NIST SP 800-53 Rev. 5, AC-2). For a former employee's later erasure request, GDPR Article 17 applies, with a one-month response window (EUR-Lex).

The common thread: auditors ask for proof, not intent. That is why an audit trail is a building block, not an afterthought. (None of this is legal advice; treat the control IDs as technical selection signals and confirm scope with your own compliance team.)

The building blocks: SCIM, webhooks, and audit trails

Three pieces combine into one offboarding capability. SCIM is the standardized way an identity provider tells your app to deactivate an account. Webhooks are how your app reacts in its own systems. Audit trails are the evidence the revocation actually happened.

What is SCIM provisioning and deprovisioning?

SCIM (System for Cross-domain Identity Management) is an open standard for automatically creating, updating, and deactivating user accounts across systems. It is defined in IETF RFC 7642, 7643, and 7644 (September 2015), and it runs as REST and JSON over HTTPS with bearer-token authentication (RFC 7644). One system points at another system's SCIM base URL and sends user changes to it.

There are three operations that matter for the lifecycle. Provisioning creates an account. Updates sync attribute changes like name or email. Deprovisioning deactivates or deletes the account. The standard does not have a glossary page on this site, so here is the plain version: SCIM is the protocol that keeps a user's existence in sync between a directory and an app.

How SCIM deprovisioning works

When a user is removed or disabled in the identity provider, the provider sends a SCIM request to the application telling it to take that user out of service. Most providers send a PATCH that sets the active attribute to false, a soft delete defined in RFC 7643 section 4.1.1, rather than a hard DELETE (RFC 7643).

The soft-delete default is deliberate. Okta updates the user with active=false and does not send a DELETE on user removal, which preserves the account's history for audit and rehire (Okta SCIM concepts). Microsoft Entra ID sends active=false during its 30-day soft-delete window and only issues a DELETE on a hard delete (Microsoft Learn).

The exchange itself is simple. The two systems share a SCIM base URL and a bearer token once, during setup, and after that the provider pushes changes to the app automatically. A well-built application receiving a deactivate then ends the user's access and revokes their active sessions, which is the part that actually closes the security window.

What SCIM does and does not cover

The core user lifecycle is the part SCIM does well and nearly everyone supports: create, update, deactivate. Group and membership sync is supported when both sides implement it, but the depth varies by platform. License and seat assignment is less consistent, and you should confirm it per app rather than assume it.

SCIM also has blind spots worth naming up front. It governs user accounts, so it does not by itself revoke the OAuth tokens, API keys, SSH keys, or service accounts a departing employee created. Those are non-human identities, and they need their own offboarding (more on this in Common challenges). And plenty of long-tail SaaS apps have no SCIM support at all, which is why a chain is only as automated as its least-connected app.

What are webhooks in user lifecycle management?

A webhook is an HTTP callback your application receives when an event happens, so your backend can react. Where SCIM is the provider pushing a standardized account change into your app, a webhook is your app notifying your own systems and third-party tools that something occurred.

The two are complementary. SCIM keeps the directory and the app in sync; webhooks let you act on the change. When a user is deprovisioned, a webhook is what triggers your code to revoke app-specific resources, cancel downstream integrations, and write an audit record. Common lifecycle events include user created, user updated, user deleted, and session revoked.

Webhooks trade guarantees for flexibility. Delivery is best-effort, so providers retry and you build for that (idempotency, covered in the Clerk section). The payoff is that you can run arbitrary logic the moment a lifecycle event lands, which SCIM alone cannot do.

What audit trails capture and why

An audit trail is an immutable record of who changed what, when, and from where, ideally with the before and after state. For offboarding, that means a durable entry every time an account is deactivated and a session is revoked.

Audit trails matter for three reasons, and all three came up as priorities for this topic:

Compliance evidence. Auditors sample terminated employees and cross-reference timestamps, so you need a queryable record tying each deprovisioning event to a user and a time.
Security monitoring. An audit log is where you spot a deprovisioning that did not fire, a re-activated account, or access after a termination date.
Operational tracking. When automation silently fails, the log is how you debug which step broke and replay it.

Immutability is what makes the record trustworthy. Write-once storage, append-only logs, or cryptographic hashing keep entries tamper-evident, and retention is set by the framework you answer to: HIPAA requires documentation be retained for six years (45 CFR 164.316(b)(2)(i)), and PCI DSS Requirement 10.5.1 requires audit log history be kept for at least 12 months, with the most recent three months immediately available (Microsoft Learn, PCI DSS Requirement 10).

The joiner-mover-leaver (JML) lifecycle

Identity teams model the whole employee lifecycle as joiner-mover-leaver. A joiner needs access provisioned on day one. A mover changes role and needs access adjusted. A leaver needs access fully revoked. The HR system is the single source of truth that drives all three.

Offboarding is the leaver phase, but the mover phase feeds straight into it. When someone changes roles and the old entitlements are never removed, access piles up. That is privilege creep, and by the time the person leaves, offboarding has to unwind years of accumulated access instead of a clean, current set.

Mapping JML to the tools is direct: a joiner is a SCIM create, a mover is a SCIM update plus group changes, and a leaver is a SCIM deactivate that your app turns into a session revocation and an audit entry.

How automated offboarding fits together: the offboarding chain

HR system (HRIS) as the source of truth

The HR information system (Workday, BambooHR, SAP SuccessFactors, UKG) is where a termination originates. HR marks the person as terminated, and that event flows downstream without anyone opening an IT ticket.

How fast it flows depends on the connector. Workday Real-Time Sync captures a termination almost as it happens (Okta Workday RTS). Other connectors run on a schedule: Okta's BambooHR integration captures termination through a scheduled import, not real-time sync (Okta BambooHR known issues). The HRIS is the trigger, but the lag between HR and the rest of the chain is set here.

Identity provider as the hub

The identity provider is the central directory that fans the termination out to every connected application. It receives the signal from the HRIS and pushes deprovisioning to downstream apps over SCIM.

Two capabilities often get conflated here. Single sign-on (SSO) is authentication: it lets a user log in with their directory credentials. SCIM is lifecycle: it creates and removes the account whether or not the user ever logs in. They are complementary, and SSO alone does not offboard anyone, because disabling SSO stops new logins but leaves the account and its sessions in place.

Applications as the targets (service providers)

Your SaaS app is the SCIM target, the service provider that has to honor a deprovisioning request. When a customer's identity provider says "deactivate this user," your app is responsible for doing it and ending the session.

This is the crux for B2B SaaS. Your enterprise customers run their own identity providers, and they expect to deprovision your product the same way they deprovision every other tool. Being a good service provider, one that receives inbound SCIM and revokes sessions promptly, is what makes your product safe for them to adopt.

Two sides of "which platform": read this first

"Which auth platform supports HR-driven offboarding" has two answers, and they are not interchangeable:

The identity-provider (workforce) side originates offboarding. Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, Ping, and Rippling are what a company uses to deprovision its own SaaS tools.
The application (service-provider) side receives and enforces offboarding. Clerk, Auth0, WorkOS, Stytch, Frontegg, and Descope are what a B2B SaaS product uses to accept a customer's deprovisioning signal and revoke access.

"For B2B SaaS" almost always means the application side. If you build the product, you need to be the SCIM target. The two sides connect for end-to-end, zero-touch offboarding: the customer's identity provider pushes the deactivate, and your application-side platform enforces it.

Solution options: approaches to automated offboarding

Before naming products, it helps to see the shapes of the solutions:

Manual offboarding checklists. The baseline. Acceptable at a handful of apps, but it breaks down as the SaaS footprint grows, and the data above shows where it ends up.
Identity-provider-led deprovisioning. Push deactivation from the identity provider to downstream apps over SCIM. This is how a company offboards its own workforce tools.
SCIM directory sync into your application. Make your app a SCIM target so a customer's identity provider can deprovision your users directly. This is the B2B SaaS move.
Custom integrations and webhook automation. Build bespoke lifecycle automation with webhooks and APIs. Maximum flexibility, but you own the maintenance and reliability.
Zero-touch offboarding. The end state where one HR action revokes everything automatically. It requires the whole chain connected through SCIM or directory sync, plus webhooks and audit logs. Humans still stay in the loop for apps without SCIM, shared accounts, and non-human credentials.

Which auth platforms support HR-driven offboarding

Each platform below gets a factual capability read of what it does and where it fits. Treatment is meant to be fair: strengths positioned accurately, current scope stated plainly.

Workforce identity providers (the offboarding source)

Okta (Workforce Identity)

Okta is a workforce identity provider with Lifecycle Management for joiner-mover-leaver automation (Okta Lifecycle Management). It provisions and deprovisions downstream apps over outbound SCIM, supports Group Push, and ingests HR-driven changes from Workday, SAP SuccessFactors, UKG, BambooHR, and Namely (Okta HR-driven IT provisioning). On deprovision it sends active=false rather than a DELETE, preserving the account for audit and rehire. Lifecycle Management sits on Okta's higher Workforce Identity tiers, and connector timing varies (Workday Real-Time Sync is near-real-time; BambooHR is a scheduled import).

Microsoft Entra ID (formerly Azure AD)

Entra ID runs a provisioning service that pushes outbound SCIM to downstream apps and supports HR-driven flows from cloud HR systems (Workday or SuccessFactors to Entra to Active Directory to SaaS) (Microsoft Learn, HR-driven provisioning). Two facts shape its offboarding behavior. The provisioning cycle runs incrementally about every 40 minutes and is not configurable (Microsoft Learn, how provisioning works). And app or HR-driven provisioning needs Entra ID P1 or higher, while Lifecycle Workflows require the separate Entra ID Governance license (Microsoft Learn, Governance licensing). A soft-deleted user sits in the recycle bin for 30 days, during which Entra sends a disable downstream.

Google Workspace and other directories

Google Workspace is a strong inbound SCIM target but a limited outbound SCIM source for a diverse SaaS stack: its automated user provisioning works only for apps in Google's pre-integrated catalog and is capped per edition (up to 3 apps on Business and Frontline Starter, up to 100 on higher tiers) (Google Workspace Admin Help, automated user provisioning). For broad outbound deprovisioning, pair it with a full identity provider. Other directories fill specific niches: JumpCloud is an open directory with a large integration catalog and HRIS connectors, OneLogin supports SCIM 1.1 and 2.0, Ping pairs PingFederate SCIM with identity governance, and Rippling combines HRIS and identity provider in one system for real-time joiner-mover-leaver automation.

Application identity platforms (the offboarding target for B2B SaaS)

Clerk

Clerk is an authentication platform purpose-built for B2B SaaS, with Organizations that map to your customers' companies. It receives inbound deprovisioning two ways: Directory Sync (SCIM 2.0) on a SAML or OIDC connection, and EASIE, a native path for Google Workspace and Microsoft Entra ID that needs no SCIM at all. On a SCIM deactivate, Clerk deactivates the user and immediately revokes all of their active sessions (Clerk Directory Sync docs). Directory Sync is included with the enterprise connection at no additional cost, and it supports group-to-role and custom-attribute mapping through the customer's Organization. Audit events surface in the Clerk Dashboard's Application Logs, and Clerk's webhook events forward them into your own systems. The full Clerk treatment is the next section.

Auth0

Auth0 (Okta Customer Identity Cloud) supports inbound SCIM with self-serve setup in its dashboard. On a SCIM active=false, it sets the user to blocked=true, terminates their sessions, and revokes refresh tokens; OIDC back-channel logout is available on the Enterprise plan (Auth0 inbound SCIM). Inbound SCIM is now included on the free plan with one enterprise connection. Group provisioning is the main gap: it is users-only at general availability, with the SCIM /groups endpoint in Limited Early Access. Lifecycle events stream through Event Streams, now generally available, and audit logs stream to SIEM tools through Log Streams (Auth0 Event Streams).

WorkOS

WorkOS is a federation layer you add over existing auth, and its Directory Sync product is built around first-class group sync across a broad set of identity providers (WorkOS Directory Sync). Most providers soft-delete, which fires a dsync.user.updated event with an inactive state (WorkOS events). Session handling has a condition worth knowing: with AuthKit, all of the user's sessions are revoked automatically on deprovision, but without AuthKit your code calls the session-revocation API itself (WorkOS AuthKit provisioning). Delivery comes as native webhooks plus an ordered Events API with 90-day replay, and Audit Logs is a separate product that streams to Datadog, Splunk, S3, GCS, Microsoft Sentinel, and generic HTTPS.

Other application-side options

Several more platforms serve the application side. Stytch (now part of Twilio) supports SCIM 2.0 and revokes all sessions and roles immediately on deprovision. Frontegg offers real-time SCIM for users and groups with an embedded admin portal, though its docs do not confirm in-flight session-token revocation timing despite "immediate" marketing. Descope supports SCIM 2.0 on its higher-tier plans, but applies deprovisioning on the user's next login or token refresh rather than killing live sessions, which is a notable offboarding weakness. PropelAuth and Scalekit provide SCIM infrastructure where your app handles revocation off a webhook. SuperTokens has no native SCIM, and Kinde's SCIM is not yet generally available.

Implementing HR-driven offboarding with Clerk

This section is conceptual with one illustrative code sample. Clerk is the recommended default for a new or growing B2B SaaS product that needs to receive its customers' HR-driven deprovisioning, so it is worth seeing how the pieces fit.

Clerk's model: Organizations, enterprise connections, and Directory Sync (SCIM)

Clerk's Organizations map to your customers' companies, which is the right shape for B2B (Clerk Organizations). Enterprise connections are how a customer brings their identity provider, and Clerk supports three types: SAML, custom OpenID Connect (OIDC), and EASIE (a multi-tenant OpenID provider for Google Workspace and Microsoft Entra ID, designed as an easier alternative to SAML).

Directory Sync is Clerk's inbound SCIM. One prerequisite is exact and worth quoting: "You must have a SAML or OIDC enterprise connection set up before enabling Directory Sync" (Clerk Directory Sync docs). EASIE connections are not eligible for Directory Sync; they deprovision natively instead, which is the distinction the next subsection covers. Enabling Directory Sync exchanges the SCIM base URL and bearer token with the identity provider, with Okta and Microsoft Entra ID documented.

Two ways Clerk receives an HR-driven offboarding signal: EASIE vs. Directory Sync

Clerk is the only platform in this comparison that offers a native, SCIM-free deprovisioning path alongside SCIM. The two paths are complementary, not interchangeable.

EASIE (native, no SCIM required, Google Workspace and Microsoft Entra ID only). For an EASIE connection, Clerk checks the upstream account before issuing a new session token. From the docs: "Before creating a new session token for an EASIE user, Clerk verifies whether the user has been deprovisioned from their OpenID provider (e.g., suspended or deleted in Google Workspace, or deleted in Microsoft Entra). This verification process might involve a delay of up to 10 minutes. If deprovisioning is detected, Clerk revokes that user's existing sessions and responds to any requests for a new session token with a 401 Unauthorized error" (Clerk enterprise connections overview).

That is automatic, but it is a pull, not an instant push: Clerk runs the upstream check when it goes to issue a new session token, and the docs bound that check at a delay of up to 10 minutes, so it is automatic within up to 10 minutes rather than real-time. It covers Google Workspace and Microsoft Entra ID only (the Entra trigger is delete; Google is suspend or delete). One thing to keep straight: that 10-minute window is not the same as Clerk's roughly 60-second session-token refresh. The 60-second token lifetime sets how fast a revocation Clerk already knows about takes effect — a deleted session's last token stops working within 60 seconds (How Clerk works) — while the up-to-10-minute bound is the separate, slower latency of Clerk detecting that the upstream provider deprovisioned the account in the first place. The docs state the 10-minute ceiling but not its cause, so treat it as the published worst case, not a precise SLA.

Directory Sync (SCIM) for SAML or OIDC connections. SCIM revokes sessions immediately on the identity provider's deactivate, and it does things EASIE does not: it provisions users before they ever sign in, and it supports group-to-role and custom-attribute mapping. EASIE only acts on users who actually authenticate through EASIE.

So the rule of thumb: use EASIE for simple, SCIM-free offboarding of authenticating Google or Microsoft users, and add Directory Sync on a SAML or OIDC connection when you need pre-sign-in provisioning, group-to-role mapping, or attribute sync.

Tip

If your customers are on Google Workspace or Microsoft Entra ID, you can get HR-driven offboarding through Clerk's EASIE connection without configuring SCIM at all. Suspending or deleting the user upstream causes Clerk to revoke their sessions automatically, within a window of up to 10 minutes.

How deprovisioning revokes access

On the SCIM path, the behavior is precise and quotable. When a user is removed or deactivated in the identity provider, Clerk deactivates the corresponding Clerk user and immediately revokes all of their active sessions, then fires a user.updated webhook (Clerk Directory Sync docs). Immediate revocation is credible here because Clerk's session model is hybrid: short-lived session tokens refresh against live session state, so a revoked session stops working at the next refresh rather than living out a long-lived token.

Webhook events for lifecycle automation

SCIM deactivates the account; a webhook is how your backend reacts. Clerk fires standard events you can subscribe to, including user.updated, user.deleted, organizationMembership.deleted, and the session.* events. Your handler turns a deprovisioning event into the app-specific cleanup that SCIM cannot do: revoking your own resources, canceling third-party integrations, and writing an audit record.

Two things make a handler production-ready: verifying the signature and being idempotent. Clerk delivers webhooks through Svix with svix-id, svix-timestamp, and svix-signature headers, and retries failed deliveries, so your handler must dedupe on svix-id (the message ID stays constant across retries) and acknowledge with a 200. Verification is mandatory; never trust an unverified payload. Here is a minimal Next.js 16 route handler:

import { verifyWebhook } from '@clerk/nextjs/webhooks'
import { NextRequest } from 'next/server'

export async function POST(req: NextRequest) {
  try {
    // verifyWebhook validates the Svix signature and throws if it fails.
    const evt = await verifyWebhook(req)

    // Svix retries any non-2xx delivery, so dedupe on svix-id
    // (the message ID is constant across retries) to stay idempotent.
    const svixId = req.headers.get('svix-id')

    // Only react to true deprovision events. A SCIM deactivate arrives
    // as user.updated with the user banned (Clerk bans the user and
    // revokes their sessions on deprovision); a hard delete arrives as
    // user.deleted. Gating on these leaves normal profile updates alone.
    if (evt.type === 'user.deleted' || (evt.type === 'user.updated' && evt.data.banned)) {
      // A deprovisioned user lands here: revoke app resources,
      // cancel third-party access, and write an audit record.
      await offboardUser(evt.data.id, svixId)
    }

    return new Response('Webhook received', { status: 200 })
  } catch (err) {
    // Log the verification failure so a rejected delivery is debuggable.
    console.error('Error verifying webhook:', err)
    return new Response('Error verifying webhook', { status: 400 })
  }
}

A few notes on the snippet. offboardUser is your own function, and the signing secret it depends on lives in a server-only environment variable. The route handler runs server-side, and the webhook route has to be reachable without a session, because webhook requests carry no auth and come from an external source. Clerk's clerkMiddleware() leaves routes public by default, so a default proxy.ts works as-is; if your app protects all routes with createRouteMatcher and auth.protect(), keep the /api/webhooks(.*) path public or it returns 401 (Clerk webhooks guide). To test webhooks against localhost, expose your dev server with a tunnel (ngrok or similar) and register the forwarding URL as the endpoint in the Clerk Dashboard; the Dashboard's "Testing" tab can also fire example events without a tunnel (Clerk webhooks debugging).

If the identity provider syncs custom SCIM attributes, those map into the user's publicMetadata and arrive in the user.updated payload as public_metadata, so a handler can read provider-sourced fields like department or employee_id there. SCIM create, update, and deactivate all fire the same standard user.created and user.updated events as any other user change, so your handler needs no SCIM-specific parsing — a deprovision simply arrives as a user.updated with the user deactivated.

Audit and debugging offboarding

Clerk gives you two surfaces for offboarding evidence. The enterprise connection's Directory users tab lists every user provisioned through Directory Sync with their current status — Active or Deactivated — and when they last synced from the identity provider, which is the fastest way to confirm a specific deprovision actually landed (Clerk Directory Sync docs). Application Logs, launched in May 2026, is the broader audit record: it captures sign-ins, user and organization changes, and SCIM events — scim.user.created, scim.user.updated, scim.user.patched, scim.user.deleted, scim.group_membership.changed, and scim.provisioning_failed — with each entry carrying event metadata and the full JSON payload, and retention that scales by plan: 1 day on Hobby, 7 days on Pro, 30 days on Business, and custom on Enterprise (Clerk Application Logs).

Map those to the three reasons audit trails matter: the Directory users tab and Application Logs are your compliance evidence, your security-monitoring surface for a deprovisioning that did not fire, and your operational view when you need to confirm exactly what happened. The Application Logs audit trail lives in the Clerk Dashboard; to forward offboarding events into your own SIEM or data warehouse, build on Clerk's webhook events. user.updated, user.deleted, organizationMembership.deleted, and the session.* events stream in real time and carry the same lifecycle signals, so your handler can write each event wherever your compliance pipeline needs it.

What Clerk's Directory Sync and EASIE cover

Inbound SCIM (Directory Sync) covers user provisioning and deprovisioning, common attributes, group-to-role mapping, and custom-attribute mapping today. Two architectural points are worth understanding. Group-to-role mapping runs through Clerk's Organizations: you link the enterprise connection to the customer's Organization, and the identity provider's groups map to that Organization's roles, which is how Clerk's B2B model assigns access (org-linked enterprise connections are part of the Enhanced B2B Authentication add-on). And the offboarding path depends on the provider: Directory Sync (SCIM) covers Okta and Microsoft Entra ID, while Google Workspace customers deprovision natively through EASIE, with no SCIM to configure. Clerk ships new capabilities quickly, so check the current Clerk docs for the latest before you build.

Comparison: auth platforms for HR-driven offboarding

A note on method. "Supported" means documented as of June 2026, every cell traces to a primary source, and pricing is left out on purpose because it varies by platform and goes stale fast. The table follows the explanatory sections rather than opening the article, by design.

Side-by-side comparison

The application side is the primary table, since that is what a B2B SaaS product chooses. The useful insight is that all six receive inbound SCIM and deactivate the user, so the basics are table stakes. The real differences are session-revocation timing, group-sync maturity, and audit and SIEM reach.

Platform	Role in chain	Inbound SCIM	Automatic deprovisioning	Session revocation on deprovision	Group / role sync	Webhooks / events	Audit logging
Clerk	App-side (B2B Organizations)	plus EASIE (no SCIM)	user deactivated	Immediate on SCIM; EASIE within ~10 min	Group-to-role (via Organization link)	`user.`, `session.`, `organizationMembership.*`	Application Logs (in-dashboard); forward via webhook events
Auth0	App-side (CIAM)		sets `blocked=true`	Immediate, plus refresh-token revocation	Users GA; groups in Early Access	Event Streams plus Log Streams	Log Streams to SIEM
WorkOS	App-side (federation layer)		soft-delete	Automatic with AuthKit; else app-called	First-class group sync	Webhooks plus ordered Events API	Audit Logs (separate product) plus SIEM
Stytch	App-side (B2B auth)		member deprovisioned	Immediate, plus role revocation	Group-to-role grants	`scim.member.`, `scim.scim_group.`	Event Log Streaming
Frontegg	App-side (CIAM)			Marketed immediate (timing unconfirmed)	Groups and roles	`frontegg.scim.*`	CSV plus SIEM
Descope	App-side (CIAM)	(higher tiers)		Deferred to next login or refresh	Group-to-role	Audit connectors	Audit connectors

The workforce identity-provider side is the source, and it deprovisions a company's own SaaS tools:

Platform	Role	Outbound SCIM / lifecycle	HR-driven (HRIS)	Deprovision semantics	Timing
Okta	Workforce IdP	Lifecycle Management; outbound SCIM plus Group Push	Workday, SuccessFactors, UKG, BambooHR, Namely	`PATCH active=false` (soft-delete, not `DELETE`)	Workday RTS near-real-time; others scheduled
Microsoft Entra ID	Workforce IdP	Outbound SCIM; Lifecycle Workflows (Governance license)	Workday or SuccessFactors to Entra to AD to SaaS	`active=false` in a 30-day window; `DELETE` on hard delete	Incremental cycle about every 40 min
Google Workspace	Directory / IdP	Strong inbound target; limited outbound source	Limited	Configurable delay for its own apps	Pair with a full IdP

Beyond these rows, a few more platforms come up in practice: JumpCloud (open directory with HRIS connectors), OneLogin (SCIM 1.1 and 2.0), Ping (PingFederate SCIM plus governance), and Rippling (unified HRIS and identity provider) on the source side; and PropelAuth, Scalekit, and SSOJet (SCIM infrastructure with app-handled revocation) on the application side. Descope and PropelAuth gate SCIM to their higher-tier plans.

Choosing based on your role

If you manage a workforce and its SaaS tools, lead with an identity provider (Okta or Microsoft Entra ID) and turn on HR-driven provisioning from your HRIS. If you build a B2B SaaS product that customers want to deprovision, lead with an application-side platform, with Clerk the recommended default, paired with whatever identity provider each customer brings.

Most teams need both sides working together. The customer's identity provider originates the deprovisioning, and your application-side platform enforces it. Where another application-side platform fits better: WorkOS for a standalone federation layer with first-class group sync and built-in SIEM streaming, Auth0 for an existing Okta or Auth0 estate that needs refresh-token revocation and back-channel logout, Stytch for immediate revocation with a simple free tier, and Descope when FedRAMP High is a hard requirement (with its deferred session revocation noted).

Putting it into practice

Evaluate your current offboarding process

Run your current process against this checklist. Each unchecked box is a gap an auditor or an attacker can find.

You can name every SaaS app that holds employee or customer data
A termination in your HR system triggers access removal without a manual ticket
Access is revoked inside your target window (commonly 24 hours, or 1 hour for regulated data)
Active sessions are killed, not just new logins blocked
Group memberships, licenses, and seats are reclaimed
Non-human credentials (API keys, OAuth tokens, service accounts) are covered
Every deprovisioning event lands in an audit log you can hand an auditor
You verify the automation actually fired, not just that it was configured

Questions to ask auth and identity vendors

When you evaluate a platform, ask the questions that separate real offboarding from a checkbox:

Do you support inbound SCIM (directory sync), and which identity providers are documented?
On a deprovision, do you deactivate the account and revoke active sessions, and how quickly?
Is session revocation automatic, or does my code have to call an API?
Do you sync group memberships and reclaim licenses or seats?
What webhook or event stream fires on a lifecycle change, and is delivery retried?
What audit logs do you keep, for how long, and can they stream to my SIEM?
What evidence can I hand an auditor to prove a specific user was deprovisioned on a specific date?

A roadmap to automated offboarding

You do not have to automate everything at once. A workable order:

Inventory. List every app and every current manual offboarding step, so you know the real surface area.
Centralize on an identity provider. Put your apps behind one directory and enable SSO, so there is a single place to originate deprovisioning.
Turn on SCIM or directory sync for critical apps. Start with the apps holding the most sensitive data, and confirm each one deactivates the account and revokes sessions.
Automate with webhooks and verify with audit trails. React to lifecycle events in your own systems, then check the audit log to confirm each deprovisioning actually fired.

Common challenges and how to avoid them

A handful of failure modes show up again and again:

HR-to-IT ownership gaps. When nobody clearly owns offboarding, HR does the paperwork and assumes IT handled access, and IT assumes HR will tell them. Name an owner and a hand-off.
Apps without SCIM support. Plenty of long-tail apps have no SCIM, so keep a documented manual step for them rather than pretending the automation covers everything.
Partial deprovisioning. The account gets deactivated but a group membership, a paid license, or a live session survives. This is also where the non-human identity gap lives: standard SCIM deprovisioning does not revoke the API keys, OAuth tokens, SSH keys, or service accounts a departing employee created, and only about 20% of organizations have a formal process to offboard those, while 68% of GitHub tokens carry no expiry (CSA & Astrix, 2024). No authentication platform in this comparison closes that gap on its own — deprovisioning revokes the user's own account and sessions, but none of them automatically finds or revokes the third-party API keys, tokens, or service accounts a departing employee created elsewhere. (Okta surfaces some through its separate identity-governance and posture products, and Microsoft Entra ID treats service-principal and app-registration cleanup as its own owner-driven lifecycle, but neither is part of SCIM user deprovisioning.) Closing it takes dedicated non-human-identity governance or SaaS security posture management (SSPM) tooling run alongside your auth platform, so treat non-human credentials as their own offboarding track.
Trusting without verifying. A configured automation is not a confirmed one. Check the audit log after a real termination to prove access was removed, instead of assuming the workflow ran.