npm Token Migration: The 7‑Day Cutover Plan

Here’s the thing: on November 19, 2025, classic npm tokens are being revoked. If your CI still leans on one, your publish step will fail the moment that switch flips. This guide gives you a pragmatic, 7‑day plan to complete your npm token migration with minimal disruption—moving to trusted publishing (OIDC), rotating granular tokens when they’re truly needed, and locking in 2FA the right way. (github.blog)

What changed on November 5—and what breaks on November 19

On November 5, GitHub disabled creation of new classic npm tokens across the site, CLI, and API. Existing classic tokens keep working until November 19, 2025, when they’re permanently revoked. New write-capable granular tokens now enforce 2FA by default and are capped at a 90‑day maximum lifetime; a Bypass 2FA option exists for CI (off by default). Local/manual publishing is shifting to short‑lived session tokens. Also important: this is about npm tokens, not GitHub PATs. (github.blog)

GitHub’s community timeline clarifies two key details teams miss during planning: any granular write token set to expire after February 3, 2026 is adjusted to that date (90 days from Nov 5), and the Nov 19 cutoff is hard—classic tokens die that day. Plan rotation and pipeline cutover accordingly. (github.com)

Trusted publishing using OpenID Connect (OIDC) is generally available for npm. It lets your workflow authenticate to the registry without storing long‑lived secrets, and it automatically produces provenance for public packages published from public repositories—cryptographic proof of where and how a package was built. (github.blog)

Who is most at risk?

Any repo that still publishes with NPM_TOKEN (classic) in CI. That includes open source maintainers with a single GitHub Actions job, teams with self-hosted runners that copied secrets years ago, and enterprises with dozens of services sharing the same env-level secret. If you haven’t validated OIDC or granular tokens in the last week, assume you’re exposed.

Zooming out, the security context matters. Supply‑chain attacks have been relentless, and the move toward short‑lived credentials plus registry‑verified identity is the right response. If you needed a wake-up call, the recent critical command injection in the React Native community CLI reminded everyone how quickly a dev‑tooling hole can expose machines and networks. Don’t wait for an incident to force your hand. (advisories.checkpoint.com)

The npm token migration checklist (7‑day sprint)

This is the plan we’ve been running with client teams all week. Adjust day allocations to your org’s size, but keep the order. We’ll favor OIDC trusted publishing everywhere possible and reserve granular tokens for edge cases.

Day 1 — Inventory and freeze risky changes

Start by enumerating every publish path:

• Search for NPM_TOKEN, //registry.npmjs.org/:_authToken, and any npm publish in your org’s repos.
• List environment/organization secrets in CI that contain npm tokens.
• Catalog what publishes from local workstations vs. CI. If local is required, note who does it and how often.

Announce a temporary freeze on creating new classic-token based pipelines. Make it explicit that Nov 19 (Wednesday) is a hard stop for classic tokens—no exceptions. If you must publish locally after the cutoff, plan to use the new 2‑hour session tokens plus 2FA. (github.blog)

Day 2 — Stand up trusted publishing (OIDC) in one repo

Pick a low-risk package and wire up OIDC trusted publishing with your CI system (GitHub Actions or GitLab CI both work). Validate the publish path end-to-end. flip the package settings to “disallow tokens” only after a successful OIDC publish. Provenance will be generated automatically for public packages from public repos—verify it in the package page. (github.blog)

Tip: restrict trusted publishers to a single workflow file on a specific branch (for example, .github/workflows/release.yml@main). Then implement environment protection rules (reviewers, concurrency) to keep the release lane tight.

Days 3–4 — Roll out OIDC to the rest

Now scale. For monorepos, define a single reusable release workflow and call it from each package’s job. As of early November, you can nest up to 10 reusable workflows and call up to 50 per run—use that headroom to keep logic DRY. (github.blog)

After each repo’s first successful OIDC publish, update that package’s settings to require 2FA and disallow tokens. Move methodically—prove the path, then lock it down. The order matters. (docs.npmjs.com)

Day 5 — Granular tokens for genuine exceptions

Some rare cases need tokens: legacy CI that can’t do OIDC yet, air‑gapped builders that sync to a publisher, or third‑party release tools. For those, create granular tokens with the narrowest scope, enable the Bypass 2FA flag only for headless CI, and set a lifetime under 90 days (it’s enforced for write permissions now). Calendar a rotation before February 3, 2026 if any token got auto‑clamped to that date. (github.blog)

Day 6 — Lock in strong 2FA and local publishing plan

Move maintainers to FIDO/WebAuthn hardware keys or platform passkeys, and run a live test for anyone who still needs local/manual publishing. Expect 2‑hour session tokens for local flows post‑cutover; that’s the new normal. Document the path, including how to recover when a device is lost. (github.blog)

Day 7 — Kill classic tokens and run the game day

Revoke all remaining classic tokens. Execute a “dry run release” across critical packages: simulate version bumps, run build steps, and ensure publish jobs authenticate via OIDC or approved granular tokens. Leave monitoring on for package publish events and provenance validation.

Reference architectures you can copy

Monorepo with package sets

Use a root release workflow that builds once and then triggers per‑package publish jobs via a reusable workflow. Gate the final publish behind an environment with reviewers (release managers). Cache node_modules aggressively but keep the OIDC identity at the publish boundary—build anywhere, authenticate only at publish.

Multi-repo with shared workflow library

Put your release workflow in a dedicated repo, then call it via reusable workflow references (pin to a commit SHA). With the November limit increases (10 nested, 50 total calls), orgs can standardize release logic without nasty duplication. Just remember to scope the trusted publisher at the target repo and branch. (github.blog)

Local-first teams

If your team insists on local releases, keep it safe: enforce passkeys, document the 2‑hour session token flow, and move long‑lived credentials out of the picture entirely. Consider an internal “release station” VM with physical key login if you must centralize.

People also ask: quick answers

Does this affect GitHub personal access tokens?

No—this change is about npm registry tokens. GitHub PATs, fine‑grained tokens, and other GitHub auth are not part of this cutoff. (github.blog)

Can we still publish from local machines after November 19?

Yes, but you’ll authenticate with new short‑lived session tokens and 2FA. Plan for a slightly different workflow and train maintainers ahead of time. (github.blog)

We use GitLab—does trusted publishing work?

Yes. Trusted publishing with OIDC is GA for npm and supports publishing from specific GitHub Actions or GitLab CI/CD workflows. Scope it tightly to the workflow and branch you trust. (github.blog)

Should we turn on “disallow tokens” right away?

Not until you’ve proven an OIDC publish for that package. Once it works, enabling “disallow tokens” and 2FA requirements is a great safety net. (docs.npmjs.com)

Risk hotspots and edge cases we keep seeing

1) Environment-level secrets shared across dozens of repos. When a single classic token backs a whole org, revocation on Nov 19 can take out your entire release surface. Replace with OIDC; if you must keep a token for a corner case, scope it per repo and per package, and rotate it under 90 days. (github.blog)

2) Monorepos with independent teams. One team flips to OIDC while another keeps a classic token in a legacy workflow. On Nov 19, half your releases break. Use a tracked migration board and a single reusable release workflow so every package shares the same trust model. The new reusable‑workflow limits make this easier. (github.blog)

3) Private packages and internal registries. Provenance currently auto‑generates for public packages from public repos when using trusted publishing. If you publish private packages, don’t expect the provenance badge to appear; verify your policy independently. (docs.npmjs.com)

4) Security policies that mandate “2FA everywhere” but ignore CI. Remember: CI doesn’t type codes. If you enable 2FA broadly, ensure the Bypass 2FA option is set only on granular tokens used in headless CI paths—and prefer OIDC to remove tokens altogether. (github.blog)

5) Delayed hardware key rollouts. If you’re mailing keys to maintainers, ship now. Where passkeys are viable, enroll them this week. Do live drills before Nov 19 so the first 2FA prompt isn’t at release time.

Let’s get practical: your migration board

Create a simple kanban with four columns: Inventory → OIDC pilot → OIDC rolled out → Revoke tokens. Each row is a package, not a repo. Why? Because the risk sits where the credential meets the registry, and that’s at the package boundary. Track owner, release workflow path, last publish, and whether “disallow tokens + 2FA” is enabled.

Run a daily 15‑minute standup until the board is empty. Your goal by November 18: every package either publishes via OIDC or uses a compliant granular token with a known rotation date and Bypass 2FA set only where truly necessary. On the 19th, revoke anything left in the first two columns.

What this means for budgets and velocity

Short‑lived credentials reduce incident risk and the cost of secrets management. With trusted publishing, you’ll spend less time chasing leaked tokens and more time shipping. Bonus: the November GitHub Actions changes upped limits for reusable workflows and made M2 macOS runners GA, which can shave minutes off iOS and Electron build times in CI. Use the migration as a forcing function to standardize workflows and reclaim compute. (github.blog)

What to do next

• Move one package to OIDC trusted publishing today, then turn on “disallow tokens + 2FA” for that package. (docs.npmjs.com)
• Schedule a 60‑minute working session to inventory every token and revoke classics you don’t need before Nov 19. (github.blog)
• For complex orgs, implement a reusable release workflow and use the increased nesting/call limits to roll it out quickly. (github.blog)
• Train maintainers on 2‑hour session tokens for local publishing and enroll passkeys now. (github.blog)

Further help and deep dives

If you want a walkthrough tailored to your stack, our team can help harden your pipeline and execute the cutover. Start with our concise CI/CD cutover guide for npm token migration, then use our last‑mile playbook to pressure‑test edge cases. If you’re merging this work with broader CI changes, our analysis of November GitHub Actions updates can save you a few cycles. And if your pipelines are already red, jump to the triage steps in Fix CI before Nov 19.

Bottom line

Classic tokens are ending, and that’s good news for the ecosystem. Spend this week moving the last mile: OIDC first, tightly scoped granular tokens only where necessary, 2FA everywhere people type, and clear ownership at the package level. Do that, and November 19 will be just another release day—quiet, on-time, and incident-free.