Ex-employee account deletion is the core offboarding control

At a glance

What this is: This is an analysis of ex-employee account deletion as the core offboarding control, with the key finding that delayed or partial removal leaves former staff able to retain access.

Why it matters: It matters because IAM and IGA teams need offboarding to work across human identities, SaaS, devices, and third-party access, not just at the directory layer.

By the numbers:

• The average company uses more than 100 SaaS applications, so dozens of accounts per departing employee may need deletion.

Context

Ex-employee account deletion is the process of disabling and removing all system, SaaS, device, and access rights tied to a departing employee. In offboarding terms, the security problem is not awareness of the exit event but completeness of revocation across the full identity surface.

As SaaS estates expand, the number of places a former employee can remain active also expands. That makes offboarding an IAM and IGA control problem, not just an HR workflow, because the account can remain usable long after formal departure if any control layer is missed.

The article’s central claim is that account persistence creates a compounded risk: access, compliance, and cost losses stack when deletion is partial, delayed, or left to manual follow-up.

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: How do security teams know whether offboarding is actually working?

A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.

Q: Should organisations automate ex-employee account deletion or keep it manual?

A: Automation is preferable when the estate includes many SaaS tools, because manual cleanup is where delays and misses accumulate. The objective is not to remove human oversight, but to remove the dependency on memory and ad hoc follow-up for every departure. Manual review still has a role, but the revocation workflow should be triggered automatically.

Technical breakdown

Why SSO deprovisioning alone is not enough

Single sign-on controls only the front door. If a departing employee still has local SaaS credentials, personal tokens, or app-level accounts, cutting the directory session does not remove the underlying access path. This is why deactivation in the identity provider must be paired with application-level deprovisioning, SCIM where available, and explicit revocation of any separate login path. The architectural failure is assuming federation is the same as account removal. Practical implication: treat SSO as one control plane, not the whole offboarding mechanism.

Practical implication: validate deactivation at the application layer, not only in the identity provider.

Why API keys and personal tokens are high-risk offboarding gaps

API keys and personal tokens behave differently from interactive user sessions because they can remain valid outside normal login controls and monitoring. They are often issued directly to individuals, embedded into automation, or forgotten when a person leaves, which makes them one of the highest-impact missed artefacts in offboarding. In NHI terms, these are non-human credentials that can outlive employment status unless they are explicitly invalidated. Practical implication: build key and token revocation into the same offboarding event that disables user access.

Practical implication: revoke personal tokens and API keys as part of the same departure workflow as user deactivation.

How account persistence creates breach and cost exposure

When ex-employee accounts stay live, the organisation keeps paying for identities that no longer serve a business purpose while preserving a usable access path for exfiltration or opportunistic abuse. The risk is compounded by the fact that dormant accounts are less monitored and therefore easier for attackers to exploit if credentials remain weak or exposed. The same lapse also creates audit and retention pressure, because organisations must prove unnecessary access was removed on time. Practical implication: offboarding needs audit evidence, not just task completion.

Practical implication: retain deletion logs and approvals so you can prove access was removed and when.

Threat narrative

Attacker objective: The attacker objective is to retain or exploit post-departure access long enough to steal data, maintain entry, or abuse the remaining account surface.

1. Entry occurs when a former employee account is left active after departure, preserving a legitimate access path that should have been removed.
2. Credential abuse follows when the account still has usable passwords, local SaaS access, API keys, or remote access rights.
3. Impact emerges as attackers or disgruntled ex-employees use that persistence to read, extract, or tamper with data and continue spending licence budget.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Account persistence is the offboarding failure that matters most: once an employee leaves, any remaining live account becomes a governance defect, not a convenience. The security issue is not only unauthorised use, but the fact that the organisation has lost control of where that identity still exists. Practitioners should treat deletion completeness as the core offboarding measure.

Ex-employee deletion is an identity lifecycle problem, not a directory task: the article shows that IdP, SaaS, VPN, device, archive, and audit obligations all sit in the same workflow. A programme that only closes the primary login leaves residual access in business apps, remote channels, and third-party systems. The practitioner conclusion is that offboarding must be governed as a lifecycle event across the full estate.

Offboarding failures expose a cross-domain control gap between human IAM and NHI governance: the same process that removes a person’s accounts must also invalidate personally issued API keys and tokens. That matters because machine credentials do not respect employment boundaries and can remain exploitable after the human identity is gone. The implication is that lifecycle governance has to span both human and non-human access artefacts.

Manual offboarding creates predictable inconsistency: the article’s failure patterns show that app-by-app cleanup, timing delays, and shared accounts all widen the exposure window. This is where governance becomes measurable: if the process depends on memory, the estate will retain hidden access. Practitioners should assume the weakest manual step defines the real control boundary.

Complete revocation should be the default control objective: the article aligns with the broader NHI lifecycle principle that access should end when the business relationship ends. For organisations with large SaaS estates, the challenge is not whether offboarding matters, but whether the workflow can execute across every system before the former employee can still use the account.

From our research library:

• 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.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Account persistence is the control gap organisations underestimate: once a person leaves, the risk is no longer just one unused login, but an identity surface that can still include SaaS, device, and token access. Offboarding should be treated as a lifecycle control that ends every reachable access path, not as a single deactivation task.

Residual access is easier to overlook as SaaS estates expand: the more applications a company uses, the more likely a department-owned tool or personal token survives the handoff. That is why the governing question is not whether the person exited, but whether every access artefact was actually removed.

Offboarding becomes an NHI issue the moment personal tokens and API keys are part of the employee workflow: those credentials continue to function independently of employment status. Lifecycle governance has to cover them with the same seriousness as human access, because the removal event is what ends the risk, not the employment record.

For practitioners

• Map every departing employee to a full access inventory Build the offboarding list from the IdP, SaaS catalogue, device estate, VPN, and any department-owned tools so hidden accounts do not survive the departure event.
• Revoke access at the departure date, not after Deactivate the primary directory account, disable application logins, revoke remote access, and invalidate personal tokens at end of business on the departure date.
• Treat API keys and tokens as offboarding items Add personally issued API keys, developer tokens, and admin credentials to the same revocation workflow used for human accounts so non-human access does not persist.
• Record each deletion for audit and dispute handling Keep logs, approvals, and completion records showing who removed which account, when it was removed, and what retention path was used.
• Automate the HR-to-identity handoff Trigger deprovisioning from the HR departure event so the offboarding workflow can disable accounts, reclaim licenses, and archive data without manual delay.

Key takeaways

• Leaving a former employee account active creates a real post-departure access path that can be used for unauthorised access or data theft.
• The practical gap is usually not policy intent but execution across IdP, SaaS, API keys, devices, and audit records.
• A complete offboarding programme proves that every access artefact was revoked at the departure event and keeps evidence of that revocation.

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.
• Identity Persistence: A situation where an attacker maintains access by abusing identity mechanisms such as tokens, OAuth applications, backdoor accounts, or modified permissions. Unlike endpoint persistence, it often blends into normal administration and survives unless lifecycle and consent controls are actively reviewed.
• Offboarding: Offboarding is the controlled retirement of a workload, service account, token, certificate, or other non-human identity when it is no longer needed. It includes revoking credentials, removing permissions, and verifying that no residual trust path remains available to attackers.
• Non-Human Credential: A non-human credential is a secret used by software, automation, or an AI agent to authenticate or act on a system’s behalf. Examples include API keys, tokens, certificates, and service account secrets. These credentials need lifecycle governance because they often persist beyond the human task that created them.

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.