npm classic tokens are revoked — trusted publishing or granular tokens?
Choose a secure package publishing strategy after npm token policy changes by weighing trusted publishing, granular access tokens, and CI provenance requirements against repository topology, private packages, and release automation needs.
Blockers
- December 9, 2025: classic tokens revoked; npm login now issues two-hour session tokens
- Requires package/npm-cli-11.5 npm CLI 11.5.1 (Trusted publishing requires npm CLI 11.5.1+ and Node 22.14.0+)
- Requires runtime/nodejs-22.14 Node 22.14.0 (Trusted publishing requires npm CLI 11.5.1+ and Node 22.14.0+)
- Only supported on GitHub Actions, GitLab CI/CD, and CircleCI cloud; self-hosted runners not supported; each package can have only one trusted publisher connection; OIDC auth limited to npm publish only
- Trusted publishing only covers publish; private package installs still need read-only granular tokens; granular tokens limited to 1000 per account, 50 orgs and 50 packages/scopes per token
- protocol/oidc-trusted-publishing incompatible with capability/self-hosted-runner: npm trusted publishing only supported on GitHub Actions, GitLab CI/CD, and CircleCI cloud runners; self-hosted runners are not supported
Who this is for
- low-ops
- compliance
- enterprise
- small-team
- monorepo
Candidates
Trusted publishing on GitHub Actions or GitLab CI/CD, then disallow tokens
Best default for public-package automation on supported cloud runners. As of 2026-03-15, npm recommends trusted publishing over access tokens, requires npm CLI 11.5.1+ and Node 22.14.0+, and automatically publishes provenance attestations when the publish runs from GitHub Actions or GitLab CI/CD for a public package in a public repository.
When to choose
Choose this for compliance + low-ops or small-team + monorepo setups where releases already run on GitHub-hosted or GitLab.com shared runners, each package can map to one canonical publish workflow, and you want token-free publishing plus provenance without managing write-token rotation.
Tradeoffs
This removes long-lived publish secrets and lets you harden the package setting to "Require two-factor authentication and disallow tokens" after migration. The main limits are platform fit and topology: trusted publishing is only supported on GitHub Actions, GitLab CI/CD, and CircleCI cloud, self-hosted runners are not supported, and each package can have only one trusted publisher connection at a time.
Cautions
Trusted publishing only covers the publish operation. If the workflow must install private npm dependencies, you still need a separate read-only granular token for install steps. Verify the workflow filename and other npm-side settings exactly, because npm does not validate them when you save the trusted publisher configuration.
Trusted publishing even when provenance is unavailable or partial
Use trusted publishing for token-free CI publishes even if you cannot get npm provenance. As of 2026-03-15, npm documents that CircleCI trusted publishing does not generate provenance, and automatic provenance also does not apply when publishing from a private repository or when the package is private.
When to choose
Choose this for enterprise + monorepo or small-team + compliance cases where your CI provider is still a supported cloud provider, but your repository topology is private, your package is private, or your release automation is on CircleCI and you value removing publish secrets more than you need npm provenance badges.
Tradeoffs
You still eliminate long-lived publish tokens and keep the CI publish path cleaner than a bypass-2FA token workflow. The downside is weaker supply-chain signaling to downstream consumers because npm provenance is unavailable in these cases, and private-package workflows may still need read-only tokens for dependency installation.
Cautions
Do not assume trusted publishing automatically solves all authentication. npm documents that OIDC auth is currently limited to `npm publish`, so install, view, and access flows still use traditional auth. Private packages require a paid npm user or organization account as of 2026-03-15; check npm's official products page for current pricing.
Granular access tokens for unsupported CI, self-hosted runners, or mixed install/publish automation
This is the fallback when trusted publishing is unavailable. As of 2026-03-15, npm only supports granular access tokens, and npm documents package- and scope-level permissions, expirations, CIDR restrictions, read-only vs read-write modes, and optional bypass 2FA for automated write workflows.
When to choose
Choose this for enterprise + microservices or monorepo + compliance environments that publish from Jenkins, Azure DevOps, self-hosted GitHub runners, or other unsupported systems, or where a single automation context must both install private packages and publish packages without migrating the whole release system to a supported OIDC flow.
Tradeoffs
Granular tokens work across more CI topologies and can be tightly scoped to packages, scopes, organizations, IP ranges, and expiry windows. The cost is ongoing credential lifecycle work: rotation, secret storage, secret scanning exposure risk, and policy review around bypass 2FA for noninteractive publishes.
Cautions
For CI/CD publish flows, npm says you must enable bypass 2FA on the granular token if trusted publishing is not available. That bypass overrides account-level and package-level 2FA checks unless the package setting is changed to "Require two-factor authentication and disallow tokens," in which case granular tokens cannot publish at all. Also note the current scale limits: up to 1000 granular tokens per account, with each token limited to up to 50 organizations and up to 50 packages and scopes combined.
Interactive publishing with 2FA and short-lived npm login sessions
Use manual publishing when you want the strongest human-in-the-loop control and do not need unattended release automation. As of 2026-03-15, npm's December 9, 2025 security update says `npm login` now issues two-hour session tokens, and npm recommends the package setting that requires two-factor authentication and disallows tokens.
When to choose
Choose this for compliance + enterprise or small-team + cost-sensitive releases where publishes are infrequent, a human approval step is desirable, and you want to avoid both CI write tokens and trusted-publisher setup complexity.
Tradeoffs
This gives the narrowest publish path because maintainers must authenticate interactively and respond to 2FA prompts, and package settings can block granular tokens entirely. The downside is operational friction: it does not scale to unattended release trains, scheduled releases, or multi-package automation.
Cautions
This is a poor fit for continuous deployment, because npm documents that maintainers must publish interactively when token use is disallowed, and the current npm login sessions expire after two hours. If you later automate releases, you will need to move to trusted publishing or reintroduce granular tokens.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "npm classic tokens are revoked — trusted publishing or granular tokens?"