Update: Classic token removal moves to December 9, bundled with new CLI improvements

[leobalter]

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 token command, 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:username API 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 login to 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.

[ckohen]

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

[leobalter]

They won't. We are actively working on enabling an expanded established trust experience but these will take a bit more time and I expect them for the next couple months.

[m-amin-b]

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.
Quick update based on the latest from npm (as of Nov 13, 2025):

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.
Established Trust / Trusted Publishing: No, the broader rollout won’t make it before Nov 19. The team is actively working on expanding support (self-hosted runners, more CI platforms, etc.), but it’s expected in the next couple of months — likely early 2026.

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.
→ Docs: https://docs.npmjs.com/trusted-publishing
→ GitHub example: https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/
For other CI systems → use short-lived granular tokens (7-day default, max 90 days) with Bypass 2FA enabled for automation.
→ The new CLI (npm token create --help) will let you generate/rotate them easily.
→ Pro tip: script token rotation in your CI (e.g., generate on startup, store in memory or encrypted env).
Feedback matters — npm is listening. Share your CI provider and pain points in the main discussion:
→ https://github.com/orgs/community/discussions/176828

If you drop your CI setup (Jenkins? CircleCI? Azure?), I can help draft a migration script or workflow.
Let’s make the ecosystem safer — together! 🙌

[tmccombs]

For other CI systems → use short-lived granular tokens (7-day default, max 90 days) with Bypass 2FA enabled for automation.

Pro tip: script token rotation in your CI (e.g., generate on startup, store in memory or encrypted env).

But what credentials would the CI use to generate this token?

[mary-ext]

no answers on how said token should be regenerated?

[jferg-workwave]

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. Established Trust / Trusted Publishing: No, the broader rollout won’t make it before Nov 19. The team is actively working on expanding support (self-hosted runners, more CI platforms, etc.), but it’s expected in the next couple of months — likely early 2026.

Argh - why does the website still say Dec 9?! I have users complaining their tokens were disabled yesterday.

[meeech]

hey @m-amin-b how do we make this token " For other CI systems → use short-lived granular tokens (7-day default, max 90 days) with Bypass 2FA enabled for automation." via the cli? It's not clear how to make a token with the bypass with this command (i looked at the help)

[jsumners-nr]

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.

[leobalter]

it's unfortunate I can't find a better way to prioritize the most recent announcements within the same thread. I don't expect to have a long series of threads anymore. Our releases continue but now in a slightly more spaced cadence.

[istian-chris]

login sessions will use 2-hour token will this be around when these security changes are complete?

[leobalter]

yes, and it's open for further improvements if needed.

[jferg-workwave]

If the date was moved to 2025-12-09, why do I have users complaining that their tokens were disabled yesterday?!

[leobalter]

We've had no changes applied this week. They might wanna reach out to support.

[jferg-workwave]

That's really strange, I have 4 different users who opened internal tickets yesterday because their classic tokens stopped working (but plenty who didn't complain either), but looking today, I can see that their tokens still exist in the admin side and appear to be active. I've issued new granular tokens for them to use at this time, so it's a non-issue at this time, and I'm working on moving us to CodeArtifact internally anyway, so shouldn't be an issue, but really seems like a strange coincidence that all these users had issues yesterday/this morning.

[istian-chris]

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?
Can we expect mandatory 2FA for local publishing in 2026?

[Tobbe]

I just got this email

Hi tobbe,

Your npm account has classic tokens that will stop working on December 9th, 2025.

What's happening:
• November 5th: Classic token creation was disabled
• December 9th: All classic tokens will be permanently revoked

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.
And some info on how to figure out where those tokens are used, so I know if I need to care or not.

[stevus]

yea, tbh I'm surprised this wasn't done prior to the announcement.

I'm 100% confused what I have to do

[tmccombs]

tl;dr; as I understand it:

If you use npm from the command line, you'll need to update to the latest version of npm that is apparently getting released at the same time these changes go out ( 🤔 ) and authenticing with the CLI will require 2fa, and you will have to re-authnticate more often.

If you use a token on Github or Gitlab CI, you will need to switch to using the "trusted publishing" that uses oauth to get a temporary token.

If you use it in some other kind of CI, they claim they will have some better solution in the future, but it isn't clear what that is currently, and for now you will probably need to switch to "granular" tokens, and rotate them every 90 days.

[stevus]

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
Publish
Read-Only
which of those do I need to update?

[tmccombs]

It was also asked in one of the other discussions (why are there so many of these), but "classic" is anything that isn't granular.

[eddielee394]

Has there been an updated release yet for CLI management of granular tokens?

[leobalter]

December 9 Update: All npm classic tokens are now revoked

Hi 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. npm login now gives you a 2-hour session instead of a long-lived token. More secure, but you'll re-authenticate more often.

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 now

Local dev: Run npm login to get a new npm session token.

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.

[gg-martins091]

Either I dont know what a classic token is, or this is not yet fully effective.

I'm testing our CI/CD pipelines and everything is running just fine without any changes. I really don't see the token we are using listed anymore at https://www.npmjs.com/settings/~/tokens, but it somehow still works.

Am I missing something?

[jedwards1211]

@leobalter installing our own private packages after npm login seems to be broken now. And we'd have to login every two hours just to install our own private packages on our own machine? You really don't want us to enjoy working with npm, do you?

[adeelasghar1001]

Yeah I'm still able to publish package updates to our npm package on github.

[gabor-at-reed]

Do you have any updates on Azure DevOps as an OIDC trusted publisher?

[tmadeira]

Both short-lived tokens (created via npm login) and granular tokens (created via npmjs.com) are not working to publish new versions of packages in my organization.

$ node -v
v24.11.1
$ npm -v
11.6.2
$ npm login
(login is successful)
$ npm whoami
(shows my username)
$ npm token
(shows all the tokens I see in npmjs.com)
$ npm publish
(...)
npm notice Publishing to https://registry.npmjs.org/ with tag latest and default access
npm notice Access token expired or revoked. Please try logging in again.
npm error code E404
npm error 404 Not Found - PUT https://registry.npmjs.org/@org%2fpackage-name - Not found
npm error 404
npm error 404  The requested resource '@org/[email protected]' could not be found or you do not have permission to access it.
(...)
$ echo "//registry.npmjs.org/:_authToken=<valid-granular-token-i-just-created>" > ~/.npmrc
$ npm publish
(...)
npm notice Publishing to https://registry.npmjs.org/ with tag latest and default access
Authenticate your account at:
https://www.npmjs.com/auth/cli/<uuid-generated-by-npm>
Press ENTER to open in the browser... (<enter> and successful login on the browser)

npm notice Access token expired or revoked. Please try logging in again.
npm error code E404
npm error 404 Not Found - PUT https://registry.npmjs.org/@org%2fpackage-name - Not found
npm error 404
npm error 404  The requested resource '@org/[email protected]' could not be found or you do not have permission to access it.
(...)

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?

[jedwards1211]

Not even letting us install our own private packages. This and npm login expires after two hours and requires MFA? Fuck's sake npm team, does it really need to be this tedious by default? I'm just going to manually create an access token that can read everything and put it in my .npmrc...but I shouldn't have to!!

[Emilios1995]

Same here. I just added a top level reply to this discussion.

[williamcotton]

I'm also experiencing this issue. I can successfully use npm login (at least apparently, with the whole 2FA process) but this is the result:

$ npm login
npm notice Log in on https://registry.npmjs.org/
npm notice Security Notice: Classic tokens have been revoked. Granular tokens are now limited to 90 days and require 2FA by default. Update your CI/CD workflows to avoid disruption. Learn more https://gh.io/all-npm-classic-tokens-revoked
Login at:
https://www.npmjs.com/login?next=/login/cli/11111111-2222-3333-4444-555555555555
Press ENTER to open in the browser...
Logged in on https://registry.npmjs.org/.
$ npm publish              

> @example/[email protected] prepack
> npm run build


> @example/[email protected] build
> tsup

CLI Building entry: src/index.ts
CLI Using tsconfig: tsconfig.json
CLI tsup v8.5.1
CLI Using tsup config: /Users/john.doe/Projects/acme/example-lib/tsup.config.ts
CLI Target: es2020
CLI Cleaning output folder
CJS Build start
ESM Build start
ESM dist/index.mjs 58.35 KB
ESM ⚡️ Build success in 20ms
CJS dist/index.cjs 60.46 KB
CJS ⚡️ Build success in 20ms
DTS Build start
DTS ⚡️ Build success in 512ms
DTS dist/index.d.cts 8.45 KB
DTS dist/index.d.ts  8.45 KB
npm notice
npm notice 📦  @example/[email protected]
npm notice Tarball Contents
npm notice 61.9kB dist/index.cjs
npm notice 8.7kB dist/index.d.cts
npm notice 8.7kB dist/index.d.ts
npm notice 59.8kB dist/index.mjs
npm notice 833B package.json
npm notice Tarball Details
npm notice name: @example/example-lib
npm notice version: 1.2.3
npm notice filename: example-lib-1.2.3.tgz
npm notice package size: 24.7 kB
npm notice unpacked size: 139.8 kB
npm notice shasum: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
npm notice integrity: sha512-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
npm notice total files: 5
npm notice
npm notice Publishing to https://registry.npmjs.org/ with tag latest and default access
npm error code E403
npm error 403 403 Forbidden - PUT https://registry.npmjs.org/example-lib - Two-factor authentication or granular access token with bypass 2fa enabled is required to publish packages.
npm error 403 In most cases, you or one of your dependencies are requesting
npm error 403 a package version that is forbidden by your security policy, or
npm error 403 on a server you do not have access to.
npm error A complete log of this run can be found in: /Users/john.doe/.npm/_logs/2025-12-10T22_38_06_168Z-debug-0.log

[Tobbe]

I'm having the same problem as @tmadeira
CI publishing using this token is failing

[arthursacurai3]

same here

[tmadeira]

Please let me know if you find any workaround. I'm trying up-to-date granular tokens with the correct scope and at the moment I'm unable to publish new versions of any package in my organization.

I filed a ticket to npm support, and will also update this thread if there is a solution.

[riderx]

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.

npm token create --name github --bypass-2fa --expires 90 --orgs capgo --packages-and-scopes-permission read-write --packages-all
npm error code E400
npm error 400 Bad Request - POST https://registry.npmjs.org/-/npm/v1/tokens - You must select at least one package or scope if granting package/scopes permissions to this token.

This is the worst move you ever made.
Nothing was ready, we cannot connect one org to trusted publisher, legit token got revoked this is pure joke

[monkbroc]

The blog post and docs should include examples of token creation using the npm CLI. Right now all we have are a bunch of flags and it's not clear what combination of flags is required for the npm token create command to succeed.

[jonenst]

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.

[fgatti675]

Hi, I am trying to make a release from my dev environment. I login with npm login, I have 2FA.
When I publish I get:
This operation requires a one-time password:
I was never given that password, either in the mail or in the login flow

[domdomegg]

This migration has felt pretty rough for maintainers with many packages. Neither suggested path works well:

OIDC trusted publishing:

• You can't publish new packages with OIDC - the first publish must use a token (npm/cli#8544 and discussion #161015
• There's no API to configure it programmatically - you have to click through the npm website for each package (discussion #161015)

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:
Personal GitHub accounts don't have org-level secrets, so you'd need to rotate tokens in every repo individually. So not only are you forced to refresh the token every 90 days, you might then need to update dozens or hundreds of repos each time.

(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:

• Several policy changes in quick succession
• CLI token management shipped on the same day tokens were revoked (Dec 9), giving zero migration window. Plus this shipped with out of date documentation - e.g. the tokens docs still say "You cannot create granular access tokens from the CLI currently"

---

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).

[domdomegg]

Also for others in the same boat as me: https://github.com/domdomegg/gcp-github-secrets

This stores secrets in GCP Secret Manager, so you can store your NPM token in one place and update that, without having to update all your ~hundreds of repos. Workflows authenticate via OIDC to GCP (no static secrets in GitHub), but without the OIDC pain of NPM's approach.

[Emilios1995]

The tokens created by npm login are not allowing me to install private packages (inside an org) locally. (Fetching them fails with a 403.)

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.

[jedwards1211]

I'd be cool with having to log in frequently to publish...but having to log in every two hours just to install private packages (if npm login even worked for that anymore) is ridiculous

[ripley-at-cascade]

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:

Two-factor authentication or granular access token with bypass 2fa enabled is required to publish packages
In most cases, you or one of your dependencies are requesting a package version that is forbidden by 
your security policy, or on a server you do not have access to.

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:

Seems like NPM is applying publish permissions to package GET operations.

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?

[zombieJ]

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 npm login and another for the npm publish.

[paul90]

Yes, would be nice at this point if local publish even worked. I know a number of people with the same problem as reported in https://github.com/orgs/community/discussions/179562#discussioncomment-15224807

While npm login will do the browser dance, npm publish does not. Without callout to the browser how is a webauthn 2fa meant to work - there is nothing in any of the npm documentation!

[marijnh]

Yes, this is driving me up the wall. I publish packages a lot, and I am now forced to go through the 2-factor auth twice for that every time, first to login, then to publish. This does not increase security. It is just terrible UX.

[GuillaumeNury]

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 npm install with private dependencies 🙏