You forwarded the phishing email to the security channel about ninety seconds too late. The laptop is already cooperating with someone else. Your personal access token, the one you minted "just for that one script", is on its way to whatever Discord pays for stolen tokens this week. Now what?
For users on GitHub Enterprise, what was previously a clickthrough checklist you complete while your hands shake is now one button. On June 24 the GitHub Changelog announced a self-service credential revocation flow under Settings, Credentials. From that view a user can see counts of every credential they have generated or authorized through SSO, then revoke or delete all of them in a single action. Personal access tokens, SSH keys, OAuth tokens, SSO authorizations: gone together.
What actually shipped
Containment used to be a manual scavenger hunt. PATs sat under Developer Settings. SSH keys lived one tab over. OAuth apps you forgot you authorized two years ago hid behind a different submenu. SSO was its own world. In practice that meant during an incident you forgot something, and the something you forgot was the credential the attacker actually wanted.
The new view collapses that surface onto one screen. Counts on one side, a revoke-or-delete-everything action on the other. Whoever wrote it had clearly pictured the 3am screenshot: a user who has just been told to "rotate everything" and has no idea where "everything" lives.
GitHub frames this as a complement to an earlier enterprise-owner capability that lets admins with the "Manage enterprise credentials" permission bulk-revoke across one user or many. So there are now two pairs of hands on the kill switch: the user, and the org. (Whichever one notices first.)
Why a pipeline owner should care
Because users are the trust boundary you keep pretending is somebody else's problem. A leaked PAT in a CI pipeline is rarely a CI bug. It is a human who pasted the token into a script, then a laptop, then a sync folder, then a backup, then a public gist. The pipeline just happens to inherit the broadest scopes.
Containment time is the variable that matters here. If revocation is a support ticket, attackers have hours. If it is a self-service action behind 2FA, it is minutes. Every minute shaved off that window is a minute fewer for token replay against your build platform, your registry, your deploy keys.
The catch to put in your runbook
Revoke-everything is destructive by design. It is the user equivalent of kubectl delete ns prod. The button will, with one click, sign you out of integrations you forgot were load-bearing: CI runners using a PAT, that personal preview deploy, the Slack notifier on your team's repo, every IDE you ever authorized. Recovery is a separate and slower exercise.
That implies two habits to lock in before you bless this thing as a runbook step:
- Inventory the integrations that depend on a user-scoped credential. If your CI still runs as Alice's PAT, the day Alice presses the button is the day your deploys stop. Move user-scoped automation onto workload identity, OIDC-to-cloud, or a machine account before incident day.
- Write the post-revoke checklist. Which scoped tokens get re-minted, in what order, by whom. The whole point of break-glass is that you do not improvise after pulling it.
Where the wider ecosystem is going
The pattern is becoming industry-wide, with different ergonomics. Other forges already expose per-user token management with bulk revocation for personal access tokens, though SSH keys and OAuth grants often live on separate pages. Identity-provider-led shops increasingly push the kill switch up to the IdP: revoke the SSO session there and downstream tokens stop refreshing, which is cleaner in theory but assumes every credential is actually federated (most are not).
The interesting move on GitHub's side is not the destination. It is the surface. The platform is admitting that "rotate everything" is a real verb users perform under stress, then giving it a real button. Most platforms still treat token hygiene as documentation.
Kicker
A self-revoke button is not a security feature. It is an admission that the security feature was always going to be needed, and that asking the user to find it across four menus at 3am was the actual vulnerability. Ship the button. Then go find every PAT in your pipeline that should have been a workload identity six months ago.