Replies: 21 comments 25 replies
-
|
Are the "established trust" changes going to land before this change? This is great for those using other ci providers, but it will still almost certainly result in storing the actual login credentials in secrets unless we can completely eliminate the need for a token |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the great question — totally get the concern about "established trust" landing in time. For anyone using non-GitHub/GitLab CI providers, this change still means falling back to storing some kind of secret unless we can fully eliminate tokens. Token removal is now back to Nov 19 (not Dec 9 as earlier planned). CLI support for granular tokens will land at the same time, along with 2FA-by-default for new packages. Yarn v1/v2 auth is safe — the CouchDB endpoint is restored and live. What you can do right now to avoid storing long-term credentials: If you're on GitHub Actions or GitLab CI → switch to Trusted Publishing (OIDC). No token needed at all. If you drop your CI setup (Jenkins? CircleCI? Azure?), I can help draft a migration script or workflow. |
Beta Was this translation helpful? Give feedback.
-
|
It is not an enjoyable experience having to subscribe to new threads in order stay apprised of the state of things since the previous threads keep getting marked as resolved. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
If the date was moved to 2025-12-09, why do I have users complaining that their tokens were disabled yesterday?! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, is mandatory 2FA for local publishing still apart of the plan? I see we've enabled 2fa bypass on the Granular tokens, but is that a permanent policy or just a way to buffer the transition to Trusted Publishing? |
Beta Was this translation helpful? Give feedback.
-
|
I just got this email
I've been hearing about this change for a while, and I've seen the banner on npmjs.com. But this is the first time I'm told that this change actually affects me. So far I've been thinking "I don't know if this affects me, and I don't know how to check. I guess I'm not affected". So now I know that it does affect me. But I still don't know how. It'd be nice to have a link like: Click here to see the tokens that will be revoked. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sure it's already been asked but I don't have time to research really. What is a "classic" token? npm only shows me a "Type" column and I see: Granular |
Beta Was this translation helpful? Give feedback.
-
|
Has there been an updated release yet for CLI management of granular tokens? |
Beta Was this translation helpful? Give feedback.
-
December 9 Update: All npm classic tokens are now revokedHi everyone, The changes we've been preparing are now live. npm classic tokens are permanently revoked. All npm classic tokens have stopped working. They cannot be recovered. npm session tokens are live. New CLI for npm granular access tokens. You can now manage npm granular access tokens from your terminal. Check the npm CLI docs for the new commands. 2FA is now default for new packages. Starting today, new packages have 2FA enabled by default. What to do right nowLocal dev: Run CI/CD: Create npm granular access tokens via CLI or web. Best option: Set up OIDC trusted publishing if you're on GitHub Actions or GitLab. 📖 Full changelog: npm classic tokens revoked; session-based auth and CLI token management now available If something's broken, let us know below. We're monitoring this thread. Thanks for sticking with us through this transition. We appreciate your patience. |
Beta Was this translation helpful? Give feedback.
-
|
Do you have any updates on Azure DevOps as an OIDC trusted publisher? |
Beta Was this translation helpful? Give feedback.
-
|
Both short-lived tokens (created via If I set "Bypass 2FA" on a granular token, it doesn't ask me to authenticate to my account in the browser, but still fails. Are there any known issues on npmjs side? |
Beta Was this translation helpful? Give feedback.
-
|
I'm having the same problem as @tmadeira |
Beta Was this translation helpful? Give feedback.
-
|
All my tokens have been revoked, including the granular one, and now i cannot recreate any new token in the UI it fail for no reason, in the CLI it refuse to accept --package-all for one org. This is the worst move you ever made. |
Beta Was this translation helpful? Give feedback.
-
|
previously, the npm token list --json would show granular tokens using bypass2fa checked in the json with the field "automation: true", the same field that classic automation tokens had. But since yesterday they are in json with "bypass_2fa": true This change completely broke my release action I need to change my code to publish new releases :( I didn't see any notice warning that this API was changing, it's very painful to change code that is responsible for security checks, and also which is painful to setup in a reproduction environment. Or maybe I just missed the notice ? Maybe a v2 api would have been better. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I am trying to make a release from my dev environment. I login with npm login, I have 2FA. |
Beta Was this translation helpful? Give feedback.
-
|
This migration has felt pretty rough for maintainers with many packages. Neither suggested path works well: OIDC trusted publishing:
Both these issues were raised months ago but remain unresolved. I've heard it's on the roadmap, but I think before forcing a breaking migration they should have been resolved so that there was a good path forward. 90-day granular tokens: (This can at least be scripted with the GitHub API, but it's still a lot of work and complexity for maintainers.) Exacerbating this is the chaotic rollout:
It'd be great if NPM could add support for publishing new packages with OIDC, and solve the setup issues (e.g. allowing a broader OIDC configuration that doesn't need to be custom for every package). |
Beta Was this translation helpful? Give feedback.
-
|
The tokens created by The only way I can install private packages right now is creating a token in the web UI with the “Bypass 2FA” checkmark checked, and putting that token in ~/.envrc. Seems like NPM is applying publish permissions to package GET operations. |
Beta Was this translation helpful? Give feedback.
-
|
We have read-only as well as read/write granular access tokens and when trying to install private packages in CI/CD workflows, we got the same message a few others have posted starting yesterday: Based off several comments above, specifically this one, I ended up making a new read-only token (via the web UI) that had bypass 2FA enabled and that ended up working. What stood out in that particular comment was:
When we originally setup the new granular access tokens, we only applied the bypass 2FA option on the write token, however, it appears that as of yesterday, the read-only token also needs that option set for automated workflows. It's a bit confusing from the docs as several spots mention optionally bypassing it for tokens with write access (see item 5 here or the last paragraph here and the CI section here), so is the expectation that automated workflows that use a write token only (since not all of our workflows need publish abilities) will need to have a write token that bypasses 2FA? |
Beta Was this translation helpful? Give feedback.
-
|
The local publish process need improvement. Since all my packages is already enabled the 2FA, currently publish a package should typing OTP twice. Once for |
Beta Was this translation helpful? Give feedback.
-
|
Would it be possible to extend a token duration? Because a 2-hour session token is a real PITA when working with a lot of repositories. We went from lifetime duration down to just 2 hours. I do not need to publish, I just want to be able to |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
Quick update on our npm security timeline: We're moving the classic token removal from November 19 to December 9, 2025.
Why the change? We're bundling this breaking change with a highly-requested feature that will make the transition smoother. On December 9, we're shipping CLI support for managing granular access tokens directly from your terminal, in addition to classic token removal.
What's coming December 9
Classic tokens will be permanently revoked, with all remaining npm classic tokens stopping work. Going forward, login sessions will use 2-hour tokens requiring periodic re-authentication. Learn more about the token changes in our security strengthening post.
CLI token management for granular tokens is finally arriving. You'll be able to create, list, and revoke granular access tokens from your terminal with a similar experience to the classic
npm tokencommand, adapted for granular tokens now with enforced 2fa. No more web-only token management! Check out the documentation on granular access tokens to prepare.We're also making packages secure-by-default, with 2FA enforcement becoming the default option for all new packages. This means better security out of the box without manual configuration. Learn about 2FA for publishing on npm if you haven't set it up yet.
Good news for Yarn users: The
/user/org.couchdb.user:usernameAPI endpoint has been restored, so Yarn v1 and v2 authentication workflows will continue working. This fix is already live.What this means for you
By delivering these features together, you'll have the tools you need right when you need them. Instead of losing classic tokens and having to navigate the website for replacements, you can manage granular tokens directly from your familiar CLI workflow.
No action needed until December 9. Your existing classic tokens continue working until then.
Stay informed
Review our previous update about classic token creation being disabled (Nov 5) and the original security roadmap announcement. You can start creating granular access tokens now if you want to get ahead of the change.
We'll share more details as we approach December 9. Thank you for your patience as we strengthen npm's security foundation while keeping your experience as smooth as possible.
Questions or concerns? Let us know below.
Update: December 9, 2025 - Changes are now live
The December 9 security changes are now in effect.
**npm classic tokens are permanently revoked. ** All npm classic tokens have stopped working and cannot be recovered or recreated.
**npm session tokens replace long-lived auth. ** When you run
npm login, you now receive an npm session token that expires after 2 hours. These tokens don't appear in your token list - they work behind the scenes. You'll need to re-authenticate periodically for local development.New CLI for npm granular access token management. You can now create, list, and revoke npm granular access tokens directly from your terminal. See the npm CLI documentation for details.
Secure-by-default 2FA for new packages. Starting today, 2FA enforcement is the default option for all new npm packages. Existing packages retain their current settings.
What you need to do now
If you were using npm classic tokens:
For local development: Run
npm loginto get a 2-hour npm session token.For CI/CD: Create npm granular access tokens via CLI or at npmjs.com/settings/~/tokens.
For best security: Use OIDC trusted publishing (GitHub Actions, GitLab CI).
Read the full changelog: npm classic tokens revoked; session-based auth and CLI token management now available
Questions? Drop them below.
Beta Was this translation helpful? Give feedback.
All reactions