Use a granular access token scoped to only the packages the job publishes, with write access only if it publishes, a short expiry, and an IP range where your runners allow it. Leave Bypass 2FA off unless the job truly needs it. Since November 2025 npm supports only granular tokens.
What npm documents
npm's access token page says that as of November 2025 only granular access tokens are supported and legacy tokens have been removed. Granular tokens let you:
| Setting | What it controls |
|---|---|
| Packages and scopes | Which packages or scopes the token can touch |
| Organizations | Which organizations the token is granted to |
| Expiration | How long it is valid, at least one day ahead |
| IP ranges | CIDR limits on where it can be used |
| Read only or read and write | Whether it can publish |
| Stage only | For write access, publish and stage versus stage only |
| Bypass 2FA | Skips 2FA requirements for write tokens, false by default |
Limits include up to 1000 granular tokens per account, and each token can cover up to 50 organizations and up to 50 packages, 50 scopes, or a combination of 50 packages and scopes. A token is tied to its user's permissions and cannot exceed them. If the user loses access to a package, the token loses it too.
A sensible profile for a release job
- One token per package or scope, one per pipeline. Do not share a token across projects.
- Read and write, limited to the exact packages published. Never account wide.
- A short expiry that matches your rotation habit, with a calendar reminder.
- An IP allowlist if your runners have stable addresses.
- Stored as a secret in the CI system, exposed only to the publish job on protected branches or tags.
- Bypass 2FA only if automation requires it, and then treat the token as highly sensitive. The npm page notes that when it is true it takes precedence over account level and package level 2FA for actions such as publishing.
Know the alternative
Token based publishing leaves a long lived secret to protect. Trusted publishing through OIDC avoids storing one. See npm trusted publishing walkthrough and npm maintainer account security.
If a token leaks
Revoke it, publish nothing until you have checked what was published with it, rotate related secrets, and review recent versions of every package it could reach. A token that was read only is a smaller incident than one that could publish.
Safeguard's policy gates and dependency scanning add a check on what your own releases pull in before the publish job runs.
Quick check
Can a token publish more than its owner can?
No. npm says access tokens cannot have more permission than the user at any point in time.
Is Bypass 2FA on by default?
No. It is set to false at token creation and applies to tokens with write access.
Sources
Last reviewed: 19 October 2026.
