Because revocation only removes the OAuth path, not every active credential bound to the account. If an attacker has already planted an SSH key, they can keep accessing repositories even after the original token is gone. Effective containment must remove all attacker-created credentials, not just the first one discovered.
Why revocation misses an added SSH key
Revoking the original token only cuts off that specific credential path. If an attacker has already added an ssh key to the account, they have created a second, independent way to authenticate and continue operating. That is why incident response has to treat account access as a set of live credentials, not a single token to invalidate.
SSH keys are durable credentials, so they behave differently from short-lived session artifacts. Once a key is present in the account’s authorized access paths, revoking OAuth access does not automatically touch it. The same containment problem shows up in broader credential exposure incidents such as token and session security and SSH key and SSH certificate management: one credential can be gone while another remains valid.
Why the attacker still has a working path
GitHub account access is not limited to OAuth tokens. An attacker who adds an SSH key has effectively enrolled a new credential tied to the account or repository access scope, so the key survives token revocation unless defenders remove it explicitly. That persistence is why credential incident response must include discovery of keys, tokens, app grants, and any other access path the attacker may have created.
In practice, the threat is not just unauthorized read access. A planted SSH key can preserve write access, enable stealthy persistence, and let the attacker re-enter after the original compromise is “fixed.” The same pattern appears in GitHub and Bitbucket token breach reporting and stolen GitHub token incidents, where one exposed credential is only part of the attacker’s usable access.
What containment has to remove
Effective containment starts with enumerating every credential and authorization path attached to the account: OAuth tokens, SSH keys, app installations, recovery options, and any delegated access that could still authenticate. If only the obvious token is revoked, the attacker may retain repository access through the back door they already planted.
The strongest remediation pattern is to rotate or revoke all active credentials, remove unknown SSH keys, invalidate sessions, and review account-level permissions for any persistence mechanism the attacker could have added. Guides on API key management and secret sprawl reinforce the same operational lesson: the dangerous state is not “a token leaked,” it is “an attacker can still authenticate somewhere.”
Risk and Threat Considerations
An added SSH key turns a token incident into persistence risk. If defenders only revoke the first stolen credential, the attacker can keep accessing code, secrets, or deployment paths through the newly planted key, often without any further user interaction.
Failure mechanism: The attacker establishes a second valid authentication path before the original token is revoked, so containment removes one credential but leaves another intact.
Impact: The attacker can preserve repo access, bypass incomplete remediation, and continue using the account for exfiltration, tampering, or lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | SSH keys left behind keep attacker access alive after token revocation. |
| NHI-02 — Secret Leakage | The incident hinges on an exposed credential path that remains usable. | |
| Recommendation — Remove all attacker-created credentials and verify no residual access remains. Revoke leaked credentials and search for any alternate authentication paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central when revocation must cover tokens and SSH keys. |
| IA-2 — Identification and Authentication (Organizational Users) | Account access persists only because another authenticator still proves the user identity. | |
| Recommendation — Revoke, rotate, and inventory all authenticators tied to the affected account. Validate that every active authenticator tied to the identity is removed or reset. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The issue is failure to manage all identifiers and authenticators attached to the account. |
| Recommendation — Review and remove unauthorized identity bindings and access paths promptly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account-level credential cleanup is required to stop continued access after compromise. |
| Recommendation — Inventory and disable unauthorized account access paths immediately. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Adding an SSH key is account manipulation that establishes persistence. |
| Recommendation — Hunt for account changes that preserve attacker access and remove them. | ||
Practitioner Guidance
What to verify: Check the account’s SSH keys, OAuth grants, session state, app authorizations, and any repository deploy keys before declaring containment. If you cannot prove each access path was removed, assume the account is still live.
Decision rule: If the attacker could have changed the account, treat this as credential persistence rather than token theft alone. Revoke the token, then immediately remove unknown SSH keys and invalidate every other active credential attached to the identity.
Practitioner takeaway: Token revocation is only a partial response when attackers can add credentials of their own, so containment must target the whole authenticated surface, not the first leaked secret.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org