Myth. A granular npm token created with bypass 2FA turned on can publish without a second factor. npm's own docs say it overrides account and package 2FA for actions such as publishing. Account 2FA protects your sign-in, not a token you already minted.
The claim and why people believe it
Many maintainers enable 2FA, feel covered, and then paste a token into CI. It is natural to think the account setting follows the token around. It does not, when bypass is on.
What the docs say
From the npm access tokens page:
- Bypass 2FA applies only to write tokens and defaults to false.
- When enabled, it overrides account level and package level 2FA for actions such as publishing.
- The page advises against enabling it where a package or organization requires fully enforced 2FA.
- A token cannot exceed the permissions of its owner.
- Starting August 2026, bypass tokens can no longer do identity or governance actions such as managing 2FA, creating tokens or managing maintainers. Those need an interactive challenge.
Publishing itself requires either 2FA on the account or a granular token with bypass enabled, according to the npm publishing pages. So CI that uses a token is in the second case by design.
Myth versus fact
| Statement | Verdict | Why |
|---|---|---|
| 2FA on my account stops anyone using my token | Myth | Bypass tokens skip the second factor |
| A stolen bypass token can publish a new version | Fact | That is what bypass does for write tokens |
| A stolen bypass token can change my 2FA settings | Not after August 2026 | npm says those actions need an interactive challenge |
| Scoping a token to one package limits damage | Fact | Tokens can be limited to specific packages and scopes |
| A short expiry helps | Fact | Tokens can be given an expiration date |
Limit the damage
- Prefer trusted publishing, so no long-lived secret exists. See npm trusted publishing setup and common errors.
- If you must keep a token, scope it to one package, mark it write only if needed, set an expiry and limit IP ranges. Details in how to configure an npm granular token.
- Consider stage-only tokens. The docs say they can stage versions but cannot publish directly, so a maintainer approves with 2FA first. See staged publishing.
- Put the publish job behind an approval gate.
- Know your first hour plan: your package was compromised, a runbook for maintainers.
Check for drift
Tokens pile up. Review the list on the npm site every few months and revoke anything unclear. The page says direct publishing with granular tokens is being removed in January 2027, so you will need to change the setup anyway. Check the live page for the current state.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how fast a new issue in a package can surface, which is the pace a stolen token works at too.
Quick check
Is bypass 2FA on by default?
No. The npm docs say it defaults to false and applies only to write tokens.
What is the safest CI setup?
Trusted publishing, where the registry accepts a short-lived identity from your workflow and you store no publish token at all.
Sources
Last reviewed: 19 October 2026.
