An incident responder locking down a compromised GitHub identity no longer has to choose between revoking a specific token and wiping every credential the user owns. A GitHub changelog entry dated August 18, 2026 adds token-type-specific and user-specific actions for personal access tokens, SSH keys, OAuth app tokens and GitHub App user access tokens. The controls sit at both enterprise and organization level, in the UI and via API, and every action lands in the audit log.
What the new controls actually expose
Two operations are available for each of the four token classes, per the changelog. Bulk deauthorization strips SSO grants for a specific credential type. Bulk revocation deletes or revokes all user-level credentials of that type. Access is restricted to enterprise owners, organization admins, and members holding the "Manage enterprise credentials" permission. GitHub frames the release as an extension of its earlier self-service credential revocation flow for incident response, with the same primitives now available at the organization tier.
Where the granularity still bites
Blast radius is the operational read. The prior flow was closer to one large hammer: when a stolen personal access token triggered the response, revoking it often meant taking down that user's SSH keys and OAuth grants at the same time, and breaking every CI job the automation touched. Cutting revocation to a single token type lets a responder shut the actual vector, keep the rest wired and give the audit team a live session to review. On shared service identities, where a full-account revoke ripples through a dozen pipelines, per-type bulk revocation compresses cleanup by an obvious margin.
Read the granularity carefully. The unit is a token type, not an individual token: bulk revocation of OAuth app tokens still means every OAuth grant on the account, not one app. And the audit-log capture is only as useful as the SIEM pipeline already ingesting enterprise-owner actions. Worth wiring up before the next incident, not during it.
