Revised npm Security Timeline Based on Your Feedback

[leobalter]

Hello npm community! 👋

Thank you for your patience and valuable feedback on our security changes. We've been listening carefully to your concerns, and I'm excited to share that we've adjusted our timeline to better support your workflows while maintaining our security improvements.

What We've Heard From You

Your feedback has been invaluable in helping us understand the real-world impact of these changes. Based on your input, we're making the rollout more gradual and providing better migration paths before implementing breaking changes.

Updated Timeline

📅 November 5, 2025

• Classic tokens: New classic tokens can no longer be created (existing ones continue working)
• Granular tokens: New write tokens will enforce 2FA by default, with an optional bypass setting for backward compatibility
• Token lifetimes: All existing granular write tokens will be capped at 90-day maximum lifetime
  • Any token currently set to expire after February 3, 2026 will have its expiration adjusted to that date (90 days from November 5)

📅 November 19, 2025

• Classic token sunset: All existing classic tokens will be permanently revoked
• Local publishing: New 2-hour session tokens will replace the old long-lived tokens for local publishing

What's Coming Next (Before Additional Breaking Changes)

We're committed to providing robust alternatives before making further breaking changes. Here's what we're working on:

Near-term improvements:

• CLI parity: Full npm token command support for granular tokens (list, add, delete)
• 2FA for publishing: Required for all local/manual publishing
• "Established Trust with OIDC": New registry API endpoints and npm CLI support for faster bulk management (especially helpful for maintainers with 10+ packages)

Looking ahead:

We're evolving from "trusted publishing" to "Established Trust" - a broader initiative that should include:

• Support for dist-tag and features beyond just publishing
• Expanded OIDC provider support, including GitHub Enterprise Server and self-hosted runners
• Multiple workflow support
• Namespace-wide configurations for account and org scopes
• Proof of presence (2FA) during publishing with GitHub Actions

Important: We will NOT proceed with removing existing TOTP configurations or further shortening token lifetimes until these enablement features are in place.

What Hasn't Changed

The security improvements from October 13 remain in effect:

• New granular tokens: 7-day default, 90-day maximum lifetime
• TOTP 2FA: Cannot add new or reconfigure existing setups (existing TOTP still works)

We're Here to Help

Your feedback has directly shaped these changes, and we'll continue to iterate based on your needs. If you're attending GitHub Universe, I'll be there in person and would love to discuss these changes or answer any questions you might have.

For those who can't make it to Universe, please continue sharing your thoughts here. Every piece of feedback helps us build a more secure npm that works for everyone.

Other resources

• Original changelog from September 29
• Initial community discussion: Our plan for a more secure npm supply chain
• October 13 changes announcement
• npm security update: Classic token creation disabled and granular token changes

Thank you for being part of this journey. Together, we're making npm more secure while ensuring it remains the tool you rely on every day.

- The npm Team

[nickdnk]

Token lifetimes: All existing granular write tokens will be capped at 90-day maximum lifetime.

Still unacceptable and meaningless security theater. You are wasting people's time, not improving security.

Edit: If not, I'd like to hear why. In what scenario do you believe a 90 a day lifetime window actually helps?

If the token leaks from a secure CI flow, it's going to be used within 90 days anyway - most likely.
It doesn't prevent newly created tokens via stolen NPM credentials (phishing or whatever) from being used immediately.

What it does is create an avenue where you can cock up the renewal and leak the rotated token that way, since it's going to be a manual process involving a (potentially) compromised machine. It's never going to just randomly leak from a secure store and then not be used immediately.

The only situation I see where it could potentially have an impact is if a package has not been updated in more than 90 days, and that package author somehow has their CI flow compromised (irrelevant how in this example), then yes, that loss of control would not cause a rogue CI flow to deploy a new version. Is that the idea here? If so, it seems like a bit of an overreaction with regard to risk vs. manual intervention required during normal operations. And usually, this should be solved at the CI level, with things like MFA. I know that that of course is outside npm's control, but if people are being reckless, they can easily be reckless within 90 days too.

[jakebailey]

My understanding is that "local" means npm login. But "2FA for publishing: Required for all local/manual publishing" mentions "manual". What does "manual" mean?

Does this still only mean "via a token from npm login" (which I understand to be special, or, at least going to be special not unlike gh login)?

Or does this imply something about publishing via a token (classic/granular/etc)?

(I ask because there are situations where any sort of proof-of-presense is infeasible, like DefinitelyTyped, nightly builds, etc, so requring that will be a major break and/or make these projects impossible.)

[sokcuri]

I am very worried about the 90-day limit. The more often we have to log in, the higher the likelihood that tokens are leaked somewhere else. I think it would be better to enforce 2FA and allow extensions to token lifetimes. I hope this policy is withdrawn as soon as possible.

From a security perspective, if a GitHub token or other credentials are leaked and a workflow runs and publishes, there is no effective defense. Rather than blocking everything and making things inconvenient, it’s important to make the policy flexible in a way that buys time to respond.

[christianemanuelson]

Thanks for the update!
Local publishing: New 2-hour session tokens will replace the old long-lived tokens for local publishing
Does this mean no more bypassing 2fa with granular tokens on Nov. 19th?
Is this the publish token you generate from the npm login command?
If that is the case it sounds like we should be able to use npm login with 2FA disabled until 2FA is required for local publishing.

[3nprob]

What Hasn't Changed

TOTP 2FA: Cannot add new or reconfigure existing setups

I don't believe this is an appropriate response to the community feedback in https://github.com/orgs/community/discussions/174505. Please reconsider.

Besides of the main issue, what behavior do you think this incentivizes for maintainers relying on an existing TOTP-based publishing flow? They'll be likely to hold on to it as long as they can. Preventing them from rotating their TOTP secrets is just baffling from a security perspective.

It also (as can be seen in the linked feedback thread) disincentivizes some maintainers from publishing at all. This only hurts the community and will likely increase the amount of security issues and forking/migration churn stemming from neglected/abandoned packages a la request if the decision is not reversed.

[sashahilton00]

Can you stop doing damage mitigation for a climbdown from a frankly embarrassing stance? Your original plans were not well thought out or grounded in reality.

TOTP 2FA: Cannot add new or reconfigure existing setups (existing TOTP still works)

Show me a single piece of evidence based research that suggests passkeys are better than TOTP for reducing/mitigating attack surface. Until then these changes are smoke and mirrors.

It's at times like these I'm glad I don't work for a large org where politics take priority over technical fundamentals.

[ckcr4lyf]

TOTP 2FA: Cannot add new or reconfigure existing setups (existing TOTP still works)

Clown behavior from micro$oft. Maybe listen to your plethora of users with a vast & varied OSS (including from a security, privacy and freedom - the point of OSS) background who don't want vendor lock in and commercialization of authorization into a website.

Can't wait for the when users are invariably locked out because their proprietary, big-tech controlled passkey app or whatever doesnt work (broken device or lost account etc.) and now they are unable to log in, because the passkeys are stored in the proprietary locked in vault (locked in meaning anti-consumer here; not security), and can't do anything because there's no number to contact github.

[wesleytodd]

Proof of presence (2FA) during publishing with GitHub Actions

I would like to confirm that this line item is does not require an integration to GHA, but can be done entirely with the web flow in the CLI just like it works for local publish. Print the webauthn url and wait for the user to take the proper MFA actions. @reggi and I discussed in person at JS Conf, and I believe they are fully able to represent my ask for this in the technical design discussion. Happy to be pulled in on it, but @saquibkhan asked that I post here with this detail.

[tmccombs]

I'm still unclear on what the migration path is for custom/self-hosted CI/CD. For example, if I want to publish an NPM package from my self-hosted Jenkins cluster, how do I get the necessary credentials? It isn't feasible to manually rotate the secret every 90 days, much less every 7 days.

Expanded OIDC provider support, including GitHub Enterprise Server and self-hosted runners

That is still only for Github customers. What about NPM users that use other CI/CD systems. Or even Github customers who use a CI/CD system other than Github actions?

[pnacht]

Yeah, that's my concern as well. Especially the

2FA for publishing: Required for all local/manual publishing

How will it distinguish between non-GH CI/CD and someone publishing from their laptop? Will it no longer be possible to publish to NPM from non-GH CI/CD providers?

[meeech]

As someone who works for one of those other CI/CD systems, all I can say right now is we're trying to work with NPM to get our system added to the trusted publishers.

[mikgross]

As someone who works for one of those other CI/CD systems, all I can say right now is we're trying to work with NPM to get our system added to the trusted publishers.

Mad that you have to become a trusted publisher. What is this an enterprise grade system? Are we going to get locked into an npm ecosystem?

[wesleytodd]

One clarifying question: Are calls to deprecate packages included in the "Support for dist-tag and features beyond just publishing" item?

cc @jsumners-nr @lukekarrys

[jsumners-nr]

We have a team that utilizes a GHA cron task to query an API for the list of still supported packages and issues an npm deprecate on the ones that have aged out. This is no longer possible with the OIDC workflow (not without going back to managing secrets).

[AlttiRi]

It is absolutely unhealthy behavior to force people to use passkeys.
Passkeys must not be mandatory. TOTP 2FA must not be deprecated.

[sashahilton00]

They have no interest in listening to reason. There has been nothing from NPM/Microsoft justifying the change, in terms of backing up their claims about it being more secure.

It's no coincidence that the vendors of the top three operating systems and browsers are pushing for an authentication mechanism that requires tie in from both the browser and the OS. It's simply a power grab designed to lock in their position.

Once passkeys have been forced upon everyone, suddenly services such as banks and government services will start validating the attestation data against the vendor keys, and before you look around you'll have to have a device configuration blessed by the manufacturer, or only some subset of functionality will be available.

This nonsense has happened with Widevine on mobile devices with L1 through L3, with Google Safetynet/PlayProtect, jailbreak detection/AppAttest on iOS, TPM 2.0/Device Health Attestation/PlayReady/etc. on Windows - invariably it becomes a certification pay to play racket where only the big boys can keep up.

Until attestation is dumped from the spec, I will simply stop using any service that only offers passkey authentication for full functionality.

[JoshuaKGoldberg]

This is still very, very soon. I want to adhere to the new and more strict guidelines but updating dozens+ of repos takes a lot of time. Project planning at that scale is measured in months, not weeks. There is no way I will be able to update my packages on even this updated schedule.

[wesleytodd]

The Node.js Security WG, in partnership with Express, OpenJS Security WG (lots of overlap in the humans in these groups 😄, so it's really only a few of us), and other contributors are putting together some guidance in a blog post, but as part of that we want to continue to push this point home. It is not that we think the direction we are taking is bad, it is that we need more time to move the whole ecosystem/community. And part of that time is also to help ensure what we are moving folks onto is ready for that move. If you are interested in helping with putting that message together please reach out to me on the OpenJS Slack and I can loop you in with the folks working on that.

[mecodeatlas]

Hey everyone 👋

Just a quick note that a new changelog was published yesterday (November 5) with the latest details on the npm security rollout. It confirms that new classic tokens can no longer be created, granular tokens with write access now require 2FA by default (with an optional bypass for CI/CD), and all granular tokens are capped at a 90-day lifetime.

These updates apply only to npm tokens - GitHub tokens aren’t affected. You can read the full post for context and migration steps.

[wesleytodd]

We are pretty sure we have a report of a token that should have expired after Feb 3 being expired today. Can someone take a look to be sure the following was implemented correctly?

> Any token currently set to expire after February 3, 2026 will have its expiration adjusted to that date (90 days from November 5)

I was hoping to have a clear bug report, but our support engineer had rotated the token already and only reported it to me because when they thought they had set the new one to expire in 90 days, it is listed as expiring in 7.

So this is at least one concrete bug report: creating a new GAT with an expiration set to 90 days is instead issued with a 7 day expiration.

EDIT: Confirmed this morning with our support on-call that this is what happened. They had selected a date like we used to, and didn't notice that it reverted back to 7 days before saving.

[nickdnk]

Hey everyone 👋

Just a quick note that a new changelog was published yesterday (November 5) with the latest details on the npm security rollout. It confirms that new classic tokens can no longer be created, granular tokens with write access now require 2FA by default (with an optional bypass for CI/CD), and all granular tokens are capped at a 90-day lifetime.

These updates apply only to npm tokens - GitHub tokens aren’t affected. You can read the full post for context and migration steps.

How do you suggest we implement safe and secure token rotation every 90 days without manual intervention? This is so stupid and unnecessary. You have also completely ignored all comments about this. What problem do you think this solves?

[tmccombs]

What problem do you think this solves?

In fact, requiring these tokens every 90 days is going to introduce new problems, like giving more people access to the credentials, or people giving their CI systems access to the MFA keys, so they can automate the rotation.

[wesleytodd]

It looks like the bug I reported (above in reply to @mecodeatlas's comment) was fixed mis-identified, but when I went to create a token just now I noticed that if you select a date further out than 90 days via the "custom" selector it does not display an error and just goes back to 7 days. Ideally this would display a warning/error message so that users notice what they selected did not take effect, but also instead of going back to 7 days it should go to 90 days since the user intent was clearly to set a longer expiry.

[jsumners-nr]

That's just a poor UI oversight to chose the wrong end of the lifetime window in this case. It helps no one.

[dangershin]

Is a 90-day maximum lifetime for tokens really being enforced without providing support for auto token generation/rotation? This seems premature and not well thought out. It adds manual steps and creates more risk than it mitigates.

[BlackGlory]

This is a great initiative; now we finally have a reason to migrate to JSR.

[mitra42]

I can't figure this out, and I bet I'm not the only one - I have the simplest case, publishing packages from my laptop. Currently via CLI npm publish which asks me for 2FA, and works just fine. If I login to NPM it tells me I have a token I just used (to login I presume), its unclear if I need to change that token.

If I try and create a granular token then that expires in 90 days, but if I miss that window, how will I login to create a new one ?

All I can find online refers to arguably much more complex cases, and I can't figure out how this applies to this, probably the simplest, of cases of wanting to publish from my laptop.

[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]

Publish and Read-Only are both "classic". Only Granular tokens are supported now.

[stevus]

@tmccombs Thanks!

[sashahilton00]

I cannot remember a more botched rollout than this current set of npm changes. Astonishing that Microsoft with all it's resources is incapable of clear and concise communication, coupled with well thought out changes.

1. Shai Hulud happens.
2. random screechings inside npm occur - a bunch of hashed together changes proposed and rushed out, breaking a bunch of workflows.
3. Shai Hulud 2.0 happens, which none of the proposed changes would have stopped anyway.
4. npm doggedly sticks to their flawed 'security' proposals/upgrades/features/whatever, including 2FA/TOTP still removed because 'reasons'.
5. The deadline of the 9th approaches, no one has a clue what is going on.

Meanwhile at pnpm: minimumReleaseAge

Great job team 👏 👏

[Trott]

Astonishing that Microsoft with all it's resources is incapable of clear and concise communication, coupled with well thought out changes.

Microsoft loses a ton of money on npm. There is no motivation for them to put the marketing and communications resources that they have for other products into npm. This is especially true given the external perception of npm as a separate entity from Microsoft (which is a perception that is also probably correct in important ways--Microsoft owns GitHub, and GitHub owns npm, but it seems very likely that, even internally, Microsoft largely treats npm as if it were a separate company).

It's unrealistic to expect another entity to put in the resources to run something like the registry, so your non-exclusive options are:

1. Become a paying customer. (Ha ha! Kidding! Nobody seems willing to do that.)
2. Make peace with using a different and vastly smaller registry. (Good luck!)
3. Treat npm support as you would support of an open source project. (FWIW, the npm client code is in fact open source.) Gather up in a forum like this one, trade information, try to figure stuff out, be supportive, and stop shitting all over the people doing the work.

Of those options, 3 is the only one that will actually work to get anyone anywhere with this and other issues. Does that fact say something bad about Microsoft and/or npm? Maybe. Maybe not. I don't know. But if you want things to be better, 3 is really your only option.

[Trott]

(I should add that I agree that the communication on this topic has been confusing and incomplete. We can all choose to respond to that in helpful or unhelpful ways.)

[jsumners-nr]

You're correct, @Trott, but so is @sashahilton00. My personal opinion is that there is a lot of theater going on here. Without actual mitigations in place (2fa (totp) in CI and/or staged publishing), none of the proposed changes will prevent the attacks they are advertised to alleviate. The only tangible effect they will have is to annoy publishers, add a LOT of work to their already over-full plate, and force them into "solutions" that solve nothing.

@wesleytodd has described all this in much more detail across the various places.

[sashahilton00]

@Trott generally I agree with what you've said. Normally I wouldn't voice my disdain with an org making changes as I have here. With regards to option 3, that is how I would choose to treat it. There is a perfect case illustrating this, where minio recently gutted the OSS project, rebranded as AIStor, and went closed source. This has caused a bigger headache than these npm changes for me. The difference is, I can just pin to a previously released version of the project, use that, and the upstream shenanigans don't impact me.

The npm registry is different - I can't just pin the release where 2FA was fully supported, passkeys weren't being pushed, all the different types of tokens that are poorly documented didn't exist, etc. If there had been a clear rationale, roadmap, rollout plan and so on for these changes, I'd have been more understanding. As it stands what we have is:

1. Security theater - removing TOTP support, adding different types of tokens, trusted publishers, etc. doesn't fix the issues these changes are being pushed as fixing - Shai Hulud 2.0 originated on a trusted CI system at a major company, and would have spread via trusted publishing just the same.
2. Fake community engagement - 'we've listened to your feedback', when they've consistently refused to acknowledge any of the pushback, questions raised or provide rationale for their decisions. Once again using TOTP as the example, there has been zero evidence provided that removing it actually makes anything more secure. More generally the npm maintainers clearly don't give a damn about any views expressed here that run counter to their own agendas.
3. Terrible communication/no proper timeline. Think this has been covered enough, but given no dev can choose to pin a previous version of the registry and ignore the changes, this should have been absolutely non-negotiable when discussing it internally. This thread and others like it are filled with people trying to work out what the new tokens do and how trusted publishing is supposed to work, and the deadline is tomorrow. It's a mess.
4. Microsoft/Github/npm governance - sadly there's a track record of enshittification at Microsoft, which spilled over into Github after the acquisition (authwall code search, aggressive rate limiting, broken web UI, etc.), and with Microsoft's push to make everyone use passkeys, call me a cynic but this change where magically only vendor approved CI pipelines or otherwise using the vendor backed auth that they've been pushing allows a normal-ish workflow to continue feels just as much about building walled gardens as any supposed security. I have close to zero trust in Microsoft as a company to have the interests of developers/users as a priority. I'd rather speak up and voice objections now than sit silently and watch the maintainers trash npm further and further with no pushback - anyone that does that has no grounds to complain further on down the line if they didn't flag their concerns when given the opportunity.

[ExtAnimal]

How depressing. Things changing all the time when you have forgotten what it was all about.

What is this? How does it affect me? What do I have to do?

[ExtAnimal]

"Migrate to trusted publishing or granular access tokens before December 9th to avoid disruption."

HAHAHAH!

WHAT?

Just like that?

|I do not even know what that string of letters MEANS

[jalarrea]

URGENT: We need immediate escalation for Ticket ID 3943185.
We lost our NPM account access it is a hard blocker for this critical migration that must start now. As workload of Black Friday is finished We require this ticket resolved ASAP to unblock the migration of the Classic tokens.

[vemonet]

Hello @leobalter I don't think you have thought this through. Please try to go through the proposed workflow. Your security/CI engineers should propose a decent solution to help users manage this changes in a responsible way

Your press release on github blog says we can use npm create token to create a token. Ok let's try.

npm token create

npm password: 
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
npm error code E401
npm error Unable to authenticate, your authentication token seems to be invalid.
npm error To correct this please try logging in again with:
npm error   npm login

Ok so let's run npm login

Getting 2FA > We are now logged in

Let's run npm token create

Getting asked my npm password + 2FA again

• Why do you even need my password now? When I do npm publish for other projects I am not getting my password asked, just 2FA (which I am fine with, I understand the implications of supply chain attack)
• Why do you need again 2FA twice?

Anyway, getting error npm error 400 Bad Request - POST https://registry.npmjs.org/-/npm/v1/tokens - Token name is required

So now going through the documentation of npm help create, and figuring out that is how I can generate this for my package:

npm token create --name publishci --expires 90 --packages @my/package --password $MYPASSWORDINCLEAR

Notice how you are pushing us to add our npm password in clear in our environment to avoid having to memorize and type it everytime (because anyway we'll go through 2FA, and we have already ran npm login so this password ask is really not necessary)

What you should have done is proposed a simple npm create token + gh secret set pipe 🤯 or just integrate this in the gh CLI directly

Unfortunately if I try to pipe the npm command or put it inside a script that breaks the 2FA call (which is weird because I don't have this behavior with the 2FA call from npm publish... But at this point I am not really surprised).

So the only option now is moving the npm publish step out of CI and in local environment, which is a pain for a build that targets multiple architectures, which is often done in CI.

We can start feeling the impact of microsoft being now owner of github and npm...

Please try yourself setting up publishing workflows through this madness, and share with us the best practices.

[loveencounterflow]

same here, have been running around in circles, creating tokens, reading blog posts, discussions, asking the web, logging in again, generating tokens, nothing works. That page where they explain what's going to change is an utter disgrace, it's just mumbo-jumbo for me.

[Trott]

I don't know about other downsides to this approach and/or maybe I don't understand your situation/constraints correctly--admittedly, I do a lot of skimming in these discussions--but if you use trusted publishing for GitHub Actions rather than an npm token, then you don't need to include your password or a token or any secret at all. Or at least that's been my experience so far.

[vemonet]

Thanks @Trott for the link, this should be linked in their announcement post, instead their are telling us this will be soon be deprecated also...

We're evolving from "trusted publishing" to "Established Trust"

[gor119-cpu]

Gor

[twesterhuys]

Expanded OIDC provider support, including GitHub Enterprise Server and self-hosted runners

@leobalter is there an update on the timeline regarding this? The 3.19 release notes did not mention anything in this regard nor can I find mentions on the github action runner repo etc. We would be very interested in adopting this for our GHES + self-hosted runners setup.

[ckcr4lyf]

> TOTP 2FA: Cannot add new or reconfigure existing setups (existing TOTP still works)
> Your feedback has directly shaped these changes, and we'll continue to iterate based on your needs.

What a fucking joke.