And another one. GitHub ships break-glass credential revocation

What it is

GitHub's self-service credential revocation for Enterprise, released the week before this post. It gives enterprise owners a "break-glass" action to cut off compromised credentials across an organization in one step, plus a new self-service view for individual members.

How it works

Two surfaces. Enterprise owners with the "Manage enterprise credentials" permission can bulk-revoke or delete credentials for all users in the org, or target one account — covering SSO authorizations for PATs, SSH keys, and OAuth tokens. A delete-all option exists for Enterprise Managed Users (EMU) orgs, and org-level REST APIs handle more granular per-org revocation. Every action writes an audit log entry and emails affected users. Individual members get a new Settings > Credentials view listing every credential tied to their account (SSO-authorized and personal); one action strips all of them from SSO-protected enterprise resources. EMU members also get an option to permanently delete all their tokens and SSH keys.

What it replaces

Before this, revoking one account meant stitching together several tools, none complete on its own:

• Fine-grained PATs — org token screen.
• Classic tokens — only via per-token SSO authorization revocation, and only with SAML SSO enabled.
• Revocation API — kills a token only if you already hold the token string (works for leaked secrets, not compromised accounts).

Caveats

• GitHub Actions tokens are out of scope. They're minted per job and expire when the job ends, so there's nothing to revoke. During an incident the page's stated mitigation is to disable Actions on the repository.
• The feature addresses incident-response rotation, not atomic rotation. The page notes atomic rotation (no window where old and new credentials both work) is "nonsensical" at GitHub's scale. Real rotation picks one of two imperfect paths: routine rotation keeps both credentials valid for a window (leaves the old one alive), or incident response cuts the old one first — and the page's whole argument is that the incidents below happened because the old credential stayed alive.

The incidents the summary references trace to exactly this gap: Aqua Security's February Trivy rotation was incomplete, a surviving credential enabled the March 19 tag force-push (75 of 76 tags in aquasecurity/trivy-action), and stolen pipeline credentials reached Checkmarx four days later (attacker persisted through April 22, data leaked April 25). Microsoft's Azure/durabletask compromise (May 19 PyPI, June 5 GitHub) came through an account whose credentials sat in infostealer logs since April and were never fully rotated — GitHub disabled 73 repos across four Microsoft orgs in response.

The takeaway for an engineer: if your org is on Enterprise, this collapses a multi-tool, SSO-dependent scramble into a single revoke — but plan a separate playbook for Actions (disable at the repo).