npm Token Migration: What Will Break on Nov 19

Let’s be blunt: if you’ve postponed the npm token migration, you’ve got a deadline staring you down. On November 19, 2025, classic npm tokens are revoked. New classic tokens were already disabled on November 5, and granular access tokens tightened up: write‑scoped tokens enforce 2FA by default and max out at short lifetimes. The future is short‑lived credentials and OIDC‑based trusted publishing. If you do nothing, your release jobs will fail.

What exactly changes on November 19?

Two things converge. First, all remaining classic npm tokens are revoked. That means any pipeline step—npm publish, npm dist-tag, or internal tooling wrapping those commands—that still injects a classic token will start returning 401/403 errors against the registry. Second, npm’s shift to short-lived and scoped credentials continues: granular access tokens with write permissions are capped at tighter expirations (90-day maximum with defaults often shorter), and 2FA enforcement is on by default. For noninteractive CI, bypass 2FA exists, but it’s intentionally a speed bump you must turn on per token. The direction of travel is clear: tokens should be narrow, short‑lived, and rarely used for publishing in CI at all.

Here’s the alternative that scales: trusted publishing with OIDC. Instead of storing a secret, your CI runner requests a short‑lived, signed token from npm during the publish step. You don’t rotate it. You don’t leak it. You don’t pass it around between orgs. For public packages published from public repos, you also get provenance attached automatically—supply‑chain hygiene with minimal ceremony.

Who’s at risk of breakage?

I’ve audited a dozen orgs in the last month, and the failure patterns rhyme:

• Release pipelines in GitHub Actions that still reference NPM_TOKEN set years ago.
• Monorepos using changesets or custom publish scripts that assume a static token in runner env.
• Self‑hosted runners or Docker images that baked in classic tokens “temporarily” and never rotated.
• Legacy CD systems (Jenkins, TeamCity, Azure DevOps) where publishing lives outside version control and secrets hygiene is informal.

If you recognize any of the above, you need a structured cutover—not a Friday night scramble.

What about GitHub Actions changes this month?

There’s useful news for teams that publish from macOS images or scale heavy workflow reuse. In early November, GitHub increased reusable workflow limits (up to 10 nested calls and up to 50 total calls per run), and M2 macOS runners reached general availability on labels like macos-15-xlarge and macos-latest-xlarge. Pricing remains aligned with the xlarge SKU. Practically speaking, if you ship React Native, Swift, or Electron builds, you can speed up parallelization while you refactor your release workflows for OIDC. Small boost, same monthly math. Also relevant: the Copilot coding agent no longer requires Actions to be enabled, which simplifies org policy when you want AI help without entangling automation toggles.

People also ask: Can I stick with granular tokens and skip OIDC?

Yes—but weigh the trade‑offs honestly. Granular tokens with write access now default to enforcing 2FA, and for CI you’ll need to enable the bypass explicitly. They also expire quickly, and you must rotate them. That’s more ops load, not less. If you’re on a CI that doesn’t support npm’s trusted publishing yet, granular tokens are a temporary bridge. Use the minimum scope and the shortest viable lifetime, lock them to CIDR blocks where possible, and put rotation in code.

People also ask: Why can’t I publish the very first version with OIDC?

There’s an ecosystem quirk: configuring trusted publishers currently requires a package entry to exist in npm, which complicates initial publishes from scratch. Many teams do a one‑time manual publish (or a short‑lived token) to create the package, then enable OIDC for all subsequent releases. It’s a minor speed bump, but one you should plan for in your playbook.

Let’s get practical: a two‑track cutover that works

Here’s a pattern we’ve used to move orgs safely without freezing feature delivery.

Track A (secure-by-default): OIDC trusted publishing

Use this for public packages from public repositories where GitHub Actions (or another supported CI) runs your pipeline.

1. Baseline your runners. Use the maintained images and labels. If you need macOS builds, switch to macos-15-xlarge or macos-latest-xlarge for M2 performance. Keep an eye on image deprecations (Node 18 and older toolchains are being pruned in macOS images), as those can surprise legacy builds.
2. Enable trusted publishing. In npm, set the repository and workflow that’s authorized to publish. In GitHub, ensure your workflow runs on a cloud‑hosted runner so OIDC credentials are available.
3. Wire the workflow. On publish, the npm CLI detects OIDC and exchanges an ID token for a short‑lived registry token. No NPM_TOKEN secret required. Keep --access and provenance flags conventional; npm will attach provenance automatically when eligible.
4. Dry‑run on a canary package. Do a patch release on a non‑critical library to exercise the end‑to‑end path. Verify provenance shows up on the npm package page.
5. Flip the switch. Convert critical packages one at a time. Guard with branch protections and manual approvals if you need extra oversight.

Track B (bridge): granular tokens with 2FA bypass

Use this only when OIDC isn’t available (private repos, unsupported CI, or complex self‑hosted runners).

1. Create the token in the website. Right now, you can’t generate granular tokens with the CLI. Use the narrowest scope: per‑package or per‑scope, read/write only where necessary.
2. Enable bypass 2FA for the token, but restrict by IP (CIDR) and set a short expiration (days to weeks, not months). Tag the token with an owner and a rotation date in your secrets manager.
3. Update workflows to reference the new token and remove any classic token secrets left in the repo or org. Hunt down copies in Dockerfiles and runner images.
4. Schedule rotation. Put a calendar event before expiration and a pipeline that can roll the token without human heroics.

Most orgs run both tracks in parallel for a few weeks: OIDC for the easy path, granular tokens for edge cases, then converge on OIDC.

The “What breaks where” checklist

You don’t need a 200‑page migration deck. You need a ruthless checklist and a clear owner. Use this, copy it into your runbook, and modify for your stack.

1. Inventory packages and pipelines. List every package you publish, the repo and workflow that publishes it, the runner image, and the auth mechanism. Include internal tooling that calls npm publish indirectly.
2. Secret search. Search for NPM_TOKEN, //registry.npmjs.org/:_authToken=, and any npmrc with an embedded token. Scan your container images and AMIs used by runners.
3. Decide the auth path per package. OIDC or granular token. Document who owns the change.
4. Harden the workflows. Add branch protections, required checks, and approvals around publish jobs. Consider manual workflow_dispatch triggers for release pipelines until the dust settles.
5. Test the happy path. Use --dry-run where it helps, and publish canary releases to validate provenance and dist‑tag behavior.
6. Remove classic tokens. Revoke them in npm settings, delete secrets in your CI, and wipe any baked‑in copies from images.
7. Add rotation and monitoring. For any remaining tokens, automate rotation reminders and alert on npm publish failures. Keep a dashboard panel just for registry auth failures for the next month.

Risk and edge cases you should plan for

Initial publish edge case. If the package doesn’t exist yet, plan one manual or token‑based publish, then enable OIDC and lock down tokens.

Private packages. OIDC today targets publishing; other commands (install/view/access) still rely on traditional auth. Don’t rip out read-only tokens your build needs for private installs.

Self‑hosted runners. Trusted publishing support is scoped to cloud‑hosted runners. If you use self-hosted macOS or Linux, you’ll likely stay on granular tokens for a bit—or move publish to a small, cloud‑hosted job while keeping the heavy build on self‑hosted hardware.

2FA policy collisions. Org security teams often mandate 2FA everywhere and balk at bypass flags. That’s healthy skepticism. The compromise: proven OIDC first; bypass only on the narrowest token with strict IP and a short life.

Toolchain churn. macOS images continue to drop EOL toolchains (Node 18, older NDKs, etc.). If your release matrix includes macOS, check image release notes and pin versions intentionally.

Reference pipeline: OIDC publish on GitHub Actions

Here’s a minimal shape you can adapt. It assumes a public repo publishing a public package and a trusted publisher configured in npm.

name: release

on:
  workflow_dispatch:
  push:
    tags:
      - 'v*.*.*'

permissions:
  id-token: write  # required for OIDC
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm test --if-present
      - name: Publish
        run: npm publish --provenance --access public

No NPM_TOKEN here. The npm CLI detects the OIDC environment and performs the exchange for a short‑lived token under the hood.

Data you can plan around (dates, limits, labels)

• November 5, 2025: creation of classic npm tokens disabled across website, CLI, and API. Granular token rules tightened and write tokens capped at short lifetimes, with 2FA enforcement by default and a CI‑only bypass option.
• November 19, 2025: remaining classic tokens revoked. Local long‑lived publish tokens replaced by short session tokens; CI using classic tokens fails.
• Reusable workflows: limits increased to up to 10 nested calls and 50 total calls per run, useful for modular release orchestration.
• M2 macOS runners: generally available under macos-15-xlarge, macos-14-xlarge, macos-13-xlarge, and macos-latest-xlarge; priced as the existing xlarge SKU.

How this impacts engineering leadership and the business

This is more than a DevOps annoyance. Classic tokens are a common root cause in supply‑chain incidents: they sit for years, get copied into too many places, and surface in logs during a bad day. The migration forces better hygiene and gives you a shot at verifiable builds with provenance by default. On the business side, the risk is release friction: a failed publish on launch day is visible revenue and reputation.

Here’s the thing: you can turn this from a forced march into a modernization win. While you move to OIDC, clean up your workflow sprawl using the expanded reusable workflow limits. If you ship macOS artifacts, test the M2 runners and lock in predictable costs. Wrap all of it in a single Release Reliability objective you can measure—success rate of publish jobs, mean time to recovery, and time-to-approve for human-in-the-loop releases.

What to do next (devs and managers)

For developers:

• Run the checklist above today. If you find classic tokens or unknown secrets, open a blocking issue.
• Move eligible packages to trusted publishing. Keep a short README in the repo’s release/ folder documenting the setup.
• For edge cases, mint granular tokens with the strictest scope and the shortest expiration you can live with, and schedule rotation.

For engineering managers:

• Assign a single owner for the migration and publish a one‑page plan internally with dates and package lists.
• Set a temporary release freeze window for the morning of November 19 and staff an incident channel, just in case.
• Invest a few hours hardening release workflows—branch protections, approvals, and dashboards for registry auth failures.

Further reading and hands‑on guides

If you need a structured plan you can drop into Jira today, grab our step‑by‑step guides: a pragmatic 10‑day CI rescue plan, a focused Nov 19 cutover guide, and a last‑mile playbook for teams with tricky monorepos and self‑hosted runners. Planning to refactor Actions while you’re here? See our take on November’s Actions updates and how to exploit the new limits without spiking costs.

FAQ quick hits

Do I have to enable 2FA to publish locally?

Yes, that’s the direction. Expect stronger MFA expectations for local publishing and a push toward passkeys/WebAuthn. For CI, either use OIDC trusted publishing or a granular token with bypass 2FA explicitly enabled.

Can I keep using npm token create to mint what I had?

No. The CLI no longer creates classic tokens, and granular tokens must be created in the website for now. Plan for web‑based creation and document the process in your security runbook.

Will this affect installs from private registries?

Installs continue to use traditional auth. Don’t confuse publishing auth with install auth; keep read‑only tokens for private package installs and scope them tightly.

Want help shipping this safely?

If you’re short on time or talent for this fix, bring in a partner who’s done it before. Our team has shipped OIDC cutovers in orgs from 10 to 1,000 developers and knows where the bodies are buried—monorepos, self‑hosted runners, and those dusty Dockerfiles. Learn more about our services, browse a few case studies, or just drop us a line. We’ll keep your release train on time and your credentials out of Slack screenshots.

The bottom line

Classic tokens had a good run, but they’re exactly the kind of credential attackers love: long‑lived, broadly scoped, and hard to track. The migration is disruptive, but it unlocks better defaults—short‑lived, scoped credentials, provenance by default, and less secret management overhead. Treat November 19 as a forcing function to modernize your release system, not a one‑off fire drill. Do the inventory, pick the right auth per package, and move the critical ones to OIDC now. Your future self will thank you the next time a supply‑chain scare hits the feed.