Beyond the News
Sign in
Web DevelopmentCloud & InfrastructureDeployment & DevOpsDeveloper Tools Active dossier

GitHub adds token-type credential kill switches for incident response

GitHub enterprise and organization admins can now revoke or deauthorize one class of user credential at a time, narrowing incident-response blast radius when only part of an account is suspected compromised.

Reviewed and published by Lars Jansen Updated 4 min read
First published

Key details

  1. GitHub announced the change on August 18, 2026.
  2. Responders can revoke all user-level credentials of a specific type instead of revoking all credential types for that user.
  3. Examples named by GitHub include personal access tokens, SSH keys, OAuth app tokens and GitHub App user access tokens.
  4. SSO authorizations can be deauthorized by credential type across an enterprise or for a specific user.
  5. Bulk credential-revocation controls are now available at organization level through both UI and REST APIs.
  6. GitHub records these actions in the audit log and sends email notifications to affected users.

What builders should take away

  1. Update GitHub incident-response runbooks so leaked PATs, SSH keys and app tokens have separate containment procedures instead of defaulting to full-user credential revocation.
  2. Where automation handles credential containment, evaluate the new organization and enterprise REST API actions and require an explicit credential type as part of the response workflow.
  3. Preserve evidence before revocation when possible: identifying the compromised credential class is what lets teams benefit from narrower blast-radius controls.
  4. Alert on bulk revocation and SSO deauthorization audit events so security operations can distinguish planned response actions from unexpected administrative changes.
  5. Test the selective-revocation workflow with a non-production account so responders know which dependent automations or developer workflows survive each credential-class kill switch.

What changed

On August 18, 2026, GitHub introduced token-type-specific bulk credential revocation and SSO deauthorization. Enterprise owners, organization admins and users with the `Manage enterprise credentials` permission can target personal access tokens, SSH keys, OAuth app tokens or GitHub App user access tokens without revoking every credential a user holds. GitHub also brought enterprise bulk-revocation actions to the organization level through the web UI and REST APIs, with audit-log records and user email notifications.

Why it matters

Credential compromise is rarely all-or-nothing. The old kill switch could force teams to invalidate trusted SSH keys or app tokens while responding to a leaked PAT, increasing operational disruption and slowing containment. Token-type targeting gives security teams a more precise response primitive while preserving unaffected credentials, which matters for larger organizations where one user can have many machine and human authentication paths.

What responders can target now

GitHub now supports bulk revocation or deletion for a specific credential class rather than all user credentials at once. The supported examples include personal access tokens, SSH keys, OAuth app tokens and GitHub App user access tokens. GitHub also added token-type-specific SSO deauthorization across an enterprise or for a specific user.

Organization-level incident response catches up

Bulk credential-revocation actions that were previously available at enterprise scope are now also available at organization scope in both the web UI and organization REST APIs. That gives standalone organizations a direct operational path for incident response without needing enterprise-level administration.

Why narrower revocation matters

Selective revocation lets a responder invalidate the credential type actually implicated by evidence while keeping other authentication paths alive. That reduces avoidable developer lockout and service disruption, but it also raises the importance of identifying which credential class was exposed. GitHub records revocation and deauthorization actions in the audit log and emails affected users, which should be incorporated into response runbooks.

What to watch next

  • Whether GitHub adds finer targeting below credential class, such as revocation by creation window, scope or repository access.
  • Whether additional machine credentials or newer authentication mechanisms become separately revocable.
  • How organizations integrate the new API actions into automated incident-response playbooks.

Still unclear

  • GitHub documents the new controls and scopes, but the announcement does not quantify how quickly revocations propagate across all GitHub services or describe edge cases for long-lived sessions derived from revoked credentials.

Sources

Direct reading behind this dossier.

1 sources
Continue reading
Artificial Intelligence

GitLab 19.3 turns plain-English process knowledge into runnable agentic flows

Custom Flows became generally available in GitLab 19.2; 19.3 adds the missing authoring layer. Flow Creator reads current Flow Registry docs, applies known failure rules and generates a runnable flow from plain English. Builders still need to review, register and govern the automation rather than treating generated YAML as trusted infrastructure.