npm token changes deadline: fix your CI today

Let’s be blunt: your CI will break today if it still relies on classic npm tokens. These npm token changes have been rolling out for weeks, and the deadline arrives with classic tokens revoked, stricter 2FA defaults, and shorter lifetimes on granular tokens. The good news is there’s a safer path—trusted publishing with OIDC—that removes long‑lived tokens from your pipelines altogether. Here’s exactly what changed, why it matters, and how to migrate in under an hour without burning a release day.

What changed—and when?

Two milestones flipped the table on old habits:

November 5, 2025: GitHub disabled creation of new classic npm tokens across website, CLI, and API. Existing classic tokens were put on a short fuse and warned for migration. Granular tokens with write scopes started enforcing 2FA by default, and their maximum lifetime was capped at 90 days (with shorter defaults like 7 days for new tokens).

November 19, 2025 (today): All remaining classic npm tokens are revoked. Any publish job or release script still using them will fail. If your release train runs on cron, expect alarms.

In parallel, GitHub has been nudging maintainers to move from TOTP-based 2FA to phishing-resistant WebAuthn/passkeys for local publishing, and to adopt Trusted Publishing (OIDC) for CI. Trusted Publishing reached GA in mid‑2025 and requires npm CLI v11.5.1 or newer.

Why this matters more than an inconvenience

The timeline isn’t arbitrary. This fall, the JavaScript ecosystem saw multiple supply chain incidents that abused leaked or stolen tokens and CI workflows. Campaigns like GhostAction swiped thousands of secrets from compromised workflows. Worm-style npm attacks demonstrated how one maintainer account and a long‑lived token can cascade into dozens of trojanized packages in hours. Shorter‑lived tokens and stronger auth reduce blast radius. OIDC‑based publishing is better yet: no long‑lived token exists to steal.

If you own a popular package—or you’re a business that implicitly trusts upstreams—reducing those failure modes isn’t optional. It’s table stakes.

The 30‑minute migration plan

There are two viable paths. Path A (recommended) moves you to OIDC‑based Trusted Publishing. Path B is a pragmatic fallback using granular access tokens with tight lifetimes. Do Path A first; keep Path B as a break‑glass option.

Step 1 — Audit your current usage (5 minutes)

Find where tokens live and who depends on them:

• Search your org for NPM_TOKEN or registry auth in CI: GitHub Actions secrets, organization secrets, repository variables, and self‑hosted runner env.
• Check ~/.npmrc on any build servers for //registry.npmjs.org/:_authToken=.
• List release workflows that publish on tag push, manual dispatch, or merges to main. Note who owns them.

Decision point: if these are GitHub‑hosted or GitLab shared runners, proceed with Trusted Publishing. If you rely on self‑hosted runners that can’t move today, plan the granular-token fallback and schedule the OIDC upgrade.

Step 2A — Switch to Trusted Publishing (OIDC) (15–20 minutes)

This is the recommended default. It eliminates long‑lived write tokens and adds provenance by default.

1. Ensure npm CLI v11.5.1+ in your CI image or setup step.
2. Authorize your workflow as a trusted publisher for the package (one trusted publisher per package at a time). Do this once per package.
3. Update your GitHub Actions job to request an ID token and publish with npm.

Minimal GitHub Actions example for publishing on semver tags:

name: release
on:
  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: 20
          registry-url: https://registry.npmjs.org
      - run: npm ci --ignore-scripts
      - run: npm test --if-present
      - run: npm publish --access public

Notes:

• No NPM_TOKEN secret is required. The CLI exchanges the workflow’s ephemeral OIDC ID token for publish credentials at publish time.
• Provenance is automatic with trusted publishing; the --provenance flag is optional for most setups.
• Trusted Publishing currently supports GitHub‑hosted and GitLab shared runners. If you’re on self‑hosted runners, plan a move or use the interim token fallback.

Step 2B — Fallback to granular tokens (10–15 minutes)

If you can’t switch to OIDC today, use granular tokens with tight scope and lifetimes. Expect to rotate frequently.

1. Create a granular access token on npm with the minimal scopes for your package(s). For non‑interactive CI publishes, enable the Bypass 2FA option; otherwise the publish will pause waiting for a second factor.
2. Set the token’s expiration to as short as your release cadence allows. Defaults are now short (often seven days) and max is 90 days.
3. Store it as NPM_TOKEN in repository or organization secrets. Rotate on a schedule before expiration.
4. Wire into CI:

permissions:
  contents: read
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          registry-url: https://registry.npmjs.org
      - run: npm ci --ignore-scripts
      - run: npm test --if-present
      - run: |
          echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > ~/.npmrc
          npm publish --access public
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Set a rotation reminder in your issue tracker that pings code owners, not just a generic DevOps account. That’s what fails silently.

People also ask: do I need both OIDC and tokens?

No. If you enable Trusted Publishing for a package, the registry will accept publishes from the authorized OIDC workflow without a token. You can still publish locally with passkey‑protected auth, but your CI shouldn’t carry a write token anymore.

Is WebAuthn/passkeys mandatory now?

For local publishing, passkeys are the preferred 2FA method and new TOTP setups have been curtailed. Existing TOTP continues to work for the moment, but plan to migrate. For CI, use OIDC so you can avoid any human‑in‑the‑loop second factor entirely.

What could break today—and how to triage fast

Expect these failure patterns as classic tokens are revoked:

• npm publish returns 401/403: Your job is still reading a classic token from ~/.npmrc or a secret. Rotate to granular or switch to OIDC.
• Publish hangs on OTP prompt: You created a granular token without enabling Bypass 2FA for CI, or your job prompts because it’s using local auth. Fix token settings or move to OIDC.
• “Provenance required” errors: Some orgs enforce provenance; ensure you’re on npm CLI v11.5.1+ and use trusted publishing (provenance is automatic).
• Self‑hosted runners: Trusted Publishing currently doesn’t support them—use granular tokens temporarily, then plan to migrate runners or workflows.

A quick governance model that actually sticks

If you run more than a handful of packages, centralize the guardrails:

• Registry policy: Default to Trusted Publishing. Allow granular tokens only by exception with documented rotation cadence.
• Secrets policy: Ban long‑lived write tokens in org secrets. Enforce repo rules that block merges to release branches if a classic token is detected in diff or secrets scan.
• Attestation: Require provenance for publishes. Audit monthly with a report tied to package owners.
• Break‑glass: Define an emergency granular token process with a 7‑day max and automatic revocation at day 8.

We’ve helped clients adopt similar controls at scale. If you need a template for GitHub governance and automation, our GitHub governance playbook is a solid starting point, and our secure DevOps services can implement it quickly.

Known limitations and edge cases

Trusted Publishing is great, but know the edges:

• One trusted publisher per package: If you maintain mirrors across CI systems, you’ll need to switch the configured publisher as part of your process.
• Publish only: OIDC covers the publish operation. Other npm commands (install, view, access) still use traditional auth methods.
• Self‑hosted runners: Not currently supported. This is the most common blocker for regulated environments; consider moving release jobs to hosted runners even if builds stay self‑hosted.
• npm CLI version: Pin v11.5.1+ for smooth OIDC flows and provenance.

Security backdrop: why GitHub tightened the screws

Over the last two months, coordinated campaigns abused maintainer accounts and CI workflows to exfiltrate credentials and publish backdoored packages. Long‑lived npm tokens were a common prize. GhostAction alone ripped thousands of secrets from CI environments. Separate worm‑style incidents demonstrated automated lateral spread across a maintainer’s full package portfolio via stolen tokens. These attacks weren’t theoretical—they forced key maintainers and vendors to yank compromised versions, rotate keys, and audit pipelines. Today’s changes directly target those attack paths by killing classic, broad‑scope tokens and pushing everyone to short‑lived granular tokens or, better, tokenless OIDC.

Let’s get practical: the “Green Build” checklist

Before you cut the next release, run this checklist end‑to‑end:

• OIDC enabled on the release workflow: permissions: id-token: write.
• Trusted Publisher configured for the package.
• CLI pinned to npm@^11.5.1 (or image includes it).
• No write tokens present in repo/org secrets except documented break‑glass.
• Provenance visible on the package page after a dry‑run publish to a canary tag (e.g., v0.0.0-canary.0).
• Release rollback plan defined (unpublish window, deprecate bad versions, and alert consumers).

If you still rely on tokens today, at least enforce a 7–30 day lifetime, don’t reuse across repos, and scope them narrowly.

Sample enterprise policy snippet

For organizations formalizing controls, here’s a concise policy you can adapt:

“All npm package publishes must use Trusted Publishing (OIDC) from GitHub‑hosted runners. Granular tokens are allowed only via break‑glass requests with max 30‑day lifetime and automatic rotation. All publishes must include provenance attestations. Classic tokens are prohibited and blocked by secret scanning. Non‑compliant publishes will be reverted and owners notified.”

Related CI hardening you shouldn’t skip

Token reform is one layer. You’ll also want to plug a common foot‑gun in CI: unsafe uses of pull_request_target in GitHub Actions. If that’s in your org, fix it with our pull_request_target hardening guide. And if your platform modernization backlog is competing for time, stack changes smartly—our recent engineering guides cover migration playbooks your release leads can reuse.

What to do next (today and this week)

Today:

• Flip one package to Trusted Publishing and ship a canary tag to validate.
• Replace any remaining classic tokens with granular tokens only if absolutely necessary.
• Alert package owners about today’s revocations and expected CI behavior.

This week:

• Migrate all release workflows to OIDC. Archive any token secrets left in org scope.
• Enable provenance enforcement on critical packages.
• Roll out passkeys to all maintainers; retire TOTP where feasible.
• Document the break‑glass token process with owners and auto‑revocation.

Need a hand pressure‑testing your release pipelines or codifying these controls? Talk to us via bybowu.com/contacts.

FAQ quick hits

Does this impact GitHub personal access tokens?

No—this change is specific to npm registry auth. Your GitHub PATs and fine‑grained PATs are unaffected, but don’t store npm tokens in GitHub secrets anymore if you’re on OIDC.

Do I need to rotate every package’s token separately?

If you’re still on granular tokens, yes—use one token per package with minimal scope. But that’s exactly why Trusted Publishing is superior: no rotation treadmill.

Can I keep TOTP for now?

Existing TOTP may still work for local flows, but plan to move to passkeys. For CI, skip both and use OIDC.

The bottom line: if you fix one thing today, make it publishing without long‑lived tokens. That change alone collapses an entire class of supply‑chain risk. Then standardize it across your org so the next headline doesn’t include your package name.

Want practical help making this stick? Our team ships this kind of change without drama. See what we do on What we do and reach out when you’re ready.