GitHub Adds Token-Type Credential Revocation for Security Incidents

GitHub has updated its credential management tooling so that enterprise owners, organization admins, and members with the Manage Enterprise Credentials permission can revoke user credentials by token type during a security incident. Previously, a kill-switch action wiped all credential types for a user at once. The new controls, available through the web UI and REST APIs, let teams surgically remove only the compromised credential class, such as personal access tokens, SSH keys, OAuth app tokens, or GitHub App user access tokens, while leaving trusted credentials intact.

What happened

Feature	Detail
Token-type bulk deauthorization	Revoke all SSO authorizations for one credential type across the enterprise or for a specific user
Token-type bulk revocation	Delete all credentials of one type (e.g. personal access tokens) for an EMU user without touching SSH keys
Organization-level parity	All bulk revocation actions previously enterprise-only are now available at the organization level via UI and REST API
Audit logging	Every deauthorization and revocation action is captured in the audit log with email notifications to affected users

GitHub describes this as building on existing self-service credential revocation tools for incident response. The four credential types that can be targeted individually are: Personal Access Tokens (PATs), SSH keys, OAuth app tokens, and GitHub App user access tokens.

The controls apply both at the enterprise level (for enterprise owners) and at the organization level (for org admins). Both the web UI and the relevant REST APIs expose the new options.

Why it matters

The old behavior was blunt: if a class of credentials was compromised, you had to nuke everything for the affected user or accept continued exposure. That forced a tradeoff between security and operational disruption, particularly for EMU (Enterprise Managed Users) accounts where re-issuing every credential type causes significant downtime.

With token-type-specific revocation, a team responding to a leaked PAT no longer has to also invalidate that user’s SSH keys or active OAuth sessions. The “blast radius” of the incident response is contained to the actual vector of compromise.

The organization-level parity is also significant. Teams that operate at the org level rather than the full enterprise level previously had fewer incident-response levers available. That gap is now closed.

Our take

This is a sensible, overdue refinement. Credential management during an active incident is high-stress, and coarse controls that revoke everything create their own disruption. The move toward granular, type-specific revocation mirrors how mature identity platforms handle token classes, and it’s good to see GitHub closing the gap.

The audit log coverage matters too. In a post-incident review, knowing exactly which token type was revoked, by whom, and when is the kind of evidence that satisfies both internal security teams and external compliance requirements. If you manage a GitHub enterprise or org with sensitive repositories, it’s worth reviewing your current AI integration and automation workflows now to understand which token types they rely on, so you know what to target (and what to protect) if an incident hits.

For teams building automated pipelines on GitHub, this is also a reminder that over-provisioning token scopes is a liability. Keeping PATs, SSH keys, and OAuth tokens separated by use case means a compromise of one is genuinely contained. If your CI/CD setup mixes token types loosely, this feature is a prompt to tighten that up. You can also read about GitHub Copilot enterprise admin controls for more context on how GitHub is expanding its enterprise management surface.

What to do about it

1. Review your enterprise or org security settings in GitHub to confirm who holds the Manage Enterprise Credentials permission.
2. Audit which token types your automations and integrations use, and document them so your incident response runbook is specific.
3. Update your incident response checklist to reference the new token-type-specific revocation options in both the UI and REST API.
4. Confirm audit log forwarding is configured so revocation events flow into your SIEM or security tooling automatically.

If a credential class is compromised, you now have the precision to contain it without collateral damage to the rest of your users’ access.

Source: GitHub Changelog