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.

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

[horia-stoenescu]

CLI parity: Full npm token command support for granular tokens (list, add, delete)

Regarding integration of generating granular tokens via CLI (npm token create) as the deadline of revoking classical tokens (which can now be generated via CLI, meaning also easily automatable) is approaching, when is this PR npm/cli#8706 going to be ready for review and then merged? The enforcement from 19th Nov will highly increase the time of managing multiple sets of tokens.