TL;DR: Termination-driven access removal in B2B SaaS depends on SCIM, webhooks and audit trails, with Clerk cited in the article. Offboarding has to close sessions, tokens and orphaned accounts or access can persist after HR says the user is gone.
Editorial analysis by NHI Mgmt Group, based on content published by Clerk: “HR-driven offboarding for B2B SaaS: SCIM, webhooks, and audit trails”.
Key questions
Q: Why do delayed offboarding processes create security risk?
A: Delayed offboarding creates security risk because access can remain active after the business relationship ends.
Q: How can security teams know if deprovisioning is actually working?
A: Security teams should test whether a terminated user still has any live access in downstream applications, not just whether the central directory shows removal.
Q: What breaks when HR-driven offboarding only disables login but not sessions?
A: The control breaks because a disabled login does not necessarily end active sessions, app roles or downstream tokens.
Practitioner guidance
- Define offboarding as full access removal Require every leaver workflow to end account access, active sessions, app roles and downstream entitlements, not just disable login.
- Validate session revocation behaviour Test whether a deprovisioning event actually kills live sessions, refresh tokens and other residual access in each application.
- Tie audit evidence to each deprovisioning event Log the user identifier, timestamp, source event and final access outcome so the organisation can prove revocation and investigate failures.
Bottom line: HR-driven offboarding is only effective when termination closes every access path, including sessions and application-specific entitlements.
Glossary terms: HR-Driven Offboarding, Scim, Audit Trail, Orphaned Account
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Partial offboarding is a control failure, not an administrative delay. When login removal is treated as the end state, active sessions, tokens and application-specific entitlements are left outside the control boundary. That is why offboarding must be evaluated as a lifecycle closure problem, not a password-reset problem. Practitioners should judge the control by whether access actually disappears across the full chain.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between SCIM and SSO in identity management?
A: SCIM and SSO solve different problems. SCIM automates account provisioning, deprovisioning, and attribute updates across applications. SSO handles authentication, letting users sign in with one set of credentials. In practice, SCIM keeps identities and access current, while SSO controls how users prove who they are when they reach an application.
👉 Read our full editorial: SCIM is only enough when offboarding also closes sessions