What happens when a former employee is only partially offboarded?

Why partial offboarding creates a real access problem

A partial offboarding is not just an HR process gap, it is an access control failure. If accounts, tokens, shared secrets, or delegated permissions remain active after employment ends, the former employee can still reach systems that should have been closed. That extends the trust boundary past the relationship that justified access in the first place.

The operational issue is that offboarding is rarely one control. It spans account disablement, privilege removal, secret rotation, session termination, device return, and ownership transfer for any shared integrations. If any of those steps are missed, the old access path can stay usable even when the person is no longer visible in standard joiner-mover-leaver workflows.

The most common weak point is credential persistence. A stale password, API key, certificate, or token may continue to authenticate until it is explicitly revoked or rotated. That is why lifecycle management and revocation discipline matter as much as the initial provisioning step, and why the NHI Lifecycle Management Guide is a useful reference point for the offboarding phase.

When an organisation wants a concrete example of the failure mode, the Coupang Signing Key Breach shows how unrevoked credentials tied to an offboarding failure can leave large amounts of data exposed. The lesson is simple: if an identity or secret can still authenticate, the offboarding process is not complete.

How the exposure becomes damaging

Once a former employee still has a live access path, the consequences depend on what that access can do. At the low end, it may create lingering audit noise and confusion during incident response. At the high end, it can enable data exfiltration, tampering, fraud, or destructive change, especially where permissions were broad or the account was tied to admin, support, or production functions.

The risk also compounds when the organisation cannot quickly tell what the former employee still touched. Weak inventory, poor ownership records, and shared credentials make investigation slower and containment less certain. In practice, that means more systems have to be checked, more logs have to be reviewed, and more business disruption may be needed while the scope is still unclear.

Offboarding gaps also create compliance exposure because access removal is part of basic control hygiene in most regulated environments. In healthcare, the impact can be especially serious because a lingering account may expose patient data or disrupt service delivery if it is used after employment has ended. The problem is not only malicious use, it is also accidental reuse, delayed revocation, or a third party continuing to trust the former employee’s access path.

The scale of the issue is reflected in NHIMG’s research, which found that only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. While that statistic is about non-human identities, the underlying control failure is the same one that affects human offboarding, stale access remains active longer than the organisation assumes.

What good offboarding should confirm before the employee leaves

Practitioners should treat partial offboarding as incomplete until every access-bearing object is accounted for. That includes direct user accounts, privileged access, shared mailbox or ticketing permissions, remote access paths, cloud consoles, secrets in code or vaults, and any application trust that was granted to the employee or to something they owned.

What to verify: confirm that access removal is not limited to the primary directory account. Check whether the employee had production access, break-glass proximity, delegated admin roles, exported tokens, certificates, or ownership of business-critical service accounts and automation jobs. If the person was a creator, not just a user, the cleanup obligation is usually broader than the ticket suggests.

Decision rule: if any credential or permission can still authenticate to a sensitive system, prioritise revocation or rotation before closing the case. If the remaining access is shared, treat it as higher risk because you may need to rotate or replace the underlying secret rather than simply disable one person’s account.

Practitioner takeaway: partial offboarding should be judged by residual access, not by whether the exit checklist was marked complete. If any trust path remains live, the organisation still owns an active exposure.

Risk and Threat Considerations

A partially offboarded employee is risky because the organisation has removed the relationship but not always the authority. That mismatch creates a window where an insider, a disgruntled former worker, or anyone who later acquires the credential can operate under still-valid trust. The longer the gap persists, the more likely the account, token, or privilege will be forgotten and left outside normal monitoring.

Failure mechanism: access removal is incomplete, so authentication or authorization remains valid on one or more systems. The failure is often hidden by fragmented ownership, shared secrets, or automation that disables the visible account but leaves embedded credentials and delegated access untouched.

Impact: the remaining access can be used for data theft, tampering, unauthorised transactions, or lateral movement, and it can slow incident response because investigators must determine which systems still trusted the departed employee. In regulated sectors, that can also become a reportable control failure and a confidentiality issue.

Practitioner Guidance

What to prioritise: treat offboarding as an access removal exercise, not an administrative closure. The highest-value work is to identify every place the employee could still authenticate or act, then remove or rotate those paths in a controlled sequence.

What to measure: track how many exits still leave active access after departure, how long it takes to revoke privileged credentials, and how often post-exit reviews discover hidden permissions. A low number of manual exceptions and a short revocation window are stronger signals than a completed form.

Common mistake: teams disable the primary user account and assume the job is done. In reality, the dangerous residue is often the credential the person created, the role they owned, or the shared integration nobody remembered to rotate.

Practitioner takeaway: the safest offboarding process is the one that proves there is no surviving way to authenticate, inherit, or continue using the departed employee’s access.

Related resources from NHI Mgmt Group

• What happens when a former employee can regain access to customer data after leaving?
• What happens when a former employee still has admin access in a SaaS application?
• What happens when Argo CD syncs secret references but the actual secret values live in an external secrets manager?
• What breaks when an AI agent is offboarded like a human employee?