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

Treat offboarding as a credential custody problem, not only an account disablement task. Confirm that managed vault access, shared passwords, and non-federated application credentials are revoked or reassigned, because directory deactivation alone does not eliminate all live access paths.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Former-employee credentials require revocation, rotation, and lifecycle control.
	AC-2 — Account Management	Offboarding depends on timely account removal and reassignment across systems.
	IA-9 — Service Authentication	Non-federated apps, service accounts, and machine credentials can outlive a leaver.
Recommendation — Revoke or rotate authenticators and verify no lingering credentials remain active. Disable, remove, or reassign accounts as part of leaver processing. Inventory and revoke non-human authenticators that still grant access.
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Live credentials after departure are the core failure this control addresses.
	NHI-07 — Long-Lived Secrets	Residual access often persists because secrets remain valid too long.
Recommendation — Remove or rotate every credential path when an owner leaves. Shorten secret lifetimes and rotate credentials on departure.
CIS Controls v8	CIS-5 — Account Management	Leaver handling requires account inventory, disablement, and access removal.
Recommendation — Enforce timely account and credential removal for departing users.
OWASP API Security Top 10	API2 — Broken Authentication	Stale API keys and tokens let former users keep authenticating.
	API9 — Improper Inventory Management	Unknown applications and accounts are a common source of leftover access.
Recommendation — Revoke stale API credentials and validate auth paths after offboarding. Maintain an inventory of apps and credentials that offboarding must cover.

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.