URGENT: npm classic tokens will be revoked November 19, 2025. Complete migration guide to granular access tokens and trusted publishing with CI/CD examples f...
What is changing on November 19, 2025
npm classic tokens are long-lived credentials that many teams still use in local shells, CI secrets, and deploy scripts. On November 19, 2025, those classic tokens will be revoked. After that date, any pipeline or tooling that still authenticates with a classic token will fail until you replace it. The replacement path centers on two modern options: granular access tokens with scoped permissions and expiry, and trusted publishing for CI so you can publish packages without storing a long-lived npm secret at all.
If you publish packages, run installs behind a private registry, or automate releases, treat this as a hard deadline rather than a soft recommendation. Audit where tokens live now—CI secret stores, local .npmrc files, shared team vaults, and any service that calls the npm API—so nothing is left pointing at a credential that will stop working overnight.
Migrate to granular access tokens
Granular access tokens replace the broad, open-ended classic model with tokens you can limit by package, organization, permission (read vs publish), and lifetime. Create a new token in your npm account settings, assign only the scopes your job actually needs, and set an expiration you are willing to rotate. Prefer short lifetimes for CI and automation; use longer lifetimes only where human rotation is impractical and the blast radius is small.
Update every consumer: replace the old token value in CI environment variables, rewrite .npmrc auth lines, and restart or redeploy anything that cached the previous credential. After swap-in, run a dry-run publish or a private package install against a non-production branch to confirm the new token works with the expected permissions—and fails when it should not. Revoke the classic token only after every critical path has been verified, so you still have a rollback window before the global revocation date.
- Inventory every place a classic token is stored or injected.
- Create granular tokens with least privilege and a clear expiry.
- Update CI secrets and local config, then verify install and publish flows.
- Revoke replaced classic tokens early; do not wait for the forced cutoff.
Prefer trusted publishing for CI/CD
Trusted publishing lets your CI provider prove identity to npm so a publish job can authenticate without embedding a long-lived token in secrets. Wire your repository and workflow identity to the package on npm, then configure the release job to request short-lived credentials at publish time. Keep publish steps on protected branches or tags, and restrict which workflows are allowed to publish so a compromised PR pipeline cannot ship packages.
For jobs that only need to install private packages, trusted publishing may not apply—use a read-only granular token with a narrow scope instead. Split roles deliberately: one path for install, another for publish. That separation limits damage if either credential or identity mapping is ever misused.
Checklist before the cutoff
Work backward from November 19, 2025. Schedule a full registry of token usage, migrate high-traffic release pipelines first, then developer machines and secondary bots. Document which packages use trusted publishing versus granular tokens so the next rotation is routine instead of emergency work. After migration, watch the first few release cycles closely for auth failures, permission errors, and unexpected 401/403 responses from the registry.
Teams that finish early reduce risk; teams that wait until the revocation day will face broken deploys and blocked publishes at the same time as everyone else. Complete the switch to granular access tokens and trusted publishing now, verify end-to-end, and remove classic tokens from every secret store before they are forcibly invalidated.