GitHub restricts npm 2FA-bypass tokens to reduce package supply chain risk

GitHub has tightened what npm granular access tokens can do when those tokens are configured to bypass two-factor authentication, a change aimed at shrinking one of the package registry's most exposed credential paths.

In a July 31 changelog post, GitHub said npm granular access tokens with 2FA bypass enabled can no longer perform sensitive account, organization, and package management actions. Those operations now require an interactive 2FA challenge. The company described the move as a way to close a large credential-based attack surface on the npm registry, where stolen maintainer credentials and automation tokens can become a direct route into widely used software dependencies.

What changes for maintainers

The immediate change applies only to npm granular access tokens. GitHub said it does not affect GitHub personal access tokens, GitHub App tokens, or the GitHub Actions GITHUB_TOKEN. For npm maintainers, the practical impact is that long-lived tokens should no longer be treated as a standing substitute for human approval when changing sensitive registry settings.

The update follows an earlier GitHub plan to reduce the role of 2FA-bypass tokens in npm publishing workflows. GitHub said the next step will remove direct publishing from those tokens as well. Under that planned January 2027 change, the tokens would be limited to reading private packages and staging a publish that a maintainer must approve with 2FA.

• 2FA-bypass npm granular access tokens can no longer perform sensitive account, organization, or package management actions.
• GitHub is steering automated releases toward trusted publishing with OpenID Connect or staged publishing with human approval.
• The stated target for removing direct publish from 2FA-bypass tokens is January 2027.

Why it matters

npm is a core distribution channel for JavaScript and web tooling, so registry credential policy has broad supply chain consequences. Attackers often look for credentials that let them alter packages, add maintainers, change access controls, or publish malicious versions without triggering normal review. Requiring an interactive 2FA step for sensitive actions makes stolen automation tokens less useful outside their intended workflow.

The change also reflects a wider shift away from permanent publish secrets and toward short-lived, identity-bound automation. Trusted publishing uses the identity of a build environment instead of a stored registry token, which can reduce the damage from leaked secrets in developer machines, CI logs, or compromised repositories. For teams still relying on 2FA-bypass tokens, GitHub's timeline gives a concrete migration window before the planned publishing restriction takes effect.

Sources

• github.blog
• github.blog

Cover photo by Rafael Minguet Delgado on Pexels, used under the Pexels License.