Let’s be blunt: npm token migration isn’t optional anymore. With classic npm tokens permanently revoked on November 19, any pipeline still using one will fail its publish step, and local publishing will shift to short‑lived session tokens. On November 5, npm also flipped on stricter defaults for new granular tokens: enforced 2FA for write scopes, a new Bypass 2FA option for CI/CD, and a hard 90‑day cap on write tokens. If you maintain packages or run release automation, this week is your last clean window to cut over with confidence.
I’ve helped teams move hundreds of repos off fragile secrets. The pattern that works is boring on purpose: inventory, replace, rehearse, and lock down. Here’s the thing—if you follow a lightweight runbook, you won’t need a release freeze. You just need discipline, ownership, and a testable rollback.
What changed on Nov 5—and what breaks on Nov 19
On November 5, npm made four security changes that affect how you publish:
• You can’t create classic npm tokens anymore via website, CLI, or API.
• New granular tokens with write permissions enforce 2FA by default. There’s a Bypass 2FA checkbox for non‑interactive CI/CD.
• All existing granular write tokens now have a maximum lifetime of 90 days. If a token was set to expire after February 3, 2026, it’s automatically adjusted to that date.
• For now, you must create granular tokens on the website; full CLI parity is coming.
On November 19, the hammer drops: all classic tokens are revoked, and long‑lived local publishing tokens are replaced with two‑hour session tokens. Translation: a cutover that only touches CI isn’t enough; you must also prepare maintainers who publish from laptops or release machines. If you don’t address both paths, you’ll fix CI but still block hotfixes.
Primary question: what’s the right path for my team?
There are two sane paths. If your registry flows and provider support it, move to OIDC‑based trusted publishing so your CI presents a short‑lived identity instead of a static secret. Otherwise, use npm granular tokens with the smallest permissions, Bypass 2FA enabled only for publish jobs, IP or CIDR restrictions if feasible, and rotation wired into CI.
Which is better? Trusted publishing is the end state. It kills long‑lived secrets outright and shrinks the blast radius on credential leaks. Granular tokens are the pragmatic stepping stone when you don’t have time to finalize OIDC trust this week.
npm token migration checklist you can run in 48 hours
Working in an enterprise? Do this in a branch org‑wide with one cross‑functional chat room and a named incident commander. Small team? Assign a single owner and a reviewer. Either way, move in waves.
Wave 0: Establish guardrails
• Enable 2FA on publisher accounts and set a backup key method. Don’t rely on SMS.
• Create an emergency maintainer group with passkeys registered—use it only if a rotation goes wrong.
• Decide your path: trusted publishing now, or granular token as a bridge.
Wave 1: Inventory and classify
• List every repo that publishes to npm, including monorepo packages.
• Identify the current credential per pipeline: classic token, granular token, or OIDC.
• Flag local/manual publishing flows and who runs them. These often hide in release notes or internal docs.
Wave 2: Create the replacement credentials
• If using trusted publishing, complete the OIDC trust setup and restrict which repos can publish which packages.
• If using granular tokens, generate a write token per CI context with Bypass 2FA enabled. Set the shortest workable expiration (≤90 days) and narrow scopes. Consider IP allowlists for runners with static egress.
Wave 3: Wire CI and add preflight checks
• Replace secrets in your CI system, but keep the old secret until the rehearsal passes.
• Add a preflight job to check token expiration dates at build time.
• Add a dry‑run publish in non‑prod to verify the new path actually works.
Wave 4: Rehearse a full release
• Cut a canary release on a low‑risk package and confirm registry metadata, dist‑tags, provenance, and semver rules.
• Validate that SBOMs or provenance attestations are still generated if you rely on them.
Wave 5: Remove the old path
• Revoke any remaining classic tokens and delete secrets in your CI store.
• Lock down who can create new granular tokens and who can approve trust links.
• Add a policy check that blocks the use of classic tokens in workflows.
CI/CD cutover patterns that won’t bite you later
Here are the patterns we’ve used for smooth cutovers across different runner environments.
GitHub Actions
Trusted publishing with OIDC is the preferred path. Map each repo or package to the publisher identity and require environment protection rules on release jobs. If you need granular tokens this week, store the token as an org secret scoped to a single environment, enable Bypass 2FA only for the publish job, and rotate on a 60‑day cadence with an automatic reminder.
Self‑hosted runners or other CI
Ensure fixed egress IPs so you can use CIDR‑restricted tokens. Put the token in a separate secret store, not in a shared env file. Split your pipeline so test and build jobs do not receive publish credentials; gate the publish job behind a manual approval or a semantic release condition.
Security nuance: 2FA defaults, lifetime caps, and audit traps
Enforced 2FA on new write tokens is a net positive, but it’s easy to shoot yourself in the foot. If you leave Bypass 2FA unchecked on a CI token, non‑interactive publishes will fail. If you set expirations to the default maximum and forget to rotate, you’ll wake up to a 2 a.m. incident when releases quietly time out at day 91. Add a simple health check in your pipeline that validates token age and remaining lifetime; fail fast with an actionable error.
Another trap is assuming the CLI can do everything today. As of now, creating granular tokens is a website flow, with CLI parity promised. Build your runbooks accordingly; don’t automate something that still needs a browser step.
People also ask: quick answers for busy teams
Do I need to enable 2FA on my npm account if CI uses Bypass 2FA?
Yes. Account‑level 2FA is still table stakes for maintainers, and it protects local publishing. Bypass 2FA applies to a specific CI token, not to your account. Keep them separate in your head: account hardening for humans, narrowly‑scoped tokens for machines.
Can I still publish locally after November 19?
Yes, but your local flow changes. Long‑lived tokens are going away; local/manual publishing switches to short‑lived session tokens with additional checks. Plan for your maintainers to sign in with strong 2FA, and document the new steps so emergency patches aren’t blocked by confusion.
Will npm token create still work for new classic tokens?
No. The CLI no longer generates classic tokens. Create granular tokens on the website for now, and then store them where your CI can access them securely. Keep an eye on CLI parity updates if you want to script lifecycle tasks later.
Should I jump to trusted publishing right now or stage it?
If your team can finish OIDC trust this week, do it; it eliminates an entire class of secret management toil. If not, use granular tokens as a bridge and time‑box the bridge. Put a date on the calendar to complete the OIDC move, and treat that date as seriously as a compliance deadline.
A weekend war‑room plan that actually works
Here’s a playbook I’ve used with distributed teams to migrate 1,000+ repositories without halting releases. Run it Saturday morning through Sunday afternoon the weekend before the deadline.
• Kickoff (30 minutes): Confirm ownership, blast radius, and success criteria. Page a secondary on‑call who can approve emergency changes.
• Phase A (2 hours): Replace secrets and run dry runs on a representative subset—one monorepo, one single‑package repo, one private package. Fix issues and codify the patch as a reusable PR template.
• Phase B (3–4 hours): Roll the PR template across the portfolio with a short‑lived feature flag so you can flip back if needed. Watch pipeline dashboards for anomalies like 2FA prompts during publish, missing dist‑tags, or registry rate limits.
• Phase C (2 hours): Ship canary releases from five packages with different build matrices. Verify provenance, scanning, and the correct tag promotion.
• Phase D (1 hour): Revoke displaced tokens and remove secrets. Archive a runbook entry with token IDs revoked and repos verified. Close the war room only after a final status check.
Policy and governance: make the new posture stick
Temporary fixes become permanent unless you lock them down. Add organization policies that block classic tokens in workflows and prevent secrets named in a denylist from being created. Require code owners and environment protection for release workflows. At the people level, document the new local publish path and run a five‑minute tabletop with your maintainers so the first emergency patch doesn’t become a live training session.
Where this is heading next
Two trends are clear. First, static, long‑lived credentials are being squeezed out of the software supply chain in favor of short‑lived identity and signed provenance. Second, publisher accounts are moving toward passkeys and WebAuthn as the default path for human authentication. Expect more of your tooling to prefer OIDC integrations and more registries to build “established trust” flows that make onboarding multiple repos less painful.
Let’s get practical: a one‑page cutover template
Steal this structure and customize per team:
• Scope: list all publishing repos and package names.
• Owner: name the person accountable per repo.
• Path: OIDC trusted publishing or granular token. If token, list scopes, expiration date, and whether Bypass 2FA is enabled.
• Secrets location: link to CI secret entry and environment name.
• Rehearsal: date and tag of the canary release validated.
• Revocation: token ID removed and date.
• Post‑checks: provenance verified, dist‑tags correct, docs updated.
What to do next
• Today: inventory publishing repos and decide your path. If you can finish OIDC trust this week, choose it.
• Within 48 hours: replace secrets in CI, run dry runs, and ship canary releases. Document the new local publish flow for maintainers.
• Before November 19: revoke every classic token, remove leftover secrets, and turn on policy checks that keep classic tokens from creeping back in.
• The week after: schedule OIDC adoption if you staged with granular tokens. Add rotation reminders for any remaining tokens at 60 days.
Want a deeper dive into the mechanics and gotchas? We’ve published detailed guides on cutting over CI safely and hardening governance around release workflows. Start with our practical write‑ups on CI/CD cutover for npm token migration, a frank assessment of how to fix CI before the Nov 19 deadline, and this November’s broader look at GitHub Actions changes, M2 runners, and policy updates. If you’d rather have a partner run the weekend war room with you, our team can help—see what we do for engineering teams and get in touch.
