After the Shai-Hulud worm, GitHub announced plans to limit npm authentication and publishing to three paths: local publishing with two-factor authentication, granular tokens with a seven day lifetime, and trusted publishing. Maintainers should move to trusted publishing and phishing resistant 2FA now.
What GitHub said it would change
In its post of 22 September 2025, GitHub listed these steps:
- Deprecate legacy classic tokens.
- Deprecate TOTP based 2FA and move users to FIDO based 2FA.
- Give granular tokens that can publish a shorter expiry.
- Disallow tokens for publishing by default.
- Remove the option to bypass 2FA for local publishing.
- Expand the providers eligible for trusted publishing.
The post gave no dates for these changes. It said they would arrive in the near future and roll out gradually. Check the current npm documentation before you rely on any of them being in force, because this post cannot tell you what has shipped since.
What each path means
Local publishing with 2FA. You publish from your own machine and approve with a second factor. Weak if your machine is compromised, as the worm showed.
Granular tokens. Scoped to specific packages and short lived. Better than classic tokens, but still a secret that can be stolen from a CI environment.
Trusted publishing. The registry accepts a publish only from a named workflow in a named repository, using short lived identity instead of a stored token. GitHub's post notes npm added it in July 2025, with PyPI, RubyGems, crates.io and NuGet having their own dates.
Maintainer checklist
- List every npm token you hold and who holds each. Delete the ones you do not need.
- Move your packages to trusted publishing where your workflow allows it.
- Switch 2FA to a hardware key or passkey.
- Require 2FA on writes at account, organization and package level.
- Remove publish steps and tokens from workflows that also run third-party code.
- Add an alert for any new version that your pipeline did not publish.
- Write down how you would respond if your account were compromised, and who can unpublish or deprecate. Start from this first day checklist.
What this does not solve
A trusted workflow can still publish bad code if the workflow itself is attacked, for example through unsafe handling of pull request input. Trusted publishing removes one class of theft. It does not review your build for you.
Why the order of work matters
If you only have an afternoon, do three things first: delete unused tokens, turn on a hardware key for every maintainer, and remove any publish token from a workflow that also runs outside code. Those three steps remove the credentials the worm relied on. Trusted publishing can follow once your build is stable enough to name a single trusted workflow.
Quick check
Is trusted publishing the same as provenance?
No. Trusted publishing is how the registry decides who may publish. Provenance is evidence about where a package was built. They often go together.
Do consumers need to do anything?
Keep lockfiles, review dependency updates, and do not treat a publisher's 2FA as proof that a version is safe.
Sources
- GitHub, Our plan for a more secure npm supply chain, 22 September 2025.
Last reviewed: 19 October 2026.
