Notifications
Clear all
Topic starter
10/06/2026 11:30 pm
TL;DR: SSO and identity providers still leave a structural “API gap” in SaaS governance, because many apps cannot be governed end to end and offboarding remains manual, error-prone, and blind to orphaned access, according to Josys. That makes lifecycle coverage, not login consolidation, the real control boundary.
NHIMG editorial — based on content published by Josys: Achieving Zero-Touch Security, Why SSO Isn't Enough for Secure Employee Offboarding
By the numbers:
- The average business now utilizes over 254 different SaaS applications across its ecosystem.
Questions worth separating out
Q: What breaks when SSO is used as the only offboarding control?
A: SSO breaks down as an offboarding control when the organisation assumes authentication coverage equals lifecycle coverage.
Q: Why do unsupported SaaS apps complicate employee offboarding?
A: Unsupported SaaS apps complicate offboarding because the identity team cannot rely on the normal connector model to remove access or verify entitlement changes.
Q: How do security teams know if offboarding is actually working?
A: Offboarding is working only when teams can prove that accounts, admin roles, tokens, and permissions were removed across all relevant systems, including unsupported ones.
Practitioner guidance
- Inventory unsupported applications before the next offboarding cycle Build a list of SaaS, custom, and legacy applications that sit outside native connector coverage.
- Define a fallback deprovisioning path for every API gap Document what happens when an app cannot be governed through the directory or IGA tool.
- Align HR and identity sources before automating offboarding Confirm which system is authoritative for leaver status, then test that the signal propagates reliably to downstream apps.
What's in the full article
Josys's full blog post covers the operational detail this post intentionally leaves for the source:
- How the AI Integration Builder learns workflows from browser actions and extracts app data without a native connector
- How Multi-Source Identity Enrichment links HR and identity systems to trigger deprovisioning on leaver events
- How App Script is used to build custom integrations for systems outside standard connector libraries
- The Francom Group example showing how the integration approach was applied to close offboarding gaps
👉 Read Josys's analysis of zero-touch offboarding and the SaaS API gap →
API gaps in employee offboarding: what IAM teams are missing?
Explore further
12/06/2026 5:35 am
SSO is not an offboarding control by itself. The article makes a familiar governance point: central authentication does not equal complete lifecycle enforcement. SSO reduces login sprawl, but it does not solve unsupported apps, shallow APIs, or disconnected permission models. Practitioners should treat offboarding as a deprovisioning problem across the full application estate, not as an identity provider setting.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, which increases the chance that offboarding misses a hidden copy or stale token.
A question worth separating out:
Q: Who is accountable when an employee keeps access after departure?
A: Accountability sits with the identity, application, and business owners who failed to ensure deprovisioning completed across the full application estate. The problem often spans HR signals, IAM execution, and app ownership, which is why offboarding governance needs clear ownership and evidence. In regulated or audited environments, incomplete revocation becomes a control failure, not just an operational miss.
👉 Read our full editorial: Zero-touch employee offboarding exposes the API gap in SaaS governance
