The rules of the game just changed. With the latest npm token changes, GitHub has disabled creation of classic tokens (effective November 5, 2025) and will revoke all remaining classic tokens on November 19, 2025. New granular tokens with write permissions now enforce 2FA by default, include a Bypass 2FA setting for CI, and have enforced maximum lifetimes. If your deployments, bots, or release scripts still depend on long‑lived secrets, the clock is ticking.
What changed, exactly? The short, dated version
Here’s the thing: vague headlines don’t help a release manager. You need dates and behaviors. As of November 5, 2025, new classic tokens can no longer be created via npmjs.com, the CLI, or the API. Existing classic tokens keep working until November 19, 2025, at which point they’re revoked. New granular tokens with write permissions enforce 2FA by default; there’s a Bypass 2FA option meant for noninteractive CI. Granular token lifetimes are capped—no more “forever” secrets lurking in a build system. Some previously created tokens have been adjusted to earlier expirations, and local long‑lived publishing sessions are being replaced with short, time‑boxed sessions.
Key dates and operational details
• November 5, 2025: Creation of new classic tokens is disabled. CLI commands that used to mint classic tokens no longer do so.
• November 19, 2025: All remaining classic tokens are revoked. Long‑lived local publish sessions shift to short, session‑based behavior.
• Granular write tokens: 2FA enforced by default; CI can explicitly enable “Bypass 2FA” when human interaction isn’t viable.
• Token lifetimes: Enforced maximums to reduce blast radius; review expirations now and plan rotation windows.
If you want a fast primer and a timeline at a glance, our deadline quickstart in NPM Token Migration: Beat the Nov 19 Deadline covers the policy milestones. This piece focuses on how to execute the cutover without breaking releases.
Why it matters: risk, reliability, and reality
Dependency attacks have gotten sharper. One stolen maintainer token can poison a tree of packages and downstream apps in hours. Tightening authentication, shrinking token lifetimes, and nudging teams toward Trusted Publishing (OIDC‑based, identity‑bound, no long‑lived secret) are the right call. But the reality is messy: large organizations run mixed CI (self‑hosted and cloud), multiple registries, and monorepos with custom release tooling. The path to secure defaults has to work on a Tuesday afternoon when a patch release can’t slip.
The 10‑day cutover plan for npm token changes
Use this if you’re staring at November 19 and want a disciplined, low‑risk path. Short on time? Compress Days 6‑9, but keep the dry runs.
Day 1–2: Inventory and map your blast radius
• Enumerate tokens: Check npm settings for organization and user tokens; list secrets in CI providers; search infra-as-code for “NPM_TOKEN,” “NODE_AUTH_TOKEN,” and registry URLs.
• Classify each usage: read only (install), read/write (publish), automation (release bots), and local developer flows.
• Flag classic tokens: Anything long‑lived or labeled “classic” is on the chopping block. Note their scopes and consumers.
• Identify owners: Attach a Slack/Teams group and on‑call to each pipeline. Cutovers fail when nobody’s on deck.
Day 3: Choose an approach per pipeline
• Trusted Publishing (OIDC): Best default for publishing from GitHub Actions, GitLab, or other OIDC‑capable CI. No stored token; the runner proves its identity at publish time.
• Granular token with Bypass 2FA: Use when your CI lacks OIDC today or you’re mid‑migration. Scope tightly (package‑level write at most) and set short expirations.
• Read‑only installs: Never use classic tokens. For private registries, use granular read tokens or vendor‑supported federated identity.
Tip: If you run self‑hosted runners behind strict egress firewalls, plan the network work now. If your CI needs fixed outbound IPs to reach npm or your own registries, see our guide on allowlisting strategies in Vercel Static IPs for Builds: The New Allowlist Fix.
Day 4–5: Wire up OIDC where you can
• GitHub Actions: Configure your npm org to trust your repository’s OIDC subject for publish. Use environment‑level protections (required reviewers, branch protections, tags) to restrict who can trigger publishes.
• GitLab CI: Set up OpenID Connect in your project/group and configure trust on npm. Lock jobs to protected branches/tags.
• CircleCI/Jenkins: If OIDC is available, enable it. Otherwise, temporarily use granular tokens with short expirations and a rotation job while you evaluate OIDC support.
Guardrails: tie publish to immutable tags, require code owners on version bumps, and record provenance. If your stack uses SBOMs or SLSA attestations, verify those artifacts on publish.
Day 6–7: Replace classic tokens and rotate secrets
• Create granular tokens only if you must: scope to a single package or org‑level write for a narrow set of packages. Set the minimum lifetime that works with your rotation cadence.
• Enable Bypass 2FA for noninteractive CI publishing only. Do not enable it on user tokens.
• Store tokens as CI secrets, not in repo. Restrict secret access to the publish job or environment; deny PRs from forks.
• Replace classic tokens everywhere. Keep a runbook that shows which pipelines moved, by when, and with what fallback.
Day 8: Dry runs and canaries
• Use “dry run” options in your release tooling, and publish to internal registries or a scratch scope first.
• For public packages, publish a pre‑release under a temporary dist‑tag (for example, “next”). Verify provenance, checksums, and installability from a clean environment.
• Rehearse a rollback: confirm you can unpublish within policy, yank versions if needed, or release a hotfix immediately.
Day 9: Cutover window with live telemetry
• Announce the window; keep the owners on call. Merge the change, tag the release, and publish via OIDC or the new granular token.
• Watch error rates: 401/403 responses, provenance validation errors, and CI job failures. Keep dashboards open for 30–60 minutes.
• If something goes sideways, rollback to a known good dist‑tag while you fix the pipeline. Avoid re‑enabling classic tokens; they’re gone on November 19 regardless.
Day 10: Lock down and document
• Delete now‑unused tokens; reduce scopes where excessive.
• Add alerting for token usage anomalies and failed publish attempts.
• Document the new normal: OIDC subject claims, required branch protections, rotation cadence, and emergency contacts. New joiners shouldn’t have to ask in Slack.
Trusted Publishing or granular tokens—how to decide?
• Choose Trusted Publishing when your CI supports OIDC and you can restrict who triggers release jobs. It removes a whole class of secret management failures and aligns with signed, attestable releases.
• Use granular tokens when OIDC isn’t available on a critical path yet. Scope narrowly, set short expiry, and plan to revisit. The Bypass 2FA setting exists for robots—use it sparingly and only in noninteractive jobs.
I’ve migrated mixed shops where some repos moved to OIDC in hours, while others needed a staged path. The winning pattern: push OIDC first for your most‑used public packages, then tackle the tricky pipelines with short‑lived tokens and aggressive rotation.
People also ask
Do developers still need 2FA if we use OIDC?
Yes. OIDC protects the publish path, but human accounts still manage repos, permissions, and release approvals. Keep passkeys/WebAuthn as your default second factor.
Is Trusted Publishing required?
No, but it’s the recommended secure route for publishing. Granular tokens remain available, with write tokens enforcing 2FA by default and optional Bypass 2FA for CI.
Can we keep classic tokens for read‑only installs?
No. Classic tokens are being revoked. For private installs, use granular read tokens or federated identity patterns supported by your tooling.
Will these changes break our monorepo release scripts?
Not if you prepare. The biggest breakages appear where scripts assumed a forever token. Replace those assumptions with OIDC or a short‑lived granular token and add a rotation job.
Gotchas we keep seeing in the field
• Shadow tokens in infra: Old tokens live inside self‑hosted runners, Docker images, and AMIs. Rebuild images and rotate secrets, don’t just update repo variables.
• Over‑broad scopes: Org‑wide write when the job only publishes one package. Tighten to the minimum and log token usage.
• Fork PR leakage: CI secrets exposed to untrusted forks. Enforce “secrets not available to forks” and require maintainers to trigger release jobs.
• Human tokens in automation: Any write token tied to a person’s account is a support ticket waiting to happen. Use org or bot identities for automation.
• Network egress traps: Private registries and egress allowlists can silently block OIDC or publish calls. Validate IPs and DNS early; if you rely on fixed egress for builds, our primer on static IP allowlists for builds will save hours.
Enterprise rollout framework you can reuse
Roll this like any security‑sensitive platform change: a small, repeatable playbook, not a “big bang.”
• Stage 0: Decision record. Capture why each repo chooses OIDC or granular tokens and who signed off.
• Stage 1: Golden repo. Convert one high‑value library first; use it to template the rest.
• Stage 2: Automation. Codify trust relationships and release templates as reusable modules (reusable workflows, pipeline templates, or Jenkins shared libraries).
• Stage 3: Policy. Require protected tags for release jobs, enable mandatory reviewers, and audit secrets usage monthly.
• Stage 4: Observability. Ship provenance, SBOMs, and attestation on publish. Alerts on failed publishes and unexpected token use.
• Stage 5: Education. Document the new flows and add pre‑commit or pre‑publish checks so devs get feedback locally.
If you’re steering a broader developer‑platform transformation, our guides on coordinating multi‑agent tooling and governance apply too—look at GitHub Agent HQ and MCP: The Migration Playbook for tactics that translate to any org‑wide migration.
Data points and version notes you can bank on
• November 5, 2025: New classic tokens disabled; granular write tokens enforce 2FA by default; Bypass 2FA now a configurable CI escape hatch.
• November 19, 2025: Classic tokens revoked; long‑lived local tokens replaced with short sessions.
• Granular tokens: Enforced maximum lifetimes, with earlier expirations applied in some cases to align with the policy window.
• CLI behavior: Commands that previously minted classic tokens no longer do; expect UI‑first flows for granular token creation while full CLI support catches up.
What to do next (this week)
• Today: Audit tokens and secrets across repos and CI; decide OIDC vs granular per pipeline.
• Tomorrow: Wire OIDC on at least one golden repo; add branch protections and tag‑based release gates.
• Within 72 hours: Replace any remaining classic tokens in production release paths; run dry‑run publishes and one real canary release.
• Before November 19: Delete unused tokens, shorten scopes, and finalize your rotation cadence.
Need help hardening releases while keeping velocity? See what our team delivers on the What We Do page, browse relevant playbooks on the blog, or reach out via contact to plan a fast, safe cutover.
FAQ for leadership: will this slow us down?
Short term, you’ll schedule a few windows and dry runs. Long term, you eliminate a class of incidents tied to stale secrets, you gain signed provenance for compliance, and you harden the path attackers love most: release automation. The move to identity‑bound, short‑lived credentials is table stakes in 2025. Do it once, do it right, and make it boring.
The bottom line
Security changes that hit the release pipeline are never fun, but they’re manageable with a clear plan. Use OIDC Trusted Publishing wherever possible; use tightly scoped granular tokens with short expirations when you can’t, and keep the rotation drumbeat. Make this migration a springboard to better controls—protected tags, provenance, and vigilant secrets hygiene. You’ll ship more confidently on November 19 and every release after.
