What breaks when a vendor-shared GitHub PAT is not revoked?

A vendor-shared GitHub PAT becomes an orphaned non-human identity, which means it can keep providing standing access long after the original business purpose ends. The failure is lifecycle governance, not authentication strength. If the token can still reach production systems, it can be reused for legitimate API activity, lateral access, or data extraction until someone explicitly revokes it.

Why This Matters for Security Teams

A vendor-shared GitHub PAT that is never revoked is not just an unused token. It is a standing non-human identity that can outlive the contract, the project, and the intended access boundary. That creates a lifecycle failure: the token still authenticates, but governance has disappeared. NHIMG research shows only 20% of organisations have formal offboarding and revocation processes for API keys, and 91.6% of secrets remain valid five days after notification, which is exactly how stale access turns into real exposure.

For security teams, the risk is broader than repository access. A valid PAT can be used to read source, modify automation, trigger workflows, or pull additional secrets from linked systems. That is why the issue belongs in NHI lifecycle control, not just vendor management. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the OWASP Non-Human Identity Top 10 both frame revocation as a core control, not an afterthought. In practice, many security teams discover stale vendor tokens only after repository access has already been reused for another purpose.

How It Works in Practice

When a vendor shares a GitHub PAT, the token usually carries more reach than the immediate task requires. If the token is not revoked at the end of the engagement, the vendor account may disappear from the business relationship while the credential remains active in GitHub. At that point, the token behaves like an orphaned NHI: still valid, still accepted, and often still able to access the same repositories, workflows, and secrets it could before.

The practical failure is usually one of missing state changes. A proper offboarding flow should link vendor exit, access review, token inventory, rotation, and revocation. Current guidance suggests treating PATs as short-lived operational credentials, even when the platform technically allows longer-lived use. That means:

• Inventory every vendor-issued PAT and associate it with a named owner, business purpose, and expiry date.
• Revoke the token when the vendor task ends, not when someone remembers to clean up later.
• Replace standing PAT access with finer-grained, time-bound alternatives where possible.
• Monitor repository, workflow, and API activity for continued use after contract termination.
• Use vaulting and lifecycle controls so token status changes are visible to security and platform teams.

The NHI Lifecycle Management Guide and the Guide to the Secret Sprawl Challenge both emphasise that exposure persists when secrets are duplicated across code, chat, and CI/CD tooling. For implementation detail, GitHub token governance should be aligned with the least-privilege expectations described in the OWASP Non-Human Identity Top 10 and with API key revocation patterns discussed in NHI lifecycle practice. These controls tend to break down in large vendor ecosystems because token ownership becomes unclear once contractors, integrators, and platform admins all touch the same access path.

Common Variations and Edge Cases

Tighter token governance often increases operational overhead, requiring organisations to balance speed for vendors against the need to prevent orphaned access. That tradeoff becomes sharper when a single PAT supports multiple repositories, automation jobs, or support rotations, because revocation can interrupt unrelated work if dependencies are not mapped first.

There is no universal standard for how every vendor PAT should be structured, but current guidance suggests avoiding shared long-lived tokens wherever possible. Short-lived, task-specific credentials are safer because they narrow the window for misuse and make offboarding deterministic. If a vendor insists on a shared token, the organisation should treat it as a high-risk exception with explicit expiry, owner assignment, and monitoring. The same logic applies when tokens are embedded in CI/CD or copied into tickets and chat channels, where revocation alone may not fully remove exposure if clones remain active. For broader context, the Guide to NHI Rotation Challenges is useful when rotation is operationally difficult, and the Top 10 NHI Issues shows how stale secrets and excess privilege compound each other. In practice, the failure becomes most visible in environments with shared service accounts, weak asset inventory, and no reliable handoff from procurement to security.

Related resources from NHI Mgmt Group

• What breaks when security teams rely on content guardrails to control AI agents?
• Why are GitHub audit logs not enough to detect PAT misuse?
• What breaks when vendor access is not governed before a SaaS incident?
• What breaks when shared clinical devices are not tied to clear ownership?