npm Token Migration: Fix CI Before Nov 19

The clock’s ticking on npm token migration. As of November 5, 2025, you can’t create classic npm tokens anymore, and on November 19 those legacy tokens get revoked. If your pipelines still depend on them, your publish job will fail the minute the switch flips. Here’s the practical plan to keep releases flowing—and to come out of this with a stronger, lower‑maintenance security posture. (github.blog)

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

On November 5, GitHub disabled creation of classic npm tokens across the website, CLI, and API. Existing classic tokens keep working only until November 19, 2025, when they’ll be permanently revoked. The npm CLI’s npm token create no longer generates classic tokens. (github.blog)

Granular access tokens tightened too: new write‑scoped tokens now enforce 2FA by default, and all existing granular write tokens are capped at a 90‑day maximum lifetime. GitHub also introduced an optional “Bypass 2FA” setting for CI/CD use. (github.blog)

GitHub says the next phase on November 19 replaces long‑lived local publishing tokens with 2‑hour session tokens—good for safety, but it means you’ll need a sane rotation or an alternative like OIDC. (github.blog)

Separate but related: in October, GitHub outlined a broader plan—default seven‑day lifetimes for new granular tokens (90‑day max), freezing new TOTP 2FA setups for npm access, and a push toward “Established Trust with OIDC,” an evolution of Trusted Publishing. The company adjusted timelines based on community feedback but kept the security direction. (github.com)

Why the urgency? Recent supply‑chain incidents, including the Shai‑Hulud worm in September that led to hundreds of malicious packages being pulled, pushed registries toward shorter‑lived credentials, stronger MFA, and automated, provenance‑friendly publishing. (techradar.com)

npm token migration: a decision framework that actually works

Don’t treat this as a one‑time scramble. Choose a durable path that reduces secrets toil and limits blast radius. Use this three‑option framework to decide:

Option A: Established Trust with OIDC (preferred)

Use your CI’s identity (OIDC) to request a short‑lived credential at publish time, instead of storing a long‑lived token. It’s the cleanest, least secret‑heavy approach and aligns with GitHub’s stated direction—“Established Trust with OIDC” expanding on Trusted Publishing, with CLI parity and bulk management planned before further breaking changes. If your environment supports OIDC to npm, prioritize this path. (github.com)

Pros: near‑zero secret sprawl, automatic rotation, provenance‑friendly. Cons: initial setup and policy plumbing; some orgs aren’t fully OIDC‑ready yet.

Option B: Granular access tokens with CI “Bypass 2FA”

If OIDC isn’t possible this week, generate a granular token scoped to just what your publish needs (write for one package or org scope), enable “Bypass 2FA” for CI, and rotate on a schedule that respects the 90‑day cap (many teams choose monthly). Be ready for shorter defaults for new tokens (seven days) if your process relies on frequent creation. (github.blog)

Pros: quick retrofit, works on any CI. Cons: still a secret; rotation and scoping discipline required; human error risk remains.

Option C: Manual local publishing (two‑hour sessions)

After November 19, local/manual publishing relies on two‑hour session tokens and 2FA, which dramatically reduces the viability of “ship from a laptop” rituals. Use this only for emergencies or when you need a human in the loop for compliance; otherwise, automate with OIDC or granular tokens in CI. (github.blog)

Let’s get practical: retrofit your pipelines in a day

Most failures on November 19 will come from forgotten secrets in old workflows. The fastest way to de‑risk is to audit, replace, and test in a safe branch. Here’s a pragmatic sequence that’s worked for teams we coach:

1. Inventory your npm credentials. Search your repos and secret stores for NPM_TOKEN, NPM_AUTH_TOKEN, _authToken, and //registry.npmjs.org/:_authToken. Include org secrets, environment secrets, repo secrets, and self‑hosted runner vaults. If you find a classic token, put it on a kill list.
2. Pick Option A or B. If your platform supports OIDC to npm, start there; otherwise, create a granular token scoped to your package/org with “Bypass 2FA” for CI. Expect 90‑day max lifetime and plan a rotation calendar. (github.blog)
3. Update your publish job. In GitHub Actions, use actions/setup-node with registry-url and set the token via NODE_AUTH_TOKEN. Keep GITHUB_TOKEN for GitHub API calls; it’s unaffected by the npm changes. (github.blog)
4. Dry‑run publish in a staging tag. Use a pre‑release tag (e.g., next) or a private package to validate auth, provenance, and dist‑tag behavior without touching production consumers.
5. Rotate and revoke. Once the new path works, revoke the old token and document the rotation owner, cadence, and expiry alerts (calendar reminders, bot PRs, or your secret manager’s TTL events).

GitHub Actions: a concrete before/after

If you’re migrating from classic tokens to granular tokens, the diff is simple. Keep context in mind: GITHUB_TOKEN (for GitHub) is not a replacement for your npm token (for npm). Per GitHub’s changelog, GitHub tokens are unaffected by these npm changes—only npm registry tokens are in scope. (github.blog)

Before (classic token in repo secret NPM_TOKEN):

- risks: long‑lived credential, broad scope, potential secret sprawl.

After (granular token with Bypass 2FA):

- benefits: strict package scope, enforced 2FA policy for interactive use, and an explicit CI bypass for noninteractive runs; still rotate within the 90‑day cap. (github.blog)

Future‑proof (OIDC “Established Trust”):

- benefits: no stored token, short‑lived auth at publish, and alignment with GitHub’s roadmap to add CLI parity and bulk management before further breaking changes. (github.com)

Security tradeoffs you should actually weigh

Scope is king. With granular tokens, scope to the smallest surface—ideally a single package or an org scope limited to publish and dist‑tag. This trims the blast radius if a secret leaks.

Rotation is a control, not a chore. Set rotation under the 90‑day max. Monthly is easy to remember and keeps exposure short. For teams that can automate, generate tokens per release and let your pipeline inject them—especially if you’re not on OIDC yet. (github.blog)

2FA Bypass is for machines only. The name says it. Use the bypass flag strictly for CI contexts; human publishers should meet strong 2FA. (github.blog)

TOTP vs passkeys. GitHub froze new TOTP 2FA configurations for npm access as part of the hardening push; passkeys (WebAuthn) are resistant to common phishing and relay attacks that have bypassed weaker MFA. If your org still leans on TOTP for dev accounts, start your passkey rollout now. (github.com)

Boardroom view: why this isn’t just “DevOps work”

If you own a product P&L, the cost of a blocked release is visible—missed fixes, delayed features, SLA penalties. The bigger, less visible risk is supply‑chain compromise. The Shai‑Hulud incident shows how a single maintainer’s stolen credential can poison the well for thousands downstream. Short‑lived credentials and provenance‑first pipelines are the new baseline for software suppliers. (techradar.com)

We’ve helped clients make similar hardening moves when registries, CDNs, or clouds changed defaults. The winning pattern is always the same: small, reversible steps with guardrails, and a brutally honest inventory of where secrets live. If you want a deeper playbook, our 10‑day CI/CD survival plan breaks migration into daily chunks, and our shorter deadline primer highlights the minimum changes to ship safely.

People also ask

Do I have to rotate granular tokens every seven days?

No. The roadmap sets seven days as a default for new granular tokens with a maximum lifetime of 90 days. You can choose a longer expiry up to that cap; many teams standardize on 30 days. (github.com)

Are GitHub tokens affected by these changes?

No. GitHub explicitly says personal access tokens (classic or fine‑grained), GITHUB_TOKEN, and Actions secrets as features aren’t changed. What is affected are npm registry tokens that you may have stored in those secrets. Update those secrets with your new npm path. (github.blog)

What’s the fastest safe path if I can’t do OIDC this week?

Generate a granular token with the narrowest scope possible, enable CI “Bypass 2FA,” update your workflows, and schedule rotation under the 90‑day max. Put OIDC on your backlog for Q4/Q1—it reduces long‑term maintenance and aligns with GitHub’s direction. (github.blog)

Why did GitHub tighten npm now?

Recent npm attacks and maintainer‑targeted phishing highlighted the weakness of long‑lived secrets. GitHub’s staged rollout (Nov 5 changes; Nov 19 revocation) reduces credential shelf life, enforces stronger MFA for humans, and nudges teams to automated, short‑lived credentials. (github.blog)

Implementation notes for non‑Actions CI

Jenkins. Store the granular token in a credentials provider, inject it into NODE_AUTH_TOKEN, and keep your npmrc scoped to the registry URL for writes only. Use folders or multibranch job credentials to narrow access. Rotate with a shared library that checks expiry.

GitLab CI. Use masked, protected variables for the token. Set //registry.npmjs.org/:_authToken=${NPM_TOKEN} at publish time, not committed. If your GitLab runners support OIDC with npm in your environment, begin planning that migration; if not, keep token scopes tight and lifetimes short.

Azure Pipelines. Store secrets in variable groups linked to environments; restrict who can use them via approvals. If you run private feeds too, double‑check you’re not mixing credentials across registries.

In every case, the principle is the same: minimize where the token exists, minimize what it can do, and minimize how long it lives.

A short checklist you can run today

Use this as a stand‑up agenda for the next two days:

• List every pipeline that publishes to npm; flag those using classic tokens.
• Decide OIDC (preferred) or granular token fallback for each pipeline. (github.com)
• Create granular tokens with the narrowest scope; enable CI “Bypass 2FA” where needed. Record expiry dates. (github.blog)
• Update workflows to use NODE_AUTH_TOKEN and the correct registry URL; test with a pre‑release tag.
• Revoke old tokens; set rotation alerts; document the owner for every secret.

What to do next (this week)

- Ship the minimal fix: granular tokens or OIDC for all publishes.

- Schedule a 30‑minute tabletop: “What if our publish fails on Nov 19 at 9 a.m.?” Decide rollback or manual contingency.

- Start your passkey rollout for maintainers; freeze ad‑hoc laptop publishes in favor of CI pipelines. (github.com)

- Add provenance to your packages and review who can cut releases. If you want help pressure‑testing this, our team can jump in—see what we do on our services page, browse relevant case work in our portfolio, or reach out via contacts.

Zooming out: after Nov 19

Expect continued hardening: shorter‑lived credentials by default, stronger MFA for humans, and better first‑class tooling for OIDC‑based publishing. GitHub has already signaled CLI parity for granular tokens, expanded OIDC support (including GitHub Enterprise Server and self‑hosted runners), and namespace‑level settings before any additional breaking changes advance. Translate that into your roadmap now so this month’s scramble becomes next quarter’s advantage. (github.com)

For additional context on platform changes and rollout planning, our recent pieces—like the GitHub Agent HQ rollout playbook—show how we approach cross‑team changes without grinding delivery to a halt. The headline: move early, iterate safely, and leave room for vendors to adjust timelines.