npm Token Migration: Everything to Fix by Nov 19

The npm token migration just went from “plan for it” to “ship it now.” As of November 5, 2025, you can no longer create classic tokens, and on November 19, 2025, every remaining classic token is revoked. At the same time, granular write tokens top out at a 90‑day lifetime and enforce 2FA by default, with a CI‑friendly bypass you must opt into. If you publish packages or even just install private ones in CI, your pipeline is squarely in scope.

What changed this week—and the exact dates

Let’s anchor the timeline. On November 5, 2025, npm disabled creation of classic tokens across the website, CLI, and API. Existing classic tokens continue to function only until November 19, 2025, when they’ll be permanently revoked. Granular access tokens that have write permissions are now limited to a maximum 90‑day lifetime; tokens that were set to expire after February 3, 2026 have been adjusted to that date. New write‑capable tokens enforce 2FA by default. There’s also a new “Bypass 2FA” option designed specifically for CI/CD so non‑interactive jobs don’t get stuck.

In parallel, npm has been expanding trusted publishing (OIDC) so you can publish from GitHub Actions and GitLab.com shared runners without storing long‑lived tokens. For trusted publishing, make sure you’re on npm CLI 11.5.1 or later, set id-token: write in your workflow permissions, and configure the repo/workflow pair as a trusted publisher in your package settings.

npm token migration: what actually breaks on Nov 19?

Two things break fast. First, any job that relies on a classic token for npm publish or for installing private packages will fail once those credentials are revoked. Second, teams that swap classic tokens for granular write tokens but forget the 2FA default will find CI jobs prompting for an OTP they can’t enter. That’s where the CI Bypass 2FA flag or trusted publishing comes in.

There’s a quieter failure mode, too: pipelines that use old macOS images or outdated Node versions can fail right as you attempt the migration. macOS runner images began removing Node.js 18 (EOL), among a few other toolchain updates, starting November 3. If your build matrix still depends on Node 18 on macOS, you’ll see red at the exact moment you’re trying to fix auth.

Tokens vs OIDC: which path should you take?

Here’s the thing—there isn’t a single “right” answer. I recommend deciding by constraints and risk appetite.

If you need speed today

Switch production pipelines to granular access tokens with the minimum scopes and enable the CI Bypass 2FA option only where you publish. Keep read‑only granular tokens for installs. Plan a follow‑up to move publishes to OIDC.

If you can spend a day hardening

Go straight to trusted publishing. It removes long‑lived write tokens entirely and gives you short‑lived, provenance‑friendly credentials during the run. It also makes rotation a non‑event—you’re not rotating anything.

Security posture and auditability

Trusted publishing gives you cryptographic provenance for public packages, better change traceability (because the permission is bound to a specific workflow file), and no secrets to leak in logs. Granular tokens are still solid—especially if you scope them tightly and rotate on a schedule—but someone still has to own the rotation and access hygiene.

The concrete cutover checklist (run this now)

Let’s get practical. Below is a 12‑step cutover I’ve used with client teams that balances speed and safety.

1. Inventory where tokens live. Search repos and CI variables for NPM_TOKEN, //registry.npmjs.org/:_authToken, or _auth in .npmrc files. Don’t forget org‑level secrets and self‑hosted runner ENV files.
2. Decide per pipeline: token or OIDC. For every publishing pipeline, choose either granular token with 2FA bypass or trusted publishing.
3. If using granular tokens: create new tokens with scopes. Use read‑only for install‑only jobs and write for publishes. Turn on Bypass 2FA only for the write token. Record the 90‑day expiry.
4. If using trusted publishing: configure the package’s trusted publisher. In npm package settings, bind the exact repo and workflow filename. Then in your workflow, grant permissions: id-token: write and use npm CLI 11.5.1+.
5. Update workflows. For Actions, consider switching to the maintained actions/setup-node@v5, ensure the Node version you declare actually exists on your runner images, and remove token references if you’re using OIDC.
6. Lock down .npmrc. For CI, prefer environment variables over committing //registry.npmjs.org lines. If you must use .npmrc, keep it in CI only and template it during the run.
7. Rotate or revoke legacy tokens. Anything unused or with broader scopes than necessary should be revoked now, not later.
8. Test a dry run. Use npm publish --dry-run on a prerelease branch, or publish to a canary tag to validate auth and provenance before touching latest.
9. Check macOS runners and Node versions. If you run on macOS, update your matrix off Node 18. Consider the M2 macOS runners for speed and stability.
10. Add monitors. Alerts on failed publishes, token expiry (set a 60‑day reminder), and workflow file drift help you catch regressions quickly.
11. Document the process. One page in the repo: how to rotate tokens, how OIDC is configured, who owns what.
12. Schedule a post‑Nov 19 audit. Confirm there are zero classic tokens left and that granular write tokens all have short lifetimes and narrow scopes.

People also ask: quick answers

What happens if I do nothing on November 19, 2025?

Anything using a classic token will stop authenticating—publishes will fail, private installs may fail, and release automation dependent on those tokens will stall. You’ll be triaging outages during your next release window.

Do I need 2FA in CI now?

Not interactively. New granular write tokens enforce 2FA by default, which will block non‑interactive jobs unless you enable the CI‑specific bypass when creating the token. Trusted publishing avoids this entirely because it relies on short‑lived OIDC credentials, not your user’s 2FA.

Will self‑hosted runners work with trusted publishing?

Today, trusted publishing supports GitHub‑hosted runners and GitLab.com shared runners. If you rely on self‑hosted, use granular tokens for now or split publish to a hosted runner job. Revisit trusted publishing support as it expands.

What npm CLI version do I need for OIDC?

Use npm CLI 11.5.1 or later. Older CLIs won’t automatically perform the OIDC exchange during npm publish.

GitHub Actions updates you should factor into this cutover

While you’re touching build infra, fold in the November Actions changes. Reusable workflow limits were raised to 10 nested calls and 50 total calls in a run, which helps break big pipelines into clean modules without hitting ceilings. Apple Silicon (M2) macOS runners are GA across labels like macos-15-xlarge and can cut minutes off Node and mobile builds. The Copilot coding agent no longer requires Actions to be enabled at the org level, which simplifies org‑wide policy. If you need a deeper dive on the Actions changes, see our write‑up on what changed in GitHub Actions this month.

One more operational note: macOS runner images began removing Node.js 18 starting November 3. If your workflow matrix.node-version still includes 18 on macOS, change it to 20 or 22. If you truly must test 18 for Linux, pin a Docker image where it’s still available—but don’t publish with it.

Common traps we’ve seen in real migrations

Workflow filename mismatches. Trusted publishing validates against the exact workflow filename you configured in package settings. If you refactor from release.yml to publish.yml without updating settings, OIDC auth will fail.

Private dependency installs. Trusted publishing only covers npm publish. Installs for private packages still need a read‑only token, even if you’re publishing via OIDC. Use a separate granular token with the narrowest scope.

Forgotten org‑level secrets. Teams revoke repo secrets and overlook org‑level NPM_TOKEN that’s inherited by dozens of repos. Audit at the org level.

Token sprawl in .npmrc. Developers sometimes commit auth lines to the repo. Move them to CI variables and generate .npmrc at runtime.

Expiry drift. Granular tokens expiring in 90 days means you will hit a release that coincides with expiry. Create a calendar rotation job at day 60, or better, move publishes to OIDC and keep only read‑only tokens to rotate.

Sample GitHub Actions snippets (safe defaults)

Trusted publishing (OIDC) for a public package

Add to your workflow:

permissions:\n id-token: write\n contents: read\n

Then use npm@>=11.5.1 with a standard publish step. No secret token required, and provenance is generated automatically for public packages from public repos.

Granular tokens for private installs

Store a read‑only granular token as a CI secret and generate .npmrc at runtime:

echo "//registry.npmjs.org/:_authToken=${NPM_READ_TOKEN}" >> ~/.npmrc

Use different secrets for read and write flows—don’t reuse the same token for both.

How this intersects with Copilot premium requests

November is busy. On November 18, 2025, GitHub will remove the $0 account‑level budget for Copilot premium requests for enterprise and team accounts created before August 22, 2025. If you haven’t set a spending policy, you could see unexpected charges as those requests fall back to your paid usage rules. We wrote a practical guide on budget controls and entitlement reports—read how to avoid surprise Copilot bills on Nov 18 and tune your limits before the switch.

A minimal, durable policy for 2026

Here’s a policy I like for companies that publish several packages:

• Publish via OIDC only. Trusted publishing for public packages; provenance turned on by default.
• Read‑only tokens for CI installs. Separate org‑level secret rotated every 60 days.
• No write tokens in repos. If you truly need one, scope it to a single package and environment, and enable the 2FA bypass only for that token.
• Pin Node 20 or 22 for macOS builds. And update runners to M2 where it improves wall‑clock time.
• Monitor failures and expiries. Alerts for publish failures, OIDC denial, and token expiry.

What to do next

If you’re short on time, prioritize in this order:

1. Replace every classic token in CI today. Either move publishes to OIDC or create granular tokens with the CI 2FA bypass enabled.
2. Validate a canary publish from CI using your new method.
3. Rotate or revoke any lingering tokens and clean up .npmrc.
4. Update macOS and Node versions in your matrix to avoid collateral failures.
5. Set budget controls for Copilot premium requests ahead of November 18 if your org is affected.

If you want a deeper, step‑by‑step playbook with screenshots and cutover timelines, use our field‑tested guide: our CI/CD playbook for the Nov 19 cutover. And if you’d rather have a partner run point on this, our DevOps services team can execute the migration, retrofit trusted publishing, and harden your pipelines without stalling releases.

Zooming out

This migration is about more than swapping a token. It pushes the Node ecosystem toward short‑lived credentials, provenance, and least privilege by default. The short‑term pain—rotating tokens, renaming workflows, nudging Node versions—buys you a simpler, safer release posture that won’t wake you up at 3 a.m. because a leaked token let someone ship malware under your name.

If you want to explore adjacent changes in the automation stack, read our take on GitHub Actions’ November updates and keep an eye on our blog for post‑Nov 19 follow‑ups.