Every CISO has lived this story at least once: an employee left six weeks ago, was marked "departed" in the HR system, their AD account was disabled. Then you pull a list for an audit — the same person signed into Salesforce twice after leaving, edited a page in Notion, and still has GitHub access. The offboarding procedure didn't work. The reason is rarely just one thing: in the SaaS world, the exit itself is a fragmented problem.
This piece explains why offboarding has become an invisible security gap, why the "lastLogon" field is less honest than you think, and what it takes to genuinely close the exit.
The real size of the problem
The average corporate employee today touches 40–90 SaaS applications — those connected through SSO, those connected through Google/Microsoft accounts, those registered directly with corporate email. When IT can only close the SSO layer at exit:
- 15–20 SSO-managed apps close.
- 15–30 apps that aren't on SSO but are registered with corporate email remain open.
- 10–20 shadow SaaS apps bought on a personal card but used for corporate work aren't even on IT's radar.
Net result: your exit is complete on paper; in reality, more than 50% of the access remains open.
lastLogon is a misleading single source of truth
The field IT teams most often turn to when working with Active Directory is lastLogon: "when did this user last sign in?". Unfortunately, this field is written on a single domain controller and is not automatically replicated to other DCs. It's clearly documented in AD; in practice, IT teams routinely forget.
Practical consequence: in an org with 3 DCs, a single user's lastLogon might read "47 days ago" on DC-Istanbul, "2 days ago" on DC-Frankfurt, "14 days ago" on DC-London. Query a single DC and you get the wrong answer. If your offboarding decision is "we can close this account, it hasn't been used in 47 days," you mis-judged an account that was active 2 days ago.
JML in 5 categories: 'active' and 'inactive' isn't enough
The traditional "Joiner/Mover/Leaver" approach reduces identity to two states: active or inactive. In reality there are five categories, each with its own action list:
- Joiner — newly arrived. No SaaS access yet; provisioning list to satisfy.
- Mover — changed role. Old access might still be open; their entitlements may not have been migrated. Most organisations don't track this category at all.
- Idle — stopped using but still in the org. Wasted licence, security risk.
- Leaver — orphaned — has left but is still active in some SaaS. The critical category.
- Leaver — closed — has left and access has been shut everywhere. The target state.
A system that reports these five categories lets you audit "left-but-still-active" (orphaned) every month. A system that collapses to two makes that class invisible.
How to make your exit procedure real
1. User-centric inventory
Instead of counting each SaaS separately, gather every user's full SaaS footprint into a single profile. CenseCloud does this through DISTINCT username — correlating endpoint agent + browser extension + IdP signals.
2. Multi-DC lastLogon MAX
Separate read from every DC, MAX timestamp. Don't let replication delay mislead you.
3. SSO-eliminated tracking
SSO is closed — but is the user still signing in directly with email/password? Track these as a separate category; SSO removal is not a security guarantee.
4. Monthly orphan audit
Once a month, pull the "left-but-still-active" list. Until it reaches zero, your offboarding process is not complete.
Conclusion: before saying "closed", you have to see
IT has the authority to close an AD account; but in the SaaS world AD is a source, not the authority. SaaS exit requires identity inventory that's also fed from the endpoint and the browser. Otherwise "closed" is just a piece of paper.
CenseCloud builds this inventory through multi-DC AD reads + endpoint agent + browser extension. See the identity & access solution or the CenseRisk module for details.