Which strategy should I use for npm Legacy Access Token Removal?

Choose a production-safe npm publishing and CI authentication path now that legacy access tokens are no longer accepted.

Use npm trusted publishing with OIDC if your production CI supports it and meets npm/node minimums; use granular tokens only when OIDC isn't viable.

Blockers

Who this is for

Candidates

Use npm trusted publishing with OIDC

As of 2026-04-01, npm documents trusted publishing as the recommended path for continuous deployment because it avoids long-lived publish tokens entirely. npm says trusted publishing requires npm CLI 11.5.1 or later and Node 22.14.0 or higher. It creates a trust relationship between npm and the CI provider and allows npm to mint short-lived credentials during the workflow. npm also states that packages published via trusted publishing from GitHub Actions or GitLab CI/CD automatically get provenance attestations for public packages from public repositories, while CircleCI trusted publishing does not currently produce provenance.

When to choose

Use this when you run production publishing on GitHub Actions, GitLab CI/CD, or CircleCI and can upgrade the publishing environment to the documented Node and npm minimums. It is the best default for compliance-sensitive or enterprise workflows because it removes the publish secret rotation problem instead of replacing one long-lived token with another.

Tradeoffs

Best security posture and least secret handling for publish flows, but it depends on provider support and newer toolchain versions. Each package can only have one trusted publisher connection at a time, so provider changes must be managed deliberately.

Cautions

As of 2026-04-01, this does not eliminate all npm secrets if your CI also installs private packages; npm recommends separate read-only granular tokens for install use cases. After enabling trusted publishing, npm recommends setting package publishing access to require 2FA and disallow tokens, then revoking no-longer-needed automation tokens.

Sources

Use granular access tokens for CI, with separate write and read scopes

As of 2026-04-01, npm says only granular access tokens are supported and legacy access tokens were removed as of November 2025. For continuous deployment where trusted publishing is unavailable, npm requires a granular access token with bypass 2FA enabled to publish from CI. npm separately recommends read-only granular tokens for installing private dependencies. npm also notes that granular token creation is currently done on the website; the token docs say CLI support for creating granular tokens will be added in the future.

When to choose

Use this when your CI provider cannot use npm trusted publishing or you cannot yet meet the trusted publishing runtime requirements. It is the fallback path when production automation still needs npm authentication, but you should scope tokens narrowly and split publish versus install credentials.

Tradeoffs

Works across more environments than OIDC-based publishing and preserves existing secret-based CI patterns, but it keeps long-lived credentials in your secret store. It also adds rotation, revocation, and bypass-2FA governance work.

Cautions

As of 2026-04-01, old legacy token strings are no longer a viable emergency fallback. npm warns that bypass 2FA should only be enabled when necessary, and that it takes precedence over account-level and package-level 2FA settings; do not assume package 2FA requirements will still block token-based publishing. Granular tokens tied to org settings do not automatically grant package publish rights, and npm notes token permissions cannot exceed the user's own permissions.

Sources

Facts updated: 2026-04-01
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Which strategy should I use for npm Legacy Access Token Removal?"
Missing something? Request coverage