npm Token Changes Move to Dec 9: Fix Your CI Now

The primary search intent here is practical: teams need to understand the npm token changes and how to migrate safely. GitHub shifted the final cut‑off for classic tokens to December 9, 2025, after tightening rules on November 5. If your CI still relies on long‑lived credentials, you’ve got days—not months—to fix it. This article breaks down the timeline, the risks, and the fastest, least painful path to adopt granular access tokens and Trusted Publishing.

What exactly changed with npm token changes?

Two moments matter. On November 5, 2025, GitHub disabled creation of classic npm tokens and tightened granular token rules. The big switch now lands on December 9, 2025: remaining classic tokens will be revoked, and local login flows lean on short‑lived session tokens. New write‑scoped tokens enforce stronger authentication defaults. Practically, that means unattended jobs using stale secrets will start failing.

Let’s spell it out so there’s no ambiguity:

• Classic tokens: creation blocked since November 5; permanent revocation on December 9.
• Granular access tokens: write scopes require stronger auth; maximum lifetime capped—plan around periodic rotation.
• Local publishing: expect short‑lived session behavior; don’t glue your release train to manual prompts.

If your workflow assumes a token that lasts forever, it’s time to move.

Why the shift—and why now?

Here’s the thing: the JavaScript supply chain has been stress‑tested this fall. Two waves framed the urgency. First, a worm‑style campaign dubbed “Shai‑Hulud” spread through maintainer accounts and CI workflows by scooping up secrets and re‑publishing compromised packages. Then a flood of fake packages themed “IndonesianFoods” hammered npm with tens of thousands of uploads. Even when payloads aren’t immediately destructive, scale alone creates risk and burns reviewer time.

Credential hygiene is the shortest path to reducing blast radius. Short‑lived tokens and phishing‑resistant 2FA blunt whole classes of compromise. OIDC‑based publishing (what npm calls Trusted Publishing and is evolving toward “Established Trust”) further reduces risk because there’s no long‑lived secret to steal in the first place.

What breaks on December 9 if I do nothing?

Three realistic scenarios we see on real teams:

1. Release jobs start failing in CI. A nightly publish to your private registry or a scheduled canary release will error out with auth failures. If your release orchestration assumes success, downstream promotions might silently skip or produce partial artifacts.
2. Emergency patch delays. The day you need to cut a CVE fix, your publish step prompts for 2FA or refuses your expired token. Suddenly “five minutes to ship” becomes a scramble for a maintainer who has the right hardware key.
3. Shadow automation breaks. Internal tools and build caches that fetch from npm with embedded classic tokens will quietly start returning 401s. Engineers will think npm is down. It’s not; your credentials are.

None of these are theoretical. We’ve watched them play out during previous npm and GitHub auth migrations. Plan for it now.

The 60‑minute migration plan (works for most repos)

You don’t need to redesign your pipeline in a day. Start with a focused hour to eliminate the riskiest failure modes.

Step 1: Inventory where tokens live (10 minutes)

Search your org for NPM_TOKEN, //registry.npmjs.org/, and any _authToken references. Check GitHub Actions secrets, GitLab variables, Jenkins credential stores, Kubernetes secrets, and any build system config files. If you keep a monorepo, verify each package’s publish script.

Step 2: Switch CI to granular tokens or OIDC (20 minutes)

Decide which path fits your maturity:

• Granular access token (fastest): Create a write‑scoped token with a short lifetime and, if your pipeline is non‑interactive, enable the setting that bypasses interactive 2FA for CI. Store it in your CI’s secret manager as NPM_TOKEN. Update your publish step to use it.
• Trusted Publishing (best long‑term): Configure OIDC between your CI provider and npm. In GitHub Actions, grant id-token: write, use npm CLI with provenance support, and designate the repo/workflow as a trusted publisher in your package settings. The workflow exchanges a time‑bound identity token for publish rights—no long‑lived secret.

If you’re juggling multiple packages, adopt OIDC once, reuse the pattern, and drop token rotation entirely.

Step 3: Lock down who can publish (10 minutes)

Set your package policy to require 2FA for publish and settings changes, or require 2FA and disallow tokens if you only publish manually. Keep the team small; fewer maintainers means fewer keys to protect.

Step 4: Test on a dry‑run and cut a patch release (20 minutes)

Run npm publish --dry-run in CI. If you’re using provenance, verify the build provenance is attached in the registry UI. Then ship a harmless patch to validate the pipeline under real conditions.

How to adopt Trusted Publishing in practice

Let’s get practical. The core idea is simple: tie publish rights to the identity of your CI job. In a GitHub Actions setup, grant your workflow the ability to request an OIDC token, and configure your package to trust that repo and workflow. The npm registry verifies the signed identity token and issues a short‑lived publish grant. When the job ends, the credential disappears with it.

Benefits you’ll feel immediately:

• No token to rotate or leak. There’s nothing to stash in a repo or a shared vault.
• Fine‑grained trust. You can trust a specific repo and workflow, not your whole org.
• Provable builds. With provenance enabled, consumers can see where and how the package was built.

Two gotchas we see often: teams forget to update the npm CLI to a version that understands provenance, and they forget to grant id-token: write in the workflow permissions. Fix those, and most setups click into place.

People also ask: common questions about npm token changes

Do I need 2FA to publish?

For manual publishing, yes—expect 2FA prompts and plan on WebAuthn/passkeys for speed and phishing resistance. For CI, either use granular tokens with the appropriate CI setting, or switch to Trusted Publishing and skip long‑lived tokens entirely.

What’s the difference between classic and granular tokens?

Classic tokens were long‑lived, all‑or‑nothing. Granular tokens scope permissions and now have capped lifetimes. They’re safer, but still secrets you can leak. Trusted Publishing sidesteps the problem by removing the standing secret.

Will 2‑hour sessions break local workflows?

If you rarely publish, you’ll barely notice. If you ship many times a day from laptops, you’ll see re‑auth prompts. That’s a nudge toward either CI‑first publishing or stronger local auth like security keys for speed.

Is Trusted Publishing slower?

In practice, no. The OIDC exchange is quick, and you save time by not babysitting tokens. Most teams report a net gain in reliability.

A pragmatic security baseline for JavaScript orgs

Zooming out, tight credentials are table stakes but not the whole story. Pair the npm token changes with predictable controls you can audit:

• Single path to production. Only CI can publish, not developer laptops. Lock permissions accordingly.
• Short‑lived identities across providers. Rotate cloud creds; prefer workload identity over static keys.
• Dependency health gates. Quarantine unknown publishers; require a minimum maintainer history or provenance for critical packages.
• Package ownership hygiene. Remove dormant maintainers. Add a break‑glass owner with hardware‑protected 2FA.

This isn’t theoretical governance. It’s the handful of guardrails that keep incidents from becoming outages.

A fast reality check for your CI

Before you assume you’re safe, try this:

• Delete NPM_TOKEN from your CI secrets in a non‑prod project and run the pipeline. If the job explodes in authentication errors, you’re still bound to legacy flows.
• Enable provenance on a staging package and publish via OIDC. Verify the attestation is visible and the job succeeds without a stored secret.
• List where publish rights live—repos, teams, and orgs. If you can’t name them in minutes, permissions are too broad.

Edge cases and gotchas we’ve hit

There are always sharp edges.

• Monorepos with partial publishes. If your tooling publishes multiple packages from one workflow, ensure the trusted publisher mapping includes each package. Missing one will fail that publish while others succeed—easy to miss in logs.
• Scoped private registries. If you mirror the public registry internally, validate that your proxy honors provenance and doesn’t strip headers. We’ve seen caches mis-handle tokenless flows.
• Self‑hosted runners. Lock down OIDC trust policy to your runner labels and org. Treat runner compromise as package compromise.

What changed on November 5—and why the deadline is now December 9

On November 5, 2025, npm blocked creation of classic tokens and tightened requirements for granular tokens with write scopes. The plan originally pointed to mid‑November for revocation. Based on maintainer feedback, the final cut‑off moved to December 9, 2025 to bundle the break with CLI improvements that make managing granular tokens less painful. You still need to move—there’s just enough time to do it right.

The security backdrop: worms, floods, and policy shifts

Supply‑chain incidents accelerated all year: self‑replicating worms turning maintainer accounts into distribution points; registry floods that swamp scanners; and targeted credential theft that pivots from CI to cloud. Shorter‑lived tokens, 2FA by default, and OIDC publication aren’t silver bullets, but they’re proven friction that materially lowers risk.

If you want a deeper dive into related incidents and playbooks, our earlier posts on what broke with npm tokens and how to fix it and the expr‑eval vulnerability response outline patterns you can reuse across ecosystems.

Checklist: your pre–December 9 readiness review

Run this before the deadline:

• Replace any classic token left in automation with a granular token or OIDC.
• Set package policy to require 2FA for publish and settings changes.
• Constrain publish rights to CI. Remove laptop publishing or mark it as break‑glass only.
• Publish a trivial patch via the new path—prove it works under real conditions.
• Document who holds hardware keys and how to recover if a maintainer is unreachable.

What to do next

For developers:

• Migrate one repo today. Pick your busiest package and move it to OIDC. Don’t aim for perfection; aim for zero long‑lived secrets.
• Rotate any surviving granular tokens and set short expirations. Treat them as temporary scaffolding.
• Enable provenance and review who can change publishing settings.

For engineering managers and founders:

• Add a security SLO: “All publishes run from CI with OIDC by December 6.” Track it in your release board.
• Budget an hour for each critical package to migrate and validate.
• Schedule a live failover test: disable the old secret and watch the pipeline use OIDC successfully.

Need a hand?

If you want expert help hardening your pipelines or standing up OIDC and provenance quickly, our team does this every week. See what we do for engineering teams, browse a few relevant project case studies, and reach out via contact. We’ll help you make the December 9 deadline a non‑event.

The bottom line

The npm token changes aren’t busywork. They’re a sensible response to how modern attacks really move—through secrets, CI, and overly permissive defaults. Use the deadline extension to decouple publishing from people, remove long‑lived credentials, and attach provenance your consumers can trust. Do that, and December 9 will be just another Tuesday.