What happens when a departing employee retains API token or proxy-style access?

If token-based or proxy-style permissions are not tightly controlled, a departing employee can continue acting through a secondary identity long after their normal login is revoked. That creates a persistent access path that bypasses the intent of offboarding. In practice, the risk is unauthorized administrative activity, delayed detection, and a cleanup problem that is much larger than a simple account disablement.

API tokens and proxy-style access often outlive the human login they were issued alongside, so offboarding has to revoke the delegated path, not just the employee account. If that secondary identity still works, the former employee can keep calling systems, changing data, or triggering admin actions without using the disabled account. That turns a routine departure into a lingering trust failure.

The practical problem is that token-based access is usually designed for convenience and automation, so it is easy to miss in manual offboarding. This is why access reviews that focus only on directory accounts routinely leave behind credentials, integrations, and forwarded access paths that still function after termination. The State of Secrets in AppSec shows how persistent secrets problems can drag on for weeks even after they are discovered, which is the same basic cleanup problem teams face when delegated access is overlooked. In practice, many organisations discover the gap only after an audit, incident, or unexplained system change, not during the exit process.

How it works in practice

A departing employee may retain access in several ways: an API token tied to a service, a proxy account that forwards requests, a browser session that was never invalidated, or an integration credential stored outside the identity system. The core issue is that these credentials are not governed like the employee’s interactive login, so disabling the person does not always disable the path they used to reach production resources.

Tokens can remain valid until expiry, even if the user is gone.
Proxy or delegation accounts can mask the original actor, making attribution harder.
Shared automation credentials may be reused across systems, widening blast radius.
Revocation often requires a separate inventory, not just an HR-triggered disable action.

That means offboarding needs to include discovery, ownership confirmation, and revocation of every credential or proxy that can still act on behalf of the departing employee. Where access is federated through apps, cloud platforms, or external tools, the team must also verify that downstream sessions and refresh tokens are invalidated, not merely the primary directory record. OWASP’s Non-Human Identity Top 10 is useful here because it highlights the operational risks around secret sprawl, rotation, and overprivilege that make these lingering paths so hard to see.

These controls tend to break down when access was granted informally, outside the standard joiner-mover-leaver process, or when no one owns the token after the employee leaves.

Common variations and edge cases

Tighter control over delegated access often increases operational overhead, because teams must know which tokens, proxies, and automation paths belong to which person or workflow. That tradeoff is worth it, but the answer changes depending on whether the access is personal, shared, or tied to a production integration that cannot simply be deleted.

Short-lived tokens reduce exposure, but only if rotation and revocation are actually enforced. Long-lived tokens, inherited admin proxies, and vendor-managed integrations are the hardest cases because they can remain valid after the employee has left and may be embedded in scripts or connected systems. Public-facing APIs, cloud consoles, and support portals are especially sensitive because a retained token can still reach high-value data or administrative functions. The Salesloft OAuth token breach is a reminder that token compromise can create a durable access path into downstream systems even when the original account relationship looks narrow on paper.

Where a proxy account or shared integration survives employee departure, the question is not only “can they still log in?” but also “can anything still act for them?” That distinction matters because the most dangerous residual access is often the one that does not look like a normal user session at all.

Risk and Threat Considerations

The main risk is persistent unauthorised access through a delegated or tokenised path after the human account has been removed. That creates a clean way for a former employee, or anyone who later obtains the credential, to bypass offboarding intent and keep reaching internal systems.

Failure mechanism: The control fails when token expiry, revocation, proxy ownership, and downstream session invalidation are not treated as part of termination. An attacker does not need the employee password if a valid API token, refresh token, proxy credential, or session cookie still works.

Impact: The result can be silent administrative activity, data access, configuration changes, or delayed abuse detection, often with weaker attribution than a normal login. The cleanup burden also expands because teams must trace every place the credential was copied, inherited, or cached.

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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secret Sprawl and Credential Inventory	Lingering API tokens and proxy access are classic non-human identity sprawl risks.
	NHI-03 — Privilege and Access Governance	Departing employees may retain excessive delegated rights after account disablement.
Recommendation — Inventory and revoke every token, proxy, and delegated credential at offboarding. Apply least privilege and remove any remaining delegated administrative paths.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Offboarding must remove active access paths, not only the primary user account.
Recommendation — Revoke authentication material and validate access removal across dependent systems.
CIS Controls v8	5 — Account Management	Account lifecycle controls must include tokens, proxies, and shared credentials.
	6 — Access Control Management	Residual proxy or token access is an access-control failure with downstream exposure.
Recommendation — Track and disable all accounts and credentials tied to departing personnel. Restrict and remove access paths that can still act after termination.
NIST SP 800-63	AAL2 — Authenticator Assurance Level 2	Token and session handling must support reliable revocation and replay resistance.
Recommendation — Use authenticators and session controls that can be revoked promptly and reliably.
NIST Zero Trust (SP 800-207)	3.1 — Verify Explicitly	Proxy-style access must be re-authorized rather than trusted after employee departure.
Recommendation — Re-evaluate each request path and deny access unless it remains explicitly authorised.

Practitioner Guidance

What to prioritise: Treat offboarding as credential and delegation revocation, not account disablement. The first question should be which tokens, proxies, refresh flows, and shared automation paths can still execute after the employee leaves.

What to verify: Confirm that ownership exists for each non-interactive access path, that revocation is technically possible from the control plane, and that downstream sessions actually die when the primary account is removed. If you cannot prove those three conditions, the access path is still live in practice.

Common mistake: Teams often close the HR ticket and assume the risk is gone. The better test is whether any credential can still authenticate, refresh, or impersonate the departed employee in production.

Practitioner takeaway: The safest offboarding metric is not “account disabled,” it is “all usable ways to act for that person have been found and invalidated.”