npm Token Changes: What Broke and How to Fix It

Release pipelines across the JavaScript world have been tripping since the npm token changes went live around November 19, 2025. If your CI suddenly can’t publish, here’s the good news: you can fix this in under an afternoon. Below is the dated, practical breakdown—what changed on November 5 and November 19, why it happened, and step-by-step paths to get your CI/CD and local publishing healthy again.

The short version: dates, scope, and the exact npm token changes

Let’s anchor this to the calendar, because that’s how you plan work:

• November 5, 2025: creating new classic npm tokens was disabled across website, CLI, and API. New write-capable granular tokens default to enforcing 2FA. Granular write tokens now have capped lifetimes—90 days maximum. A Bypass 2FA option exists for CI, but it’s off by default.
• November 19, 2025: remaining classic tokens were revoked, and long-lived local publish sessions shifted to short, session-based authentication (think hours, not months). If your pipeline still relied on a classic token, your publish step started returning 401/403 or “you must enable 2FA to publish.”
• 2FA posture: new TOTP setups for npm are blocked going forward; the long-term direction is WebAuthn/passkeys. For automation, the north star is Trusted Publishing (OIDC), which eliminates long-lived publish tokens from your CI entirely.

If you remember just one thing, make it this: classic tokens are gone; granular tokens expire quickly and prefer 2FA; Trusted Publishing is the easiest path to stability and provenance.

Why this happened: the Shai‑Hulud reality check

In mid-September, a self-propagating malware campaign nicknamed “Shai‑Hulud” hammered the npm ecosystem. It stole maintainer credentials, harvested cloud keys, and even dropped GitHub Actions workflows into repos to keep exfiltrating secrets. Hundreds of packages were impacted, including popular namespaces. The takeaway wasn’t theoretical: long-lived secrets in CI are brittle, and classic, all-powerful tokens multiply blast radius when something leaks.

Registries had to make credential theft less useful. Shorter lifetimes, enforced 2FA, and token scope restrictions reduce the window an attacker can abuse. Trusted Publishing shifts identity from static secrets to workload identity via OIDC, so CI jobs mint ephemeral credentials on the fly and attach publish provenance automatically.

Fix your CI fast: three migration paths that work

Pick one based on your environment. If you can, start with option 1—it’s the cleanest and most future-proof.

Option 1 — Move to Trusted Publishing (OIDC)

This is the recommended route for public and private packages when your CI provider supports OIDC (GitHub Actions and GitLab.com shared runners do). No long-lived npm token is stored; your workflow exchanges a short-lived identity token for publish rights on demand. You also gain provenance on public packages, which many orgs will start requiring.

Steps on GitHub Actions (typical setup):

• Upgrade to a recent npm CLI on your runner (11.x+). Ensure Node runtime is recent enough to avoid older CLI quirks.
• In your workflow, set permissions to include id-token: write and contents: read.
• In your package’s npm settings, add a Trusted Publisher: point it at the repo and workflow that will publish.
• Remove NPM_TOKEN secrets from the workflow. Replace your publish step with the new invocation (npm publish under OIDC picks up the federated identity automatically if configured).
• Dry-run in a branch with --dry-run or publish to a canary tag.

Common gotchas:

• Monorepos: you may need separate Trusted Publisher entries per package. Use matrix jobs or a single workflow with multiple publish steps, but make each package’s settings aware of that workflow.
• Private feeds: confirm your org scope permissions and whether provenance is required or optional for your use case.
• Self-hosted runners: ensure they support OIDC federation; if not, either switch to hosted runners for publish jobs or use option 2 temporarily.

Option 2 — Use granular access tokens with CI Bypass 2FA (temporary bridge)

If your provider doesn’t support OIDC or you need more time, generate a granular token scoped for publish, enable the CI bypass for 2FA, and rotate it on a schedule.

Steps:

• Create a granular token in npm settings. Limit scope to the specific package or org. Grant only the permissions you need (publish, dist-tag management). Set the shortest lifetime you can operate with comfortably. Remember: 90 days is the max; many teams choose 7–30.
• Store it as a CI secret. Rename the secret to make rotation easier, e.g., NPM_TOKEN_ACTIVE and NPM_TOKEN_NEXT, so you can cut over without code changes.
• Update your workflow to use the new secret and to fail fast with a helpful message if auth is missing.
• Schedule rotation. Put a calendar invite and an automated check in CI that warns when the token has less than, say, seven days left.

Tradeoffs: you’re still babysitting a secret, which is why this is a bridge, not the destination.

Option 3 — Private registries and self-hosted infrastructure

If you mirror npm or use an internal package registry, update your upstream credentials and ensure your mirror isn’t caching compromised versions. For publish flows that remain internal, consider OIDC inside your platform (e.g., GitHub Enterprise Server or GitLab with OIDC to your registry) or short-lived, scoped tokens managed by a vault with just-in-time issuance.

People also ask: Do I need 2FA to publish locally now?

Yes—if you’re publishing manually from your laptop, expect the CLI to enforce 2FA and to use short, session-based tokens. Set up WebAuthn/passkeys. It’s faster than typing an OTP every time, and it’s phishing-resistant. If you’re regularly doing local releases, ask the harder question: should this be automated behind OIDC so humans aren’t handling production credentials at all?

Monorepos, Changesets, Nx, Lerna: what changes?

Monorepos typically have a single publish job that iterates through packages. With Trusted Publishing, that’s fine—configure each package to trust the same workflow or split workflows by package group. With granular tokens, life gets trickier: either grant the token org-wide publish privileges (bigger blast radius) or rotate separate tokens and select them per package (operationally heavier). Where possible, move monorepos straight to OIDC.

Changesets and release PRs continue to work. Ensure the final publish step runs in the trusted workflow. If you previously used changesets/action with a stored NPM_TOKEN, remove the secret and adopt OIDC. For Nx and Lerna, nothing architectural changes—just how you authenticate the publish command.

A 30-minute audit checklist for npm publishers

Use this to find and fix the obvious breakpoints fast:

• Search your org for secrets named NPM_TOKEN or anything matching *NPM*TOKEN*. Remove classic tokens immediately; replace with OIDC or granular tokens.
• Check self-hosted runners and old build agents for cached ~/.npmrc files with tokens. Wipe or rotate.
• Review package.json scripts for preinstall/postinstall hooks that might assume long-lived auth or fetch from private scopes.
• Pin package manager versions in CI so you don’t inherit breaking CLI auth changes mid-run.
• Enable dependency and secret scanning on repos that publish packages. Turn on alert forwarding to Slack/Teams so someone actually sees it.
• If you mirror npm, clear any cached compromised versions and verify upstream authentication health.

Common failure modes after Nov 19 and how to spot them

Patterns we’re seeing in the wild:

• 401/403 on npm publish with a vague “authentication required” message. This usually means you’re still using a revoked classic token or a granular token that expired.
• “You must enable 2FA to publish” errors when your granular token lacks the CI 2FA bypass or the account hasn’t configured WebAuthn.
• Can’t publish from a monorepo despite OIDC being configured. Often it’s because only one package was set to trust the workflow; the others weren’t.
• Private package installs failing in CI. Check whether your registry URL and auth lines in .npmrc were baked into the pipeline image with a classic token; rebuild the image with new auth or move to OIDC-supported installs.

Beyond unblocking: provenance, policy, and proof

Take the opportunity to mature your release posture:

• Turn on provenance for public packages via Trusted Publishing. Consumers increasingly look for attestations.
• Add a policy that forbids long-lived publish tokens in repos. Enforce via organization secret scanning and periodic audits.
• Create a runbook: how to rotate tokens, where they’re stored (if any), how to test a canary publish, and how to roll back a bad tag.

If you’re modernizing broader CI security, our piece on getting GitHub Actions pull_request_target right is worth a read. It walks through a high-impact misconfiguration that often coexists with weak token hygiene. See this GitHub Actions hardening guide for specifics.

What about businesses that don’t publish to npm but rely on it?

You still feel the blast radius. When maintainers can’t publish, your updates stall. When registries purge compromised versions, your builds can fail. Here’s what helps:

• Cache with intent: use an internal proxy that honors upstream yanks and signatures, and alerts when a dependency was pulled for security reasons.
• Budget time for “security-driven releases.” When an upstream dependency ships a fix with provenance, push it through quickly.
• In vendor reviews, start asking suppliers: do you use OIDC Trusted Publishing, and do your public packages include provenance?

Let’s get practical: a two-hour cutover plan

Here’s a realistic workflow a staff engineer can run this afternoon:

1. Identify the publishing repos. Grep for npm publish in workflows; list packages with release automation.
2. Pick one candidate package and enable Trusted Publishing. Add id-token: write to the release workflow; add the repo/workflow as a Trusted Publisher in npm; remove the secret token; run a dry-run publish.
3. If OIDC isn’t supported in your CI, issue a minimal-scope granular token with a 7–30 day lifetime and Bypass 2FA enabled for CI. Store it as a new secret name to simplify rotation.
4. For monorepos, add each package to the same trusted workflow or split by package group. Do one successful publish before scaling out.
5. Document the change and add a rotation reminder if you used a granular token. Then schedule migrating any remaining pipelines to OIDC.

People also ask: Is Trusted Publishing mandatory?

No—but it’s becoming the sane default. Granular tokens with CI 2FA bypass work, but they’re more maintenance and more risk. Trusted Publishing removes long-lived secrets, adds provenance, and tends to be simpler once it’s set up.

What to do next (developers)

• Migrate one publisher to Trusted Publishing today and write the runbook while it’s fresh.
• Delete any lingering classic tokens in org secrets, repo secrets, and runner images.
• Add a CI guard step that fails the build if a token is within seven days of expiry (until you’re fully on OIDC).
• Turn on secret scanning and dependency alerts across your publishing repos.

What to do next (engineering leaders)

• Set an org policy: no long-lived publish tokens in code or secrets; OIDC-only for new pipelines.
• Ask for a weekly status until all publishers are on Trusted Publishing. Track the number of packages with provenance enabled.
• Fund one day to harden Actions settings per repo—permissions, environments, required reviewers for release workflows.
• Schedule a postmortem on last week’s failures and capture the fixes as reusable templates.

If you want a deeper walkthrough, our earlier explainer on the deadline covers the policy milestones and gotchas you’ll hit in CI. Read npm token changes: fix your CI today. If your team needs help executing the cutover and hardening your pipeline, see our services for CI/CD modernization or get in touch.

A note on stability and signal

Teams asked whether the cutoff would slip. The answer doesn’t change your work: classic tokens are effectively gone and session-based local publishing is here. If something in your environment still “works,” treat it as borrowed time. Move now and you won’t be back here during year-end freezes.

Final checklist: don’t leave the room until these are true

• Every publishing workflow either uses Trusted Publishing or a short-lived granular token with a rotation plan.
• No classic tokens remain in org/repo secrets, runner images, or developers’ ~/.npmrc.
• At least one successful canary publish happened this week under the new auth model.
• Secret scanning, dependency alerts, and branch protection are on for publishing repos.
• Your runbook lists exactly how to rotate, test, and roll back.

You can’t control the next worm or phishing campaign, but you can control how much damage a leaked credential does. With OIDC and short-lived tokens, the answer becomes: not much—and not for long.

Want an expert eye on your pipeline? We’ve helped teams ship on new platform baselines before—whether it was framework upgrades or registry policy changes. Browse our recent projects or read the rest of our engineering guidance on the blog.