GitHub break-glass revocation shows why credential cleanup must be atomic

At a glance

What this is: GitHub has added enterprise-level break-glass credential revocation to bulk remove compromised tokens, SSH keys, and OAuth access during an active incident.

Why it matters: For IAM and NHI teams, this matters because incomplete revocation leaves standing access alive, which turns a single compromise into repeated reuse across repositories, pipelines, and organisations.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Aikido's analysis of GitHub break-glass credential revocation

Context

GitHub credentials are non-human identities in practice, whether they are personal access tokens, SSH keys, OAuth tokens, or SSO-linked authorisations. The governance problem is not only exposure, but the time window between compromise detection and complete revocation across every place those credentials still work.

This article matters because incident response for NHI is often slowed by fragmented control planes. If revocation requires multiple tools, multiple permissions, or manual token-by-token cleanup, the attacker’s access frequently outlives the first containment step. That is exactly the failure mode this feature is designed to reduce.

Key questions

Q: How should teams handle incomplete credential revocation during an incident?

A: Treat incomplete revocation as an active containment failure, not a cleanup detail. Revoke every credential path tied to the compromised identity, confirm the revocation state in each control plane, and assume the attacker will reuse any surviving token, key, or SSO grant. The goal is complete invalidation before the same identity is used again.

Q: Why do service account and token revocation gaps keep causing repeat incidents?

A: Because many environments manage authentication state in fragments. A token may be removed from one console but still authorised through SSO, a linked key, or an API-managed path. If the organisation cannot remove all live trust relationships at once, the identity remains usable and the incident can reappear in a different system.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: Who is accountable when a compromised credential keeps working after cleanup?

A: Accountability sits with the team that owns the credential lifecycle and the responders authorised to cut off access. Governance frameworks expect identity state changes to be complete and auditable. If access survives the first response, the organisation has not finished containment, and the audit trail should show exactly where the revocation failed.

Technical breakdown

Why fragmented credential revocation leaves NHI access alive

A non-human identity can be authorised in several layers at once: token state, SSH key registration, SSO grant, and repository or organisation scope. If revocation only removes one layer, the credential may remain usable through another path. That is why incomplete cleanup after an incident often looks fixed at the admin console but still leaves access alive in workflows, forks, or linked services. In distributed environments, revocation is a state transition problem, not just a delete action.

Practical implication: map every credential type and revocation path before an incident so containment does not stop at the first screen.

What break-glass revocation changes in enterprise workflows

Break-glass revocation centralises a response that used to be split across token screens, API calls, and SSO settings. The operational value is not convenience alone. It is that incident responders can remove all in-scope credentials from one account or one enterprise boundary before the attacker reuses them elsewhere. This is especially important where CI/CD and developer tooling depend on multiple credential forms, because partial revocation can preserve the attacker’s foothold while breaking the wrong systems.

Practical implication: define who can invoke bulk revocation, what identities are in scope, and how audit logs will confirm complete cutoff.

Why atomic rotation remains an awkward fit for real incident response

Atomic rotation means the old and new credential never overlap in a usable state. That sounds ideal, but it is difficult in large organisations because integrations, runners, and downstream services rarely switch in lockstep. Routine rotation tolerates overlap to avoid downtime, but incident response needs the opposite behaviour. This tension is why organisations often discover that their normal lifecycle process is not strong enough for compromise scenarios. The control needed during an attack is immediate invalidation, even if it disrupts service.

Practical implication: separate routine rotation logic from incident revocation logic and test both as distinct operational runbooks.

Threat narrative

Attacker objective: The attacker wants surviving credential paths that let them regain repository or pipeline access after defenders believe the incident is contained.

1. Entry occurs when an attacker obtains a valid token, SSH key, or OAuth grant from an exposed or incompletely cleaned-up account. Escalation follows when that credential still authorises access across repositories or enterprise resources after the first response attempt. Impact lands when the attacker reuses the surviving identity to push malicious code, harvest more secrets, or re-compromise related pipelines and organisations.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Incomplete revocation is the real NHI failure, not initial compromise alone. Once a credential has been used in an attack, the security question becomes whether every authorisation path can be shut off at once. The Trivy and durabletask examples show that partial cleanup creates a second incident from the same identity. For practitioners, the control gap is not visibility alone, but the inability to revoke all live access in one governed action.

Break-glass revocation is a control for standing privilege persistence. NHI programmes often focus on discovery and rotation, but incident containment depends on eliminating the credential that still works right now. That is the difference between knowing a token exists and ensuring it no longer authorises anything. Practitioners should treat bulk revocation as a distinct lifecycle state, not just an admin convenience.

Credential cleanup has to match the blast radius of the identity, not the shape of the tool. A PAT, SSH key, and OAuth token may be different artefacts, but attackers do not care which console owns them. If revocation remains fragmented across SSO, repository settings, and APIs, the attacker keeps the longest-lived path. The implication is straightforward: governance must follow the credential wherever it is still trusted.

Atomicity is the wrong default for routine lifecycle management, but the right expectation for compromise response. Routine rotation can tolerate overlap because uptime matters, yet incident response cannot. That is why organisations need two separate models for NHI lifecycle governance: one for planned renewal and one for emergency invalidation. Practitioners should stop assuming a single rotation process can satisfy both operational and security objectives.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• That is why teams should also review Guide to the Secret Sprawl Challenge when they are rebuilding revocation and rotation processes.

What this signals

Atomic revocation is becoming a governance expectation, not an edge case. The more enterprise identities accumulate across repositories, SSO, and automation, the less tolerance there is for stepwise cleanup. The practical shift is toward defining which identities can be revoked in a single operation and which ones need a pre-agreed emergency cutoff path that breaks normal workflows.

Credential survivability is the metric to watch. If a compromised PAT, SSH key, or OAuth grant can still authenticate after the first response step, the programme has not contained the incident. Teams should measure how many minutes or systems remain exposed after revocation begins, because the attacker only needs one surviving path to keep moving.

With 28% of secrets incidents now originating outside code repositories, in Slack, Jira, and Confluence, according to The State of Secrets Sprawl 2026, response programmes have to assume compromise will not stay neatly inside one tool. That makes break-glass processes and credential inventory hygiene inseparable.

For practitioners

• Define a bulk revocation authority Assign the permission to invoke enterprise-wide credential cutoff to a named responder group and verify they can act without waiting for cross-team approval. Test the permission path for PATs, SSH keys, and OAuth grants in a controlled exercise.
• Map every credential state before an incident Document where each credential type is managed, how SSO authorisation is revoked, and which APIs can delete or disable it. Include enterprise and org-level paths so responders do not stop after removing only one access route.
• Separate routine rotation from incident invalidation Use normal lifecycle rotation for planned maintenance, but maintain a distinct emergency runbook that invalidates surviving access immediately even if it breaks CI/CD or linked automation.
• Pin build dependencies to immutable references Require GitHub Actions and similar workflows to use full commit SHAs instead of movable version tags, so a force-pushed tag cannot redirect trusted automation to malicious code.

Key takeaways

• The breach lesson is that incomplete revocation is a second vulnerability, because surviving credentials let attackers return after the first cleanup.
• The operational evidence is clear: recent NHI incidents have shown that one unrecovered credential can propagate compromise across repositories, pipelines, and partner environments.
• Teams need separate controls for planned rotation and emergency invalidation, because compromise response requires immediate trust removal, not graceful transition.

Key terms

• Break-glass revocation: An emergency control that removes a compromised identity’s access in one governed action. In NHI programmes, it is the difference between partial cleanup and complete invalidation across tokens, keys, and authorisations that may otherwise survive in different systems.
• Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.

What's in the full article

Aikido's full blog covers the operational detail this post intentionally leaves for the source:

• The full revocation workflow for enterprise owners and how the Manage enterprise credentials permission behaves in practice.
• The differences between bulk revoke, target-account removal, and EMU delete-all handling across credential types.
• The audit log and notification behaviour that follows each revocation action, which matters during incident reconstruction.
• The specific GitHub Actions handling guidance for repositories where the correct response is disabling Actions rather than revoking a token.

👉 Aikido's full post covers the revocation paths, incident examples, and workflow caveats in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.