Notifications
Clear all
Topic starter
05/07/2026 10:45 pm
TL;DR: Leaving former employee accounts active creates a compounded risk of unauthorised access, data exfiltration, compliance failures, and wasted licence spend, according to Josys. The control gap is not awareness but execution: offboarding has to revoke access across IdP, SaaS, API keys, and devices before the account remains usable.
NHIMG editorial — based on content published by Josys: How to Delete Offboarding Employee Accounts
By the numbers:
- The average company uses more than a 100 SaaS applications, meaning it's not unusual for dozens of accounts per departing employee to require deletion.
Questions worth separating out
Q: What breaks when ex-employee accounts are not deleted promptly?
A: Delayed deletion leaves former employees able to authenticate after departure, which can enable data exfiltration, unauthorized access, audit findings, and avoidable licence costs.
Q: Why do ex-employee accounts create both security and compliance risk?
A: Active departed-user accounts can be used to reach confidential data and also fail access-removal obligations in GDPR, ISO 27001, SOC 2, and similar frameworks.
Q: What do security teams get wrong about SaaS offboarding?
A: The common mistake is assuming that disabling one root login, such as SSO or email, removes all access.
Practitioner guidance
- Map every departure to a complete access inventory Build the offboarding workflow so HR notice triggers a full inventory of IdP, SaaS, cloud, VPN, device, shared account, and API access tied to the departing person.
- Revoke access at the application layer on day of departure Do not rely on SSO deactivation alone.
- Separate archive retention from access termination Preserve emails, files, and chat history according to legal and operational retention requirements, but move them into controlled archives that the former employee cannot reach.
What's in the full article
Josys's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step deletion sequence for IdP, email, SaaS, VPN, and device access across a departing employee's full account set
- Practical handling of archiving windows, retention obligations, and the difference between deactivation and full deletion
- Tool-specific notes for Microsoft Entra ID, Google Workspace, Okta, SailPoint, and SaaS management automation
- Common failure patterns such as missed department-owned apps, shared accounts, and undeleted API keys
👉 Read Josys's guide to deleting ex-employee accounts and closing offboarding gaps →
Ex-employee account deletion: are your offboarding controls complete?
Explore further
05/07/2026 10:48 pm
Account persistence is a lifecycle failure, not just an offboarding miss. The article shows that departing employees often retain access because deletion is fragmented across IdP, SaaS, cloud consoles, and tokens. That is a governance problem in the access lifecycle, where the organisation believes departure closes access automatically. Practitioners should treat any active post-exit account as evidence that lifecycle ownership is incomplete.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations prove that offboarding actually worked?
A: They should keep a deletion record that shows who removed each account, when it was removed, which systems were touched, and what approval supported the action. A good process also checks for residual access after departure and records archiving separately from deletion. If you cannot produce the evidence, you cannot demonstrate control.
👉 Read our full editorial: Ex-employee account deletion is the core offboarding control
