npm Token Migration by Nov 19: The Last‑Mile Playbook

Let’s be blunt: if you haven’t started your npm token migration, you’re about to have a very quiet release week. GitHub’s November 5, 2025 changes disabled creation of classic tokens and set a hard stop: all remaining classic tokens are revoked on Wednesday, November 19, 2025. New granular tokens have tighter lifetimes and 2FA defaults, and Trusted Publishing (OIDC) is mature enough for most teams. This playbook gets you over the line without breaking prod.

What exactly changed—and when?

Here’s the thing: the rules moved, and they’re not moving back. On November 5, 2025, GitHub confirmed three big changes for npm publishers:

• Classic tokens are end-of-life. You can’t create them anymore. Existing classic tokens are revoked on Nov 19, 2025.
• Granular tokens tightened up. Write-capable tokens are capped at a 90-day lifetime; defaults trend shorter. 2FA enforcement is on by default, with an explicit “Bypass 2FA” switch for CI.
• WebAuthn/passkeys are the path forward. New TOTP setups aren’t accepted; plan to migrate existing TOTP to passkeys. For automation, use Trusted Publishing where you can.

Complementing that, Trusted Publishing with OIDC is generally available. When you publish via OIDC from supported CI providers (notably GitHub Actions), npm issues short‑lived credentials on demand and automatically attaches provenance attestations for public packages. No long‑lived secret to leak, nothing to rotate.

People also ask: What happens on November 19 if I do nothing?

Your pipelines that still inject a classic token will fail with authentication errors—typically a 401/403 from the registry or a publish denied in the npm CLI. That includes release jobs, monorepo publish steps, and any internal tooling that runs npm publish or npm dist-tag under the hood. If you’re unlucky, you’ll also have stale tokens hiding in container images, GitHub Action secrets, or self‑hosted runner environments. Those jobs will fail the moment they try to talk to the registry.

npm token migration: the 90‑minute cutover runbook

If you have one hour and a half, you can get from risk to green. This is the playbook we use with teams that need to unblock releases today.

0–15 minutes: inventory and blast radius

Make a quick map of everywhere a token might live:

• CI systems: GitHub Actions secrets, GitLab CI variables, CircleCI contexts, Jenkins creds, self‑hosted runners.
• Release bots and scripts: taggers, changelog generators, monorepo managers (Lerna, Changesets, Nx), templated workflows.
• Container images: base images that include .npmrc or environment vars.
• Local developer machines: ~/.npmrc and shell profiles used by maintainers.

Search your repos for _authToken, NPM_TOKEN, and npmrc. If you find classic tokens, highlight those jobs as red‑flag critical.

15–60 minutes: pick your path—OIDC first, token second

Path A: Trusted Publishing (recommended)

1. Enable Trusted Publishers for the package in npm settings and record your CI provider’s identity (e.g., GitHub repository and environment).
2. In GitHub Actions, add a job with OIDC permissions: permissions: id-token: write, contents: read. Use the official npm or actions/setup-node guidance to publish via OIDC. No secret needed.
3. Run a --dry-run publish from a non-default branch to confirm the handshake, then a real patch publish of a test package or canary tag.

Path B: Granular token (when OIDC isn’t possible yet)

1. Create a granular access token with the minimum permissions you need (typically publish:package and automation scope for your org/package). Set an expiration under 90 days; 7–30 is a sane range for rotation discipline.
2. Add the token to CI as NPM_TOKEN. In your workflow, configure registry auth with npm config set //registry.npmjs.org/:_authToken=${NPM_TOKEN}.
3. Run a --dry-run, then publish a canary. If your package requires 2FA, either enable “Bypass 2FA for CI” on the token or move to OIDC now.

Either path: confirm that provenance shows up for public packages when using OIDC, and that your release tooling (Changesets, semantic‑release, custom scripts) sees the new auth method.

60–90 minutes: revoke, lock down, and verify

1. Revoke every remaining classic token. Keep the list in a ticket for audit. Don’t leave them to be revoked by the platform on Nov 19; cut exposure now.
2. Harden package settings. For interactive publishes, require 2FA. If you’ve proven OIDC works, consider “require 2FA and disallow tokens.”
3. Add safeguards: protect release branches, require status checks, and block unreviewed workflow edits. Turn on provenance checks in your consumer repos where practical.
4. Run a full release dry‑run. Execute the entire pipeline (build → version → tag → publish) with a patch version to validate end‑to‑end.

Why Trusted Publishing (OIDC) wins long term

Granular tokens are a good stopgap. But OIDC removes the root problem—static credentials. With Trusted Publishing:

• Credentials are minted just‑in‑time for one job with a narrow audience and short lifetime.
• There’s nothing to rotate or accidentally check into a repo, container layer, or support ticket.
• Public packages get automatic provenance, which gives your users cryptographic proof of where the build came from.

If your organization already uses GitHub Actions, the path is straightforward. And with the November 2025 Actions updates (M2 macOS runners GA and higher limits for reusable workflows), many projects get faster builds and more composable pipelines while they modernize publishing. For a deeper dive on the Actions changes, see our take in GitHub Actions November 2025: Limits, M2, Copilot.

Common gotchas that break pipelines

We keep seeing the same traps in enterprise repos. Save yourself a day by checking these now.

• Invisible tokens in base images. Old images often bake in .npmrc. Inspect and rebuild; don’t rely on docker exec to patch running workloads.
• Monorepo publishing order. Tools like Changesets may run multiple npm publish steps. Ensure every step has OIDC permissions or the new token context.
• 2FA + CI mismatch. If a package requires 2FA and you’re still on tokens, you must enable bypass for CI or switch to OIDC. Otherwise you’ll get a late‑stage prompt that CI can’t satisfy.
• Org policies blocking OIDC. Some orgs restrict OIDC audiences or require specific environments. Align your permissions and environment rules with the publishing job.
• Private registries and mirrors. If you front npm with a cache/proxy, validate that the publish path talks to the upstream registry with your new auth model.
• Self‑hosted runners. Harden runner machines: ephemeral disks, secret scrubbing, and no long‑lived service accounts. OIDC reduces risk; sloppy runners re‑introduce it.

People also ask: Should I rush to passkeys if I only publish from CI?

If Trusted Publishing is your sole publish path, your maintainer accounts won’t enter a code during releases. You should still enroll passkeys to protect account access and package settings. Think of passkeys as your break‑glass and admin‑change control, not as a replacement for OIDC.

People also ask: Do read‑only tokens get revoked too?

The Nov 19 cutoff applies to classic tokens broadly. If you have read‑only automations using classic tokens (installing from private registries, for example), migrate those to granular tokens with read scopes or use repo‑level alternatives (e.g., GitHub Packages with GITHUB_TOKEN) where appropriate.

A short, honest timeline

Today is November 8, 2025. You have eleven days until classic tokens die. Realistically, you’ve got five business days to migrate core projects and one week for stragglers. Expect 30–90 minutes per repo once you’ve done the first one. For org‑wide scale, handle shared workflows and base images first to get compounding wins.

A lightweight governance framework you can copy

Use the “3x3 Publishing Governance” checklist for every package group:

1. Identity: All maintainers have passkeys; OIDC audiences are pinned to specific repos/environments; human publishes require 2FA.
2. Access: No classic tokens exist; granular tokens (if any) expire in ≤30 days and are write‑only where needed; OIDC is the default.
3. Evidence: Provenance is present on public packages; release artifacts are immutable; audit logs capture who, what, when, and from where.

Tag every item red/yellow/green. Red gets a ticket today, yellow gets a date, green gets automated checks (pre‑merge policy + scheduled audits).

Step‑by‑step: enable Trusted Publishing in GitHub Actions

Here’s a concise, vendor‑aligned setup:

1. In npm package settings, add your GitHub repo as a Trusted Publisher and select the environment you’ll use.
2. In your workflow, add OIDC permissions:

   permissions:
     id-token: write
     contents: read
   

3. Use setup‑node with registry authentication handled by OIDC, then run your publish step. Example with Changesets:

   jobs:
     release:
       runs-on: ubuntu-latest
       permissions:
         id-token: write
         contents: read
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with:
             node-version: 22
             registry-url: https://registry.npmjs.org
         - run: corepack enable
         - run: npm ci
         - run: pnpm changeset version && pnpm changeset publish

4. Publish a canary (1.2.3-canary.0) to verify end‑to‑end. Confirm provenance on the package page.

If you prefer a guided walk‑through, our earlier field notes lay out the sequencing and rollback tactics in Your CI cutover plan by Nov 19 and the bite‑sized checklist in the 10‑day CI/CD survival plan.

Security context: why this change matters now

September and October saw multiple supply‑chain scares, including account takeovers and publish‑pipeline compromises. Short‑lived credentials and OIDC‑based trust cut off entire attack classes—tokens stolen from laptops, logs, container layers, or runner disks don’t exist to be abused. Pair the npm changes with dev‑server hygiene, strong org policies, and ephemeral runners, and you materially reduce blast radius.

If you’re re‑architecting pipelines anyway, you may also benefit from GitHub Actions efficiency gains shipped this month (higher limits for reusable workflows and M2 macOS runners). Faster builds help offset the “we changed the release script” tax while you migrate. For practical tuning tips, skim our take in our November 2025 Actions guide.

People also ask: Does OIDC work outside GitHub?

Yes—npm Trusted Publishing supports multiple CI providers. The exact setup differs, but the model is the same: the CI job proves its identity to npm at publish time and receives a short‑lived credential. If your org uses mixed CI, standardize on OIDC‑capable providers for release jobs, and keep granular tokens as a narrow exception with short expiry.

What to do next (this week)

• Today: migrate one repo end‑to‑end to OIDC, revoke its classic token, and document the steps.
• Tomorrow: convert shared workflows and monorepo templates. Rebuild base images to purge baked‑in tokens.
• By Wednesday: move Tier‑1 libraries and apps. Enable passkeys for maintainers. Require 2FA for interactive publishes.
• By Friday: finish long‑tail repos, disable any remaining classic tokens, and schedule quarterly audits.
• If you’re stuck: drop us a note via Bybowu contacts or review the deeper guidance in Fix CI before Nov 19.

Risks and edge cases you should acknowledge

Be candid with stakeholders:

• OIDC policy drift. Over‑broad audiences or permissive environments dilute OIDC’s benefits. Keep them tight and reviewed.
• Provenance gaps. Private repos and certain workflows won’t get automatic attestations; confirm what’s covered and what isn’t.
• Human publish workflows. If you intentionally keep manual publishes, require passkeys for maintainers and restrict who can change package settings.
• Vendor lock concerns. If you worry about CI portability, define a thin interface: a make target or reusable workflow that abstracts publish mechanics so you can swap CI later.

Final thought

This isn’t just a security cleanup; it’s a maintenance dividend. You’ll ship with fewer secrets, clearer audit trails, and faster incident response. Do the first repo today, replicate the pattern across your estate, and you won’t even notice November 19 go by—other than your releases continuing to land on time.

If you want a partner to pressure‑test your plan or draft reusable workflows, our team has shipped dozens of these cutovers at scale—see what we do on Bybowu services or browse a few relevant projects in our portfolio.