Before 18 August, revoking a user's credentials on GitHub was an all-or-nothing action. If one credential was compromised, containing it meant burning every credential type that user had — their SSH key, their personal access tokens, every OAuth authorisation, everything.
That is a blunt instrument for a common incident shape. A leaked personal access token in a CI log has nothing to do with the SSH key on someone's laptop, and treating them as one problem meant every response was more disruptive than the incident required.
What changed
Four credential types can now be revoked independently: personal access tokens, SSH keys, OAuth app tokens, and GitHub App user access tokens.
Enterprise owners, organization admins and anyone with the "Manage enterprise credentials" permission can bulk-deauthorize by token type, either across an entire enterprise or scoped to individual users, with the same capability available in the UI and the REST API. GitHub also added comprehensive audit logging with user notifications, so a revocation is visible and traceable rather than silent.
Why blast radius is the right frame
GitHub's own language is precise: this contains the blast radius of a compromise without revoking credentials that remain trusted.
That distinction is the entire value of the feature. Incident response has a real cost beyond the incident itself — every credential you revoke unnecessarily is a re-authentication, a broken CI run, a blocked developer, multiplied across however many people share the blunt response. A security team that can only respond with maximum force learns to under-respond to ambiguous signals, because the cost of being wrong is too high. Precision lowers that cost, which should mean teams actually act on weaker signals instead of waiting for certainty.
What this changes about incident response
Write a specific question into your incident runbook now, because this feature only helps if someone asks it under pressure: which credential type was exposed?
A secret scanning alert for a leaked PAT should trigger a PAT-scoped revocation, not a full credential wipe. An SSH key found in the wrong place should not force every developer to re-authorize their OAuth apps. Matching the response to the actual exposure is now possible, but only if your process asks the question rather than defaulting to the biggest hammer available out of habit.
Two things worth checking now, not during an incident
Confirm who in your organisation actually holds the "Manage enterprise credentials" permission, and whether that list matches who you would want making this call at 2am. This is exactly the kind of permission that gets granted broadly during setup and never re-reviewed.
Then check the audit log path before you need it — during a real incident is a bad time to be learning where the revocation trail lives and what it shows.