What should teams do when former employees may still have live credentials?

Why former-employee credentials remain a live-access problem

Offboarding only works when every credential path tied to the departing person is closed, not just their primary directory account. The residual risk usually sits in shared passwords, vault entries, local application accounts, API keys, and non-federated systems that do not automatically follow HR-driven disablement. That is why secrets sprawl and API key lifecycle discipline matter during leaver handling.

The practical issue is custody: someone may have left, but the secret may still be valid, retrievable, or embedded in a workflow the team forgot to inventory. That is especially common where credentials are stored outside the IdP, issued manually, or reused across tools with no centralized revocation point. In those cases, deactivation is necessary, but it is not sufficient.

Teams should think in terms of credential ownership transfer. If the credential supports a shared operating process, ownership must move to a service owner or team process, while access must be reissued under current control rather than informally passed along. The safest outcome is a clean replacement with rotation, not a silent handoff that preserves stale privilege.

What must be revoked, reassigned, or rotated

Every offboarding review should cover the full credential set, including vault access, password managers, shared admin passwords, SSH keys, long-lived tokens, cloud console access, and application-specific logins that bypass SSO. For secrets that cannot be centrally invalidated, rotation is the revocation mechanism. NHIMG’s credential rotation guidance is useful here because the operational problem is often not the concept of rotation, but the dependency mapping needed to do it safely.

Shared credentials deserve special attention because they hide accountability gaps. If multiple people know the same password, you cannot prove which actor still has access after one person leaves, and you cannot confidently scope the blast radius of compromise. That is why shared secrets should be treated as revocable assets, not convenience artifacts.

Non-federated applications are often the hardest cleanup item because they sit outside standard identity governance. If an application maintains its own local accounts, those accounts need explicit reassignment, disabled sessions, and password change or key rotation. A directory record marked inactive does not reach into those systems on its own.

How to verify offboarding is complete

Verification should be based on evidence, not assumption. Confirm that every known secret path has a named owner, a current state, and a closure action, then verify the action in the target system rather than relying on ticket closure alone. Where the environment uses vaults or centralized secret stores, confirm both the vault entry and every downstream consumer that relied on it.

Good offboarding evidence includes rotation timestamps, revocation logs, application admin screenshots or audit events, and a current inventory of systems where the departed employee had access. Where teams still depend on manual handoffs, the verification standard should be stricter because manual processes are the most likely place for hidden access to persist.

The cleanest control test is simple: could the former employee still authenticate, retrieve a secret, or use an already-issued token anywhere in the estate? If the answer is uncertain, the offboarding process is not finished.

Risk and Threat Considerations

Former employees with live credentials create a direct path from routine turnover to unauthorized access. The risk is highest where secrets are long-lived, shared, or stored in places that bypass central identity controls, because those conditions let access survive the employee relationship itself.

Failure mechanism: Directory disablement ends one authentication path, but it does not automatically revoke vault entries, shared passwords, API keys, or local application accounts. Attackers and insiders can exploit that gap to preserve access after departure, and an ordinary leaver event can become a delayed compromise.

Impact: The result can be data exposure, account misuse, unauthorized changes, fraud, or persistence inside systems that the organization believed were closed. The longer a live credential survives, the harder it becomes to distinguish legitimate business use from ex-employee activity.

Practitioner Guidance

What to prioritize: Start with credentials that can reach production data, privileged administration, or external integrations. If a former employee had access to a shared secret, a vault path, or a local admin login, treat that as higher priority than a simple desktop account disablement.

What to verify: Check for three things on every leaver: credential invalidation, session termination, and ownership reassignment. If any one of those is missing, the offboarding control is incomplete even if HR marked the record closed.

Common mistake: Teams often equate “removed from the directory” with “removed from access.” That shortcut misses the exact places where hidden credentials persist, especially in application-specific accounts, vaults, and shared operational logins.

Practitioner takeaway: Offboarding should end with no remaining secret that can still authenticate on behalf of the departed person, and the only trustworthy proof is confirmation at each system that actually holds or accepts the credential.

Related resources from NHI Mgmt Group

• How should security teams respond when public code contains live credentials that still authenticate years later?
• What should teams do when former employees still appear in renewal counts?
• How should teams reduce the risk of orphaned service accounts and stale tokens?
• How should security teams debug JWTs without exposing live credentials?