Because the credential itself authorises access after authentication, and many tokens are not bound to a fresh human check at request time. A password reset may not stop an already-issued session, OAuth grant, or personal access token from continuing to operate until revocation occurs.
Why bearer credentials are riskier than a password change
A GitHub bearer credential changes the security question from “who knows the password?” to “who already has an accepted token, grant, or session?” That matters because bearer credentials are often reusable until they are revoked, and they can keep working even after the human password is changed. The attacker does not need to re-authenticate if the credential still authorises requests.
How bearer credentials outlive password resets
Passwords are only one input to an account’s overall access state. A password change may invalidate the next interactive login, but it does not automatically kill every token, OAuth grant, API key, or session that was issued earlier. In GitHub-style workflows, a bearer credential can be enough on its own to call the API, push code, read private repositories, or operate automation until the token is explicitly revoked or expires.
This is why bearer credentials are often more operationally dangerous than password compromise alone. They bypass the “fresh login” moment that a password change affects, which means the defender can mistakenly believe the account is safe while a silent access path remains active. API Key Management Guide is useful here because the same revocation and scoping problem applies to bearer-style access material across systems.
Why GitHub tokens create a wider blast radius
GitHub bearer credentials usually sit close to code, automation, and secrets. That gives them a wider blast radius than a password, because a stolen token may already be trusted by CI/CD, repository integrations, deployment tooling, or scripts that never prompt a user again. If the token has broad scopes or long lifetime, the attacker gets persistent access to the exact places where secrets, source code, and release paths are concentrated.
The practical risk is not just account access, but downstream action. An attacker with a valid token can often enumerate repositories, modify workflows, exfiltrate secrets, or plant persistence in automation. Guide to the Secret Sprawl Challenge and Secrets Management Guide both reinforce the same control reality: once a bearer credential leaks, the surrounding secret ecosystem matters as much as the credential itself.
What changes after the password is changed
A password reset helps only if the compromised access path depends on the password at request time. Many bearer flows do not. Personal access tokens, OAuth grants, and cached sessions can continue to function until they are revoked, rotated, expired, or reissued under a new trust decision. That is why response has to focus on access revocation, token inventory, and scope reduction, not just password hygiene.
For GitHub specifically, the question to ask is whether the leaked material is a one-time login secret or an already-issued access instrument. If it is a bearer token, treat it as active access. The right control is usually to revoke the token, invalidate related sessions where possible, review connected apps and automation, and then verify whether the credential had access to repositories, package registries, or deployment infrastructure. Guide to NHI Rotation Challenges and Ultimate Guide to NHIs, Static vs Dynamic Secrets both help frame why revocation and short-lived credentials are the safer default.
Risk and Threat Considerations
Bearer credentials are attractive to attackers because they turn stolen material into immediate, reusable access. Password changes can create a false sense of recovery if existing tokens, sessions, or delegated grants remain valid. In a GitHub context, that can preserve access to source code, workflows, packages, and secrets even after the human login path has been reset.
Failure mechanism: The attacker keeps using an already-issued bearer token or session that is not bound to a fresh password check, so password rotation does not interrupt the active access path.
Impact: The compromised credential can continue to authenticate automation or API calls, which extends exposure, delays containment, and increases the chance of repository tampering or secret theft.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Bearer tokens that survive password resets are long-lived access material. |
| NHI-02 — Secret Leakage | Leaked GitHub tokens behave like exposed secrets with immediate access value. | |
| NHI-05 — Overprivileged NHI | Broad GitHub tokens can expose more repos and actions than needed. | |
| Recommendation — Replace durable bearer tokens with short-lived credentials and enforce explicit revocation. Scan, revoke, and rotate exposed credentials before assuming the account is safe. Constrain token scopes to the minimum access needed for each workflow. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle, revocation, and rotation are central to bearer credential risk. |
| IA-9 — Service Identification and Authentication | GitHub tokens often authenticate services, automation, and other non-human actors. | |
| AC-6 — Least Privilege | Token scope directly determines how much damage a stolen bearer credential can do. | |
| Recommendation — Manage authenticator lifecycle with rotation, revocation, and expiry enforcement. Use distinct service authenticators and validate their use independently of human passwords. Limit each credential to the smallest set of actions and resources required. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Bearer tokens are an API-style authentication mechanism that can remain valid after password change. |
| API5 — Broken Function Level Authorization | Stolen GitHub tokens may retain high-impact actions beyond the original user's intent. | |
| Recommendation — Treat active tokens as authentication material that must be revoked, not just reset. Enforce function-level authorization so tokens cannot perform privileged actions by default. | ||
Practitioner Guidance
What to verify: Confirm whether the exposed material is a password, a session, an OAuth grant, a personal access token, or another bearer credential. If it is bearer-style access, password reset alone is not containment.
Decision rule: If the token can reach production repositories, CI/CD, package publishing, or org-wide settings, revoke it first and treat scope review as part of incident response, not as a later hardening task.
What good looks like: Access is short-lived, narrowly scoped, inventoried, and revocable without depending on a user remembering to change a password after the fact.
Practitioner takeaway: The real control objective is not “change the password,” it is “remove every still-valid bearer path that can act without a fresh trust decision.”