NPM Token Migration: Beat the Nov 19 Deadline

The npm token migration just got real. On November 5, 2025, GitHub disabled the creation of classic npm tokens and tightened rules for granular access tokens. On November 19, 2025, all remaining classic tokens will be permanently revoked. If your releases or internal registries still depend on legacy credentials, you’re on the clock. (github.blog)

What changed on November 5 (and what breaks on November 19)

Effective November 5, 2025: classic npm tokens can’t be created via website, CLI, or API. Existing classic tokens still work—for now. New granular tokens with write permissions enforce 2FA by default, and granular write tokens are capped at a 90-day maximum lifetime. There’s also a new Bypass 2FA option designed for CI/CD. (github.blog)

On November 19, 2025: GitHub will revoke all classic npm tokens and replace long‑lived local publishing tokens with 2‑hour session tokens. If your pipelines still use a classic token on that date, your publish step will fail immediately. (github.blog)

Why this is happening: a supply‑chain reality check

September’s wave of malicious package activity and maintainer‑targeted phishing wasn’t hypothetical—it was costly. Security researchers and registry operators removed hundreds of compromised packages and accelerated the shift away from broad, long‑lived credentials. GitHub has been explicit: legacy tokens and weaker 2FA paths have to go to reduce blast radius when credentials leak. (theregister.com)

There’s another change under the hood: new TOTP 2FA setups are disabled for npm access going forward, nudging maintainers to WebAuthn/passkeys and policy‑driven automation (OIDC) instead of copy‑pasted secrets. That’s a good trade—less friction for developers, less risk for everyone. (github.blog)

The npm token migration checklist

Here’s the straight‑line path to get compliant before the cutoff. Share this with every maintainer and release engineer on your team.

1. Inventory where tokens live. Search your CI config (GitHub Actions, GitLab, CircleCI), local ~/.npmrc files on release machines, build servers, and any deployment scripts. Assume there’s at least one forgotten classic token hiding in a vault or environment variable.

2. Generate a granular access token for npm. In npm settings → Tokens, create a Granular Access Token with the minimum scopes your workflow needs (often publish and read for your org’s packages). The CLI’s npm token create will no longer generate classics. (github.blog)

3. Decide: granular token vs. OIDC trusted publishing. If you publish from CI, use OpenID Connect to mint short‑lived credentials at build time and avoid storing tokens. If you truly need a token, enable the CI “Bypass 2FA” flag on the granular token—but treat it as a stopgap, not a forever solution. (github.blog)

4. Rotate and update pipelines. Replace classic tokens in secrets managers and CI variables. Confirm token lifetimes—write‑scoped granular tokens top out at 90 days, so set reminders or automate rotation. (github.blog)

5. Lock down local publishing. After November 19, long‑lived local tokens are gone; local/manual publishing will use 2‑hour session tokens with 2FA enforcement. Test your release scripts on a clean machine to catch prompts and timeouts. (github.blog)

6. Audit the blast radius. Remove classic tokens from repos and wikis, scrub CI logs, rotate any downstream secrets that may have been exposed, and enable provenance where possible. If you ever committed a token, rotate it—even if the repo is private.

How to update GitHub Actions for npm publishing

Let’s get practical. Most teams can switch to OIDC‑based trusted publishing in under an hour once org policies are aligned. At a high level:

First, define the npm registry as a federated audience in your CI so GitHub can exchange a short‑lived identity token for publish rights. Then, scope your workflow with the minimum permissions and branch rules that match your release process. Finally, remove old secrets—NPM_TOKEN should disappear from repo and org secret stores once OIDC is working.

Two notes that save time: the built‑in GITHUB_TOKEN for Actions is a GitHub credential, not an npm token—it won’t publish to npm by itself. And if you must use granular tokens temporarily, check the “Bypass 2FA” box for headless jobs or you’ll get unexpected prompts. Both behaviors are called out in GitHub’s changelog. (github.blog)

People also ask: will my builds fail on November 19?

Yes—if they depend on classic tokens. The revocation is hard. Treat November 19, 2025 as a drop dead date for classic credentials across website, CLI, and API. Migrate now, or plan for a release freeze. (github.blog)

Do I need 2FA for CI jobs?

You don’t physically enter a code in CI, but you must satisfy the new 2FA policies. Either lean on OIDC (preferred) or create granular write tokens with the CI “Bypass 2FA” flag enabled. Don’t leave bypass on for humans; it’s designed for automated jobs. (github.blog)

Are GitHub tokens affected?

No. These changes apply to npm registry tokens. GitHub personal access tokens and fine‑grained PATs aren’t impacted by the November schedule. That said, don’t conflate GitHub PATs with npm tokens in your automation—keep them separately scoped and stored. (github.blog)

What about private registries or internal packages?

If you publish to private scopes on npm, the same token rules apply. If you run a completely private registry, check its auth model—this npm change won’t rewrite your internal auth, but it’s a smart time to standardize on short‑lived credentials and hardware‑backed keys for admins.

The security backdrop: attacks, tokens, and 2FA

Classic tokens were too permissive and too durable. Attackers only needed one leak—from a misconfigured runner, a compromised laptop, or a malicious dependency—to push malware to the registry. Security teams pulled more than 500 compromised packages in recent campaigns, and operators tightened the model: shorter token lifetimes, passkeys over TOTPs, and policy‑driven trust at publish time. (theregister.com)

Zooming out, it’s the same playbook we use to harden other parts of the stack: remove long‑lived secrets, bind permissions to intent (workflows, not users), and make the secure path the easy path. The registry is finally pushing this across the board—good news for anyone who ships JavaScript in production. (github.blog)

Migration pitfalls we keep seeing

There’s no virtue in learning these the hard way. If you’re racing the deadline, vet these edge cases early.

• Shadow tokens in monorepos. Big repos often hide tokens in old .npmrc files under packages/. Grep your tree and your build logs for “_authToken”.

• Runner images with baked‑in tokens. Golden AMIs and Docker images sometimes have credentials copied during image build. Rebuild clean images and scrub layers.

• Secrets syncing across orgs. If you mirror repos, secrets won’t mirror. Make a per‑org plan for OIDC or tokens—it’s not one‑and‑done.

• Interactive prompts in headless jobs. After November 19, local/manual publishing will enforce 2FA and 2‑hour sessions. Your “dry run” might succeed on a laptop and then hang in CI. Test both paths. (github.blog)

• Confusing GitHub and npm credentials. The GITHUB_TOKEN unlocks GitHub APIs, not npm publish. Use OIDC to mint npm trust at publish time instead of pasting secrets. (github.blog)

Governance: pair token hygiene with agent governance

Tokens are one slice of a broader automation story. As teams adopt AI agents and richer CI bots, apply the same guardrails: short‑lived credentials, least privilege, clear audit trails, and policy as code. If you’re exploring GitHub’s Agent HQ or MCP‑based tooling, align your identity and authorization model now so bots can’t side‑step your change controls later. We’ve published migration guidance on governing multi‑agent development and integrating with MCP—use those as templates for your own controls. Run multi‑agent dev safely and the MCP migration playbook both map cleanly to this token overhaul.

Business impact: avoid a Friday fire drill

If your product revenue, customer updates, or security patches depend on npm publishes, this is operational risk, not a developer inconvenience. Treat November 19 as a change‑freeze date for anything that still uses classic tokens. Allocate owner time this week, not next. If you’re short on hands, get help—this is a high‑leverage fix measured in hours, not weeks, and it reduces your exposure every single release going forward.

If you’re also reevaluating cloud resilience after recent incidents, combine token cleanup with a quick reliability sprint: fail open on read‑only mirrors, cache critical tarballs, and rehearse degraded‑mode deployments. Our earlier guidance on building for resilience under provider incidents still applies—ship a graceful fallback instead of a blank page. Bulletproof your stack against outages pairs well with today’s security work.

Mini‑framework: 3 lanes to finish before Nov 19

Use this to pick your path and move.

Lane A (preferred): OIDC trusted publishing—Eliminate stored tokens, bind publish rights to the workflow, and let the registry mint short‑lived credentials on demand. Ideal for teams with centralized CI and predictable release branches.

Lane B: Granular tokens with rotation—Create narrow‑scoped tokens with “Bypass 2FA” for CI only. Set a 60–75 day rotation policy, automate replacement, and monitor for drift. Good for polyglot CI or when OIDC isn’t available yet. (github.blog)

Lane C: Local/manual publishing hardening—For teams that publish from laptops or air‑gapped networks, plan around 2‑hour sessions and enforced 2FA. Use passkeys, dedicate a hardened release machine, and script as much as possible to reduce human error. (github.blog)

FAQ for CTOs and platform teams

How do we prove compliance after we migrate?

Write a short control: “All npm publishes use OIDC or granular tokens with 90‑day max lifetime; no classic tokens permitted.” Enforce via a policy check in CI that fails builds if NPM_TOKEN is set, require provenance on publishes, and audit token pages monthly. Keep screenshots in your GRC system.

Will shorter tokens slow down developers?

No. With OIDC, there’s nothing to paste or rotate—publishing becomes "+1 line of YAML" and a signed exchange at runtime. For granular tokens, automate rotation and use repository environments so developer ergonomics are preserved.

Do we need to retrain the whole org?

Not really. Train release owners and platform engineers. Everyone else just sees faster, safer releases. If you’re rolling out AI agents or new CI bots, fold identity lessons into that enablement, too. Our team can help you blueprint the rollout. See our services for secure delivery and contact us to schedule a working session.

What to do next (this week)

• Identify every classic token and where it’s used. Create a shared issue and track owners.

• Pick Lane A (OIDC) or Lane B (granular token). Don’t mix unless you must.

• Ship one pilot package end‑to‑end with the new setup. Document the steps and copy to the rest.

• Delete old secrets. Add a CI check that blocks NPM_TOKEN going forward.

• Enable passkeys for maintainers. Remove new TOTP enrollments as your fallback. (github.blog)

If you want a second set of eyes, we’ve done this before—migrating teams off legacy tokens, hardening CI, and rolling out agent governance in parallel. Browse a few recent projects and our latest engineering notes, then let’s put a two‑hour workshop on the calendar.

Final thought: don’t let a policy change become a production incident

Here’s the thing—this isn’t a scary migration if you cut out the guesswork. The path is paved and documented, the deadlines are firm, and the security upside is immediate. Make the switch to OIDC or granular tokens, remove long‑lived secrets from your pipelines, and treat identity as part of your code. Your future self (and your incident pager) will thank you on November 19. (github.blog)