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

This is Part 1 of a two-part series on HR-driven offboarding for B2B SaaS. This part covers the foundational concepts: why automated offboarding matters, the building blocks of SCIM, webhooks, and audit trails, and a survey of the vendor landscape across workforce identity providers and application identity platforms. Part 2 covers the implementation details using Clerk, comparison tables, and an evaluation checklist.

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, and compares them fairly. Part 2 adds an evaluation checklist, a list of vendor questions, and an implementation roadmap. Read it to assess your current process and pick the right platform.

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 Part 2). 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 Part 2). 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:

1. 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.
2. 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.
3. 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:

1. 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.
2. 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.
3. 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.
4. Custom integrations and webhook automation. Build bespoke lifecycle automation with webhooks and APIs. Maximum flexibility, but you own the maintenance and reliability.
5. 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⁠). Automated user provisioning to SaaS apps is available even on Entra ID Free, while HR-driven (inbound) provisioning needs Entra ID P1 or higher and 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 Starter 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 in Part 2.

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 supported as well: the SCIM /Groups endpoint handles group create, update, and delete, mapping synced groups to tenant- or organization-level roles (group members must be users, so nested groups are not synced). 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.

This concludes Part 1's conceptual overview and platform survey. Part 2 moves from theory to practice, covering how to implement HR-driven offboarding with Clerk, detailed comparison tables of the platforms discussed here, and a roadmap for evaluating your own offboarding process.

Frequently asked questions

In this series

1. HR-driven offboarding for B2B SaaS: SCIM, webhooks, and audit trails (you are here)
2. HR-driven offboarding for B2B SaaS: SCIM, webhooks, and audit trails - Part 2