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

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?

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