Ex-employee account deletion is the core offboarding control

At a glance

What this is: This is a practical offboarding guide on deleting ex-employee accounts, with the key finding that lingering access across SaaS, cloud, and API credentials creates avoidable security, compliance, and cost risk.

Why it matters: It matters because offboarding is one of the few identity processes that directly spans human access, non-human credentials, and lifecycle control, so gaps here can leave both people and machine access active after departure.

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.

👉 Read Josys's guide to deleting ex-employee accounts and closing offboarding gaps

Context

Ex-employee account deletion is the offboarding control that removes access after employment ends, and it is only effective when the whole account surface is covered. In SaaS-heavy environments, that surface now includes identity providers, collaboration tools, cloud consoles, API tokens, and device access, so the problem is broader than email closure or laptop return.

The governance failure is usually not the lack of a process on paper, but the gap between departure and actual revocation. That gap creates account persistence, which can support exfiltration, unauthorized access, audit findings, and license waste. For teams responsible for identity lifecycle, this is the same discipline applied to human accounts and non-human credentials in one workflow.

Key questions

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. The failure is usually not one control but several, including incomplete SaaS deprovisioning, missed API tokens, and weak record keeping. Offboarding has to close every active access path, not just the corporate directory.

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. That makes offboarding a governance control, not just an IT task. If the organisation cannot prove revocation, it may face breach exposure and audit issues at the same time.

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. Many SaaS tools retain local sessions, vendor accounts, shared logins, or separately issued tokens. Teams also underestimate department-owned tools, which means the inventory is incomplete before revocation even begins.

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.

Technical breakdown

Why account persistence creates a post-exit access window

Account persistence occurs when a former employee's access remains technically valid after the employment relationship has ended. In practice, this can happen because SSO is cut off while local SaaS login still works, a personal API token remains active, or a shared account was never changed. The result is a divided control plane where identity state, application state, and device state do not close together. That is why offboarding has to be treated as a coordinated identity event rather than a single administrative task.

Practical implication: verify deactivation at the application level, not just in the identity provider.

Why API keys and third-party access need explicit revocation

Ex-employee deletion is not complete if developer tokens, admin keys, partner logins, or vendor portal access remain live. These credentials often sit outside standard employee workflows, so they are easy to miss when the owner leaves. Unlike interactive user accounts, they may not trigger obvious login activity, which makes them harder to detect after the fact. In identity governance terms, this is where lifecycle control has to extend beyond human directories into the non-human and delegated access layer.

Practical implication: inventory and revoke non-interactive credentials as part of every offboarding case.

How deletion, archiving, and audit logs fit together

Deletion does not mean immediate destruction in every system. The article describes a staged model of deactivation, archiving, and eventual full deletion, with retention rules shaping how long data must remain available. That matters because legal hold, HR records, and operational continuity can all require different treatment. The technical requirement is to preserve the evidence trail while ensuring the departed user can no longer authenticate or re-enter the environment through any retained system.

Practical implication: separate access removal from data retention and keep deletion records for audit.

NHI Mgmt Group analysis

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.

Ex-employee access and NHI governance now fail in the same place: residual credentials. The article's strongest signal is that API keys, personal tokens, and shared credentials are part of the same offboarding surface as human accounts. That aligns with OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 focus on access control and asset visibility. The implication is that identity lifecycle cannot be built as a human-only workflow anymore.

Standing access after departure is the wrong assumption for modern SaaS estates. Offboarding processes were designed for environments where identity ownership was easier to map and fewer apps held independent login state. That assumption fails when the actor can still authenticate through multiple SaaS layers after the HR system says the relationship is over. The implication is that revocation must be provable across every credential type, not inferred from one control plane.

Lifecycle blind spots turn offboarding into a cost and compliance multiplier. The article links undeleted accounts to audit issues, legal exposure, and recurring licence charges. That combination matters because the same missing control creates security risk and financial leakage at the same time. Practitioners should view offboarding as a control that protects both the trust boundary and the software estate.

NHI lifecycle discipline belongs inside offboarding design, not beside it. The article makes clear that personal tokens, vendor accounts, and cloud admin credentials must be removed with the same rigor as employee email and directory access. This is where the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs are directly relevant. The practical conclusion is that offboarding checklists should be credential-type aware, not role-only aware.

From our research:

• 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.
• For a broader control view, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding belong to the same lifecycle.

What this signals

Account deletion is becoming a cross-domain identity problem. The same offboarding event now has to close human access, revoke non-human credentials, and prove that archive data is inaccessible to the departed user. Teams that still separate IAM, SaaS administration, and NHI governance will keep finding residual access after the employment relationship has ended.

The practical signal is that lifecycle automation will matter more than manual checklist discipline. When departments use dozens of SaaS tools and developers issue their own tokens, offboarding quality depends on whether the identity programme can see and revoke every access path before the account persists.

Organisations should also expect offboarding to become a board-visible control because it sits at the intersection of security, audit, and spend management. Where licence waste, compliance evidence, and access revocation are managed together, the identity programme has a stronger control story than when they are handled in separate teams.

For practitioners

• 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. Include department-owned tools and shadow SaaS that IT may not see by default.
• Revoke access at the application layer on day of departure Do not rely on SSO deactivation alone. Confirm that each application has been deprovisioned or disabled directly, and invalidate any local login paths, personal tokens, and remote access rights before end of business.
• 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. Keep deletion logs, approvals, and timestamps for later review.
• Automate deprovisioning across HR and identity systems Use HR-triggered workflows to push deactivation into the identity provider, SaaS applications, and device management tools in one sequence. Automation reduces missed accounts, especially when multiple employees leave at the same time.

Key takeaways

• Ex-employee account deletion is a lifecycle control, and incomplete revocation leaves a real post-exit access window.
• The biggest operational risk is not email closure but residual access across SaaS, cloud consoles, API keys, and shared accounts.
• Teams that can prove deletion, archiving, and audit logging across the full account surface will reduce both breach exposure and recurring licence waste.

Key terms

• Ex-Employee Account Deletion: The process of disabling and removing a departed employee's access across identity providers, SaaS, cloud, and device systems. It is not just account closure, but a coordinated lifecycle action that also preserves required data and audit evidence while preventing the former user from re-entering the environment.
• Account Persistence: A condition where a former user's access remains active after employment ends. In identity governance, it signals a lifecycle failure because authentication paths still exist somewhere in the stack, often in SaaS apps, tokens, shared accounts, or local application sessions that were not deprovisioned.
• Identity Lifecycle: The end-to-end governance of access from joiner through mover to leaver, including provisioning, access changes, reviews, and revocation. For departed users, lifecycle control must prove that access is removed across every system, not just the primary directory or SSO layer.
• Non-Human Credential: A secret, token, API key, or certificate used by software rather than a person. These credentials often sit outside normal employee offboarding workflows, which is why they can survive a departure unless the organisation explicitly inventories and revokes them during lifecycle execution.

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

👉 Josys's full article covers the deletion sequence, tool examples, and common offboarding failure patterns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.