Offboarding Beyond the Directory: Ending Tokens, Sessions and Grants When People Leave

Most offboarding checklists end with one action: disable the account in the directory. That step matters, but it closes only the front door. A person who leaves can still hold OAuth tokens, personal access tokens, SSH keys, app sessions and API keys that were issued before the account was switched off. None of these need a fresh sign-in, so MFA never gets a chance to stop them.

A recent incident shows what this looks like in practice. In its September 2026 analysis, CrowdSec reported that about 170 private GitHub repositories were cloned on 22 May 2026 using an OAuth token tied to a recently departed developer's account. The account had been kept in the GitHub organisation on purpose, and was removed three days after the clone. The company attributes the compromise of the former employee's machine to the TanStack npm supply-chain attack. The Hacker News notes that CrowdSec's first statement had pointed elsewhere before the updated report. The lesson does not depend on those details: access that outlives employment is access someone else can use.

Why disabling the account is not the end

Identity providers stop issuing new credentials once an account is disabled. What has already been issued is a different matter. Microsoft's guidance on revoking user access in Entra ID explains the gap clearly:

• Access tokens stay valid until they expire, which by default is one hour for Entra-issued tokens.
• Browser applications usually issue their own session cookie after sign-in. The identity provider cannot revoke that cookie; the application has to.
• Some applications may not send the user back to the identity provider for as long as their own session is valid.

Developer platforms add another layer. GitHub's documentation on managing a member's SAML access states that revoking an authorised credential only removes its SAML authorisation and does not delete the underlying token or SSH key. Removing someone from an organisation ends their access to private forks, but GitHub notes that local copies remain on their machines and that forks in other organisations may stay reachable.

In short, offboarding is a set of revocations across several systems, each with its own timing. Treat it that way.

Map what a leaver actually holds

Before you can revoke everything, you need to know what "everything" is. For a typical knowledge worker or engineer, the inventory looks like this:

• Interactive identity: the directory account, SSO sessions, MFA methods and passkeys, and registered devices.
• Application sessions: cookies in SaaS tools that manage their own sessions, including apps outside SSO.
• Delegated grants: OAuth consents given to third-party apps and integrations on the user's behalf.
• Developer credentials: personal access tokens, SSH keys, signing keys, CLI login caches and cloud access keys.
• Shared and machine identities: service accounts, bots and API keys the person created or owns.
• Data shares: external sharing links and guest invitations they issued.

The fifth category is the one most often missed. The OWASP Non-Human Identities Top 10 lists improper offboarding as its first risk, and recommends reviewing every non-human identity associated with a departing employee and periodically recertifying that each still has a valid owner.

Exceptions need an end date

Keeping access open for a few days after someone leaves is sometimes reasonable: a handover, a final fix, a contractor finishing a deliverable. The CrowdSec account was kept for exactly that kind of reason, and the company's own report names offboarding, scoped tokens and better logging among its lessons.

Treat any post-departure access as a formal exception rather than a courtesy:

1. Record who approved it, why, and the exact expiry date and time.
2. Reduce scope to the specific repositories, projects or folders needed, ideally through a new, narrowly scoped credential rather than the person's existing tokens.
3. Revoke existing long-lived tokens at the departure date, even if a new limited one is issued.
4. Monitor the account more closely than usual, including bulk clone, download and export activity.
5. Remove the access automatically at expiry instead of relying on someone to remember.

Make revocation fast and complete

The UK NCSC's identity and access management guidance asks for a joiners, movers and leavers policy so that access can be revoked when no longer needed, and recommends tying access to the work account through single sign-on so it can be removed when someone leaves. The more applications rely on the central identity, the fewer separate revocations you need.

For the applications that do rely on it, revocation should go further than the account flag. Microsoft's guidance pairs disabling the account with revoking refresh tokens and sessions, disabling registered devices and using automated deprovisioning so that applications end their own sessions. Where supported, continuous access evaluation shortens the window in which an already-issued token still works.

For applications outside SSO, keep a list with a named owner and a documented removal step. If an application cannot be deprovisioned centrally, it is a candidate for SSO integration or replacement.

A checklist for this week

• Pull your last ten leavers and check, system by system, whether any token, key, session, OAuth grant or sharing link survived their departure date.
• In your code platform, review personal access tokens, SSH keys and OAuth app authorisations for accounts no longer employed. Revoke what remains.
• List every account kept active after a departure. Give each one an owner and an expiry date, or remove it.
• Confirm that your offboarding runbook includes "revoke sessions and tokens" as a separate step from "disable account".
• Identify applications with their own sessions and no automated deprovisioning, and assign an owner to each.
• Find service accounts, bots and API keys created by people who have left, and reassign or retire them.
• Check that audit logs for your code platform and file storage capture bulk clone and download activity, and that someone would see an alert.

Conclusion

Offboarding fails quietly. The directory shows the account as disabled, the ticket is closed, and a token issued weeks earlier keeps working. Closing that gap means treating departure as a set of revocations across identity, applications, developer tools and machine identities, with exceptions that expire on their own.

A shared identity layer makes this easier, because one decision can reach many systems at once. That is the role OXU Identity is built for: one account with complete control. Whatever tooling you use, the test is the same: on a leaver's last day, can you show that nothing they held still works?

Sources

• CrowdSec: TanStack supply chain attack analysis
• The Hacker News: CrowdSec says TanStack npm attack led to copy of 170 private GitHub repositories
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• GitHub Docs: Viewing and managing a member's SAML access to your organization
• GitHub Docs: Removing a member from your organization
• OWASP Non-Human Identities Top 10: NHI1 Improper Offboarding
• NCSC: 10 Steps to Cyber Security, Identity and access management