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

At a glance

What this is: GitHub’s break-glass revocation reduces the time and coordination needed to remove compromised credentials during an incident, and Aikido frames that as a fix for incomplete cleanup that allowed repeat compromise chains.

Why it matters: IAM and NHI teams should treat credential revocation as an incident-response control, because partial cleanup can leave standing access that reopens the same attack path across repos, pipelines, and related accounts.

Context

Credential revocation is the point where an identity incident either stops or becomes a repeat event. In NHI governance terms, the problem is not only whether a token or key was compromised, but whether it can be removed everywhere it is trusted before an attacker reuses it.

GitHub’s new break-glass flow is relevant because it collapses several revocation paths into one incident-time action. That matters for service accounts, PATs, SSH keys, and OAuth tokens, where delayed cleanup often leaves one surviving credential that preserves attacker access.

The underlying pattern is typical, not exceptional: organisations often have more ways to create credentials than to remove them atomically. This article focuses on that operational gap rather than on a new exploit technique.

Key questions

Q: What breaks when credential revocation is not atomic during an incident?

A: When revocation is not atomic, one surviving token, key, or OAuth grant can preserve the attacker’s foothold after the first cleanup pass. That turns a contained incident into a repeat compromise because the identity still exists in one trust path even after teams believe it was removed.

Q: Why do incomplete credential rotations lead to repeat compromise?

A: Incomplete rotation leaves an overlap window where an old credential still works while teams are cleaning up the new state. If an attacker already has that old secret or account path, they can reuse it before every trust relationship is actually revoked.

Q: How can security teams tell whether revocation readiness is real?

A: They should be able to demonstrate a tested revocation process with known timelines, defined ownership and a clean audit trail. If revocation only works when the right person is available, readiness is not real. Effective programmes can prove containment from institutional evidence, not vendor assurances.

Q: What should teams do when a GitHub account is compromised and used in pipelines?

A: They should treat the account as a live containment event, revoke all associated credentials in one action, check for surviving workflow access, and then validate that repos and runners can no longer authenticate as that identity. Partial cleanup is not enough.

Technical breakdown

Why credential revocation fails when it is split across systems

In large environments, a single account may own multiple credential types, each with its own revocation path and permission model. If revocation requires separate actions for SSO authorisations, PATs, SSH keys, and API-driven token deletion, the cleanup window stays open long enough for an attacker to reuse what survived. The architectural problem is consistency, not visibility: teams may know the credential exists but cannot guarantee that every trust path is removed at the same moment. That is why incomplete rotation becomes an attack enabler instead of a control.

Practical implication: consolidate credential inventories before incidents so you know which trust paths must be cut in one operation.

Atomic cleanup versus routine rotation

Atomic cleanup means every credential in scope is invalidated as one all-or-nothing event, with no overlap between old and new trust. That differs from routine rotation, which often keeps both credentials valid briefly so systems do not break. In a compromise scenario, overlap is the problem because an attacker only needs one surviving credential to continue operating. The GitHub use case shows why incident response and planned rotation are different control modes: one optimises continuity, the other optimises containment.

Practical implication: separate planned credential rotation from incident revocation in your operating model and approval paths.

Why break-glass revocation matters for open-source and CI/CD compromise

The Trivy and Microsoft incidents described in the article show how one incomplete cleanup can cascade into another repo, package, or pipeline. Once a credential survives, attackers can force-push tags, poison workflows, or harvest more secrets from runners that trust the compromised identity. In that environment, revocation is not a housekeeping task after the event. It is the containment boundary that determines whether compromise stays local or spreads across software delivery systems.

Practical implication: treat revocation speed as part of your CI/CD containment design, not as a post-incident admin step.

Threat narrative

Attacker objective: The attacker aims to keep a usable credential alive long enough to re-enter trusted repositories and extend compromise into build and release systems.

1. Entry began with previously stolen credentials or a workflow misconfiguration that gave the attacker a credential-bearing foothold in the organisation's GitHub estate.
2. Credential access persisted because not all tokens and keys were revoked together, leaving at least one surviving credential available for reuse.
3. Escalation occurred when the attacker reused the surviving credential to push malicious commits, force-push tags, or continue workflow abuse across related repositories.
4. Impact was repeat compromise, broader pipeline poisoning, and in some cases exfiltration or downstream disruption of CI/CD systems.

Breaches seen in the wild

• GhostAction returns 2026: GhostAction's fake security workflow hit 772 repos in Aug-Sept 2026 via stolen GitHub credentials, targeting 2,577 secrets; only 16% cleaned.
• Change Healthcare breach 2024: A stolen login on a Citrix portal without MFA led to ALPHV ransomware, a $22 million ransom and 192.7 million people affected.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Atomic revocation is a governance capability, not a convenience feature: When an organisation cannot cut off every credential tied to a compromised identity in one action, it does not really control that identity under incident conditions. The problem is not revocation volume alone but trust-path coordination across PATs, SSH keys, OAuth tokens, and SSO authorisations. Practitioners should treat this as an identity containment requirement, not an administrative enhancement.

Break-glass revocation exposes the failure of split credential ownership: The article shows how one credential type may be revoked while another survives because different tools, permissions, or teams own different parts of the cleanup. That is a classic governance gap in NHI operations. The lesson is that credential ownership without unified offboarding leaves attackers with a persistence lane.

Standing credential exposure window: This is the period between compromise and full invalidation of every credential that can still authenticate as the affected identity. In the Trivy and Microsoft examples, the exposure window was long enough for the same account to reappear in a second incident. That window is the control failure practitioners need to measure and collapse.

Incident-time revocation should be modelled as a containment control in NIST CSF terms: The relevant question is not whether credentials can eventually be rotated, but whether revocation can be executed before attacker reuse. That shifts emphasis from ordinary lifecycle hygiene to response-time enforceability. Teams that cannot prove this capability should assume repeat compromise remains possible.

GitHub’s new workflow validates a broader NHI operating principle: when revocation is slower than attacker reuse, the identity programme has already lost the incident. The operational standard for machine credentials should therefore be removal completeness, not administrative effort. Security teams should judge their tooling by how quickly it can eliminate every surviving trust path.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: Guide to NHI Rotation Challenges

What this signals

Credential cleanup now needs to be designed as a containment boundary: If revocation can be performed token by token, the organisation is assuming attackers will wait while the cleanup completes. That assumption is wrong for service accounts, GitHub credentials, and any other NHI that can be reused immediately after compromise.

Standing privilege is the real problem hidden inside revocation workflows: the control gap is not only issuing credentials, but guaranteeing that every surviving trust path dies together when compromise is confirmed. That is why incident response needs a revocation path that is faster than the attacker’s reuse path.

GitHub’s break-glass model reflects a broader shift in NHI operations. Teams should expect more pressure to prove that credential offboarding is complete, auditable, and executable under incident conditions, not just documented on paper.

For practitioners

• Define a single incident revocation owner Assign authority to one role that can revoke PATs, SSH keys, and OAuth tokens together during a live compromise, rather than splitting cleanup across teams or tools.
• Map every credential tied to each enterprise account Use the credentials inventory view to verify which tokens and keys are still associated with the account before an incident starts, including SSO-authorised and personal credentials.
• Separate planned rotation from break-glass revocation Keep routine rotation workflows distinct from incident containment so overlap windows do not become the default behaviour when an account is compromised.
• Pin workflows to immutable references Replace version tags with full commit SHAs in GitHub Actions so a force-pushed tag cannot redirect trusted pipelines to malicious code.

Key takeaways

• The article shows that partial cleanup can leave a compromised GitHub identity active long enough for an attacker to return through a surviving credential.
• The Trivy and Microsoft examples illustrate how one missed token or key can extend an incident into a second compromise event.
• Atomic revocation changes the control objective from tidy administration to complete containment, which is the standard that matters in live incidents.

Key terms

• Atomic Revocation: Atomic revocation is the removal of all authentication paths for a compromised identity in one coordinated action. In NHI operations, it matters because partial cleanup leaves surviving credentials that attackers can reuse before the incident is fully contained.
• Break-Glass Control: A break-glass control is an emergency access or emergency response mechanism used when normal workflows are too slow for active incident containment. For non-human identities, it should prioritise complete credential invalidation, auditability, and immediate execution over routine change-management flow.
• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.
• Credential containment: Credential containment is the practice of preventing end users from handling the secrets that unlock backend systems. It reduces exposure by keeping passwords, keys, and tokens out of operator workflows, but it only works when revocation and logging are tied to the same control plane.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for IAM, PAM, or machine identity governance, it is worth exploring.