Make the token as narrow as the job: one package, read-only unless it must write, a short expiry, an IP range if your CI has a stable one, and bypass 2FA off unless a pipeline truly needs it. npm now supports only granular tokens, so these controls are the ones you have.
What changed
The npm token page states that, as of November 2025, only granular access tokens are supported and legacy tokens have been removed. If an old guide tells you to create an "automation" or "publish" token, it is out of date. Granular tokens need npm CLI 5.5.1 or later.
The settings, one by one
| Setting | What it does | Solo advice |
|---|---|---|
| Packages and scopes | Limits which packages the token can touch | Pick the one package it publishes |
| Organizations | Grants org settings access, not publishing of org packages | Usually none |
| Expiration | Date after which the token stops working, at least one day ahead | Short; renew on purpose |
| IP ranges | Restricts use to CIDR blocks | Use only if your runner IPs are stable |
| Read or write | Read-only, or read and write | Read-only for install tokens |
| Bypass 2FA | Overrides account and package 2FA for write actions | Off by default; think before enabling |
The page lists some limits: up to 1,000 tokens per account, up to 50 packages, scopes or a mix of both per token, and a token can never exceed its owner's permissions.
Bypass 2FA deserves a pause
Bypass 2FA applies only to write tokens and defaults to false. The docs say that when enabled it overrides account and package 2FA for actions such as publishing, and advise against it where 2FA must be fully enforced. The page also says that starting August 2026, bypass tokens can no longer do account identity or governance actions such as managing 2FA, creating tokens or managing maintainers. Those need an interactive challenge.
In plain terms: a stolen bypass token can publish, which is exactly why you keep it narrow and short lived.
Direct publishing is being phased out
The same page says direct publishing with granular tokens is being removed in January 2027, and recommends stage-only tokens or trusted publishing for CI/CD. A stage-only token can stage a version and deprecate versions or move dist-tags, but cannot publish directly. See staged publishing where a maintainer approves and trusted publishing setup and common errors. Check the live page for the current date before you plan around it.
A tidy-up routine
- List your tokens on the npm website and note what each one is for.
- Revoke any you cannot name a purpose for.
- Replace long-lived write tokens with trusted publishing where your CI supports it.
- Store whatever remains in your CI secret store, never in a committed
.npmrc. Our post on scoping tokens in npmrc shows the safe pattern. - Put a calendar reminder on the expiry date.
Quick check
Are legacy npm tokens still available?
The npm docs say they have been removed, and only granular tokens are supported.
Should my CI token use bypass 2FA?
Only if the pipeline cannot use trusted publishing or staging. It lets a token publish without a second factor, so keep it scoped and short lived.
Sources
Last reviewed: 19 October 2026.
