GitHub Now Revokes Stolen Tokens Without Locking Out the Rest

What Changed

On August 18, 2026, GitHub made token-type credential revocation generally available. The change is small to describe and useful the moment you need it.

Until now the kill switch was blunt. GitHub's own wording:

Previously, credential kill-switch actions applied to all of a user's credentials at once.

So containing one leaked personal access token meant taking that person's SSH keys and OAuth authorizations with it. During an incident that is a second outage on top of the first, and it lands on someone who is usually already busy.

Now enterprise owners, organization admins, and anyone with the Manage enterprise credentials permission can act on a single credential type: personal access tokens, SSH keys, OAuth app tokens, or GitHub App user access tokens. GitHub frames the goal as containing the blast radius "without revoking credentials that remain trusted", which is exactly the distinction that was missing.

Deauthorize and Revoke Are Not the Same Button

The announcement lists two separate capabilities, and it is worth keeping them apart because they solve different halves of an incident.

Deauthorization removes SSO authorizations for a credential type, across the whole enterprise or for one user. The credential still exists; it simply stops opening your organization's doors. This is the reversible one, and the right first move when you suspect something and want the door shut while you look.

Revocation deletes or revokes the user-level credentials themselves. GitHub's example is precise: delete every personal access token belonging to one Enterprise Managed User without touching their SSH keys.

Both work from the web UI and from the REST APIs, which matters if your incident runbook is a script rather than a person clicking.

Organizations Get Parity

The quieter half of the release is that every bulk revocation action that existed at enterprise level now also exists at organization level, in both the UI and the organization REST APIs.

That is the part that widens who this helps. Enterprise-level controls assume an enterprise account and the administrative structure that comes with it. Plenty of teams that need incident response are a single organization, and until now they watched these features from the outside.

Everything lands in the audit log, and affected users are emailed automatically, so nobody has to work out afterwards who lost what and why.

Where This Actually Helps

The scenario is not hypothetical, and it was two weeks ago.

The npm supply chain worm of August 4 harvested npm tokens, GitHub personal access tokens, OAuth tokens and SSH keys from any machine that ran an install during a 53 minute window. Remediation in that situation is credential rotation, and the order matters: the tokens that can mint other credentials first, because a stolen GitHub token is what turns one compromised laptop into a compromised organization.

Under the old kill switch, doing that meant revoking everything a developer had and handing them a rebuild of their whole local setup on the day you least wanted to. Being able to say "every personal access token for these six people, nothing else" is the difference between a contained morning and a lost day.

Worth Setting Up Before You Need It

Two small things are cheap now and awkward at 2am.

First, check who actually holds the Manage enterprise credentials permission. A capability that only the one person on holiday can use is not incident response.

Second, if your runbook is written down, add the API call rather than a UI walkthrough. The REST endpoints are the reason this scales past a handful of users, and an incident is a poor time to read API docs for the first time.

If you have no runbook at all, the useful version fits on one page: who can revoke, which token types exist in your org, and who to tell. Writing that down beats any tooling.

We handle incident response and access review as part of security and compliance work, and build the CI/CD pipelines whose tokens are usually the ones worth protecting. If you want a second pair of eyes on what a stolen token could reach in your setup, get in touch.

Sources: GitHub Changelog, August 18 2026, GitHub REST API for enterprise administration