No. One token shared by every pipeline means one leak exposes everything it can read, and one revocation breaks every build. Use a read only token per team or per pipeline, scoped to the packages it needs, with an expiry, owned by a service identity and not a person.
Why sharing hurts
A shared token has three problems.
- Blast radius. If it leaks from one pipeline log, an attacker can read whatever all pipelines can read.
- Blunt revocation. Revoking it stops every build in the company at once, so teams hesitate to rotate, and the token lives for years.
- No attribution. When registry logs show one token making a million requests, you cannot tell which pipeline caused it. That matters during a rate limit incident.
What npm gives you to work with
npm's access token documentation says that, as of November 2025, only granular access tokens are supported and legacy tokens have been removed. With a granular token you can:
- Restrict which packages and scopes it can reach.
- Grant access to specific organizations.
- Set an expiration date. The docs say it must be at least one day in the future.
- Limit use to IP address ranges.
- Choose read only or read and write access.
You can create up to 1000 granular tokens on an account, and each token can cover up to 50 packages, scopes, or a mix. Other registries have their own controls, so check yours for the same ideas.
One more line in that page is easy to miss: a token is tied to its owner's permissions. If a user loses access to a package or organization, their token loses it too. A token created by a person who later leaves, or changes team, can break builds with no change in the pipeline.
Three models compared
| Model | Pros | Cons | Fits |
|---|---|---|---|
| One token for all | Simple | Large blast radius, hard to rotate | Not recommended |
| One per team | Moderate scope, easier ownership | Still shared inside a team | Small to mid size orgs |
| One per pipeline | Smallest scope, clear logs | More to manage and rotate | Sensitive or high volume pipelines |
A sensible setup
- Create a service account for CI so tokens do not depend on one employee.
- Issue read only tokens. Publishing needs a separate write token held by a separate job. See which npm token settings for a CI publish job.
- Limit each token to the scopes it needs, and bind private scopes to your own registry as shown in npmrc scoped registry and token scoping.
- Set an expiry and put the renewal date in a calendar or ticket. Then rotate without outages using rotate a CI registry token without breaking builds.
- Restrict by IP range if your runners have stable egress addresses. If they do not, skip this control rather than breaking builds.
- Keep tokens out of pull request jobs from forks. If a job runs untrusted code, it should not see a registry credential.
Where your CI and registry support short lived credentials, prefer them to stored tokens. The reasons are in OIDC vs static credentials in CI, and the lessons from one registry's policy changes are in registry token policy lessons from npm granular tokens.
Where Safeguard fits
Fewer, narrower tokens reduce exposure but do not tell you what your pipelines pulled. Safeguard's SBOM and dependency scanning records that, and policies and gates apply the same rules across every pipeline, whichever token it uses.
Quick check
Is a read token low risk?
It is lower risk than a write token, but it can still expose private packages and source. Treat it as a credential and scope it.
Why did our builds break when someone left?
npm tokens are tied to the owner's permissions. If the owner loses access, the token does too. Use a service account for CI tokens.
Sources
Last reviewed: 19 October 2026.
