npm walls off 2FA-bypass tokens from account and package management

A token that skips 2FA is a bad idea (until you need one at 3am)

You automate your npm publishes with a token that skips the 2FA prompt, because robots do not punch codes into a phone. Then the token leaks. Now the attacker has your automation, your account settings, your maintainer list, and a fresh batch of tokens they minted for themselves on the way out. Comforting.

As of July 31, npm has cut the second half of that story off. Granular access tokens (GATs) configured to bypass 2FA can still do their day job, but they can no longer touch the account behind it. GitHub's changelog puts it plainly: a token that skips 2FA should not also be a way to manage the account.

What flipped over

Bypass-2FA GATs now hit an interactive 2FA challenge whenever they try to:

• create or delete tokens,
• change package access, maintainers, or trusted publishing configuration,
• manage organisation or team membership, or package grants.

None of those are automation workloads. They are the things an attacker does after they have your token, to make sure they keep it. A leaked bypass token used to be a foothold that could bootstrap into full account takeover. Now it is a leaked publish key with a much smaller blast radius: still bad, but not "add a new maintainer and quietly retire you" bad.

Direct publish, at least for the moment, still works.

Why the convenience tier was the whole problem

Every team that ships packages has faced the same three-door choice. Force the CI job to interact with a 2FA prompt (fun). Stash a long-lived credential somewhere the pipeline can read (dangerous). Or mint a token that simply skips 2FA (dangerous, but ergonomic). Enough teams picked door three that "bypass-2FA GAT" became a category of credential, and inevitably a category of credential that leaks.

The failure mode was never that these tokens could publish. It was that one leaked token could publish, extend itself, add friends, and mint more tokens. That self-perpetuating loop is what npm just broke.

What to do this week

GitHub's own guidance is blunt: move automated publishing off bearer tokens.

• Trusted publishing (OIDC). The CI runner asks the registry for a short-lived credential using its workload identity, on the fly. No secret in the repository, no long-lived token sitting in a vault waiting to leak. If your pipeline runs anywhere that mints OIDC tokens, this is the path.
• Staged publishing. Push to a staging area, then require an interactive step to promote to the real package. Works well where a human is already in the loop for a release.

If you still need a GAT for publishing, at least prune it. Scope it to the exact packages that need pushing. Give it the shortest life you can stomach. And drop the bypass-2FA flag on any GAT whose only real job was management, because there is now no reason to keep it: management is exactly what it can no longer do.

Two questions your platform team should answer before Friday. Which pipelines currently authenticate to npm with a bypass-2FA GAT? And for each, is that token doing anything other than npm publish? If yes, that thing just started requiring 2FA, and probably already broke.

The January 2027 clock

GitHub has already telegraphed the next step. Bypass-2FA tokens will lose direct publish rights too, targeted for January 2027. The trajectory is not subtle. The registry is walking the ecosystem off long-lived bearer tokens for anything that touches a package, one verb at a time.

If your OIDC-based publishing rollout has been living on the "we will get to it" board for a while, you have roughly one release cycle to change your mind. Tokens that skip a security control tend to end up on someone else's laptop. Yours, or theirs.