Owners can see and revoke fine-grained personal access tokens that reach their organization, but they cannot see or revoke classic tokens from that screen. Removing the person from the organization is the dependable control, and a token policy limits what is left behind. SSH keys created by a token keep working after revocation.
Two kinds of token, two different answers
GitHub documents the difference plainly. For fine-grained tokens, organization owners can list every token that can reach the organization's resources, review its permissions, filter by creator, repository access or permission, and revoke several at once. The token's creator gets an email.
Classic tokens are different. Owners cannot view or revoke them in that interface. Unless the organization restricts them, a classic token can reach organization resources until it expires.
That is why the leaver process cannot be "find and kill their tokens". It has to be "remove the account's membership, then verify".
A leaver sequence for tokens and keys
- Remove the person from the organization, or from the identity provider group if membership is managed through SCIM or enterprise managed users. In that case GitHub says to remove them in the identity provider.
- Open the fine-grained token list, filter by the departing user, and revoke what remains. Revocation does not affect public resources, which the token can still read.
- Check for SSH keys. GitHub notes that SSH keys created by a token continue to work after the token is revoked, so review keys tied to the account and to any repository the person administered.
- Look at deploy keys on repositories they managed. Those belong to the repository, not the person.
- Rotate any shared secret they could read, such as CI variables.
- Record the date and time of each step in the leaver ticket.
Set a policy before anyone leaves
Prevention is cheaper than cleanup. Owners can set a personal access token policy with three levers.
| Lever | What GitHub documents |
|---|---|
| Restrict access | Owners can block classic and fine-grained tokens from organization resources. Both are enabled by default |
| Maximum lifetime | Settable per token type. Fine-grained defaults to 366 days. Classic has no expiry requirement by default |
| Approval | Owners can require approval for fine-grained tokens. This is the default, and owners' own tokens skip it |
Note one subtlety. Tokens that exceed the lifetime limit are blocked from the organization, not revoked. The policy gates access without cleaning up the tokens themselves.
A sensible baseline for most teams is to keep fine-grained approval on, cap lifetime well below the default, and restrict classic tokens unless a specific integration needs them.
What the API can and cannot do
Review and revocation of fine-grained tokens is available through the REST API, but only GitHub Apps can call those endpoints. Personal access tokens and OAuth apps cannot. If you plan to automate leaver cleanup, plan for a GitHub App.
Quick check
If I revoke a token, does it stop all of that person's access?
No. It stops that token. Their SSH keys, other tokens and membership are separate, so remove membership and review keys as well.
Can owners see classic tokens?
Not in the fine-grained token review screen. Restrict classic tokens by policy, or require expiry, so they cannot linger.
Does setting a lifetime policy delete old tokens?
No. Tokens over the limit are blocked from the organization but not revoked, so you may still want to clear them.
Safeguard's asset discovery and compliance evidence automation can help you keep a record of which identities and credentials exist and when they were removed. You can run a free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Reviewing and revoking personal access tokens in your organization
- GitHub Docs: Setting a personal access token policy for your organization
- GitHub Docs: Removing a member from your organization
Last reviewed: 19 October 2026.
