npm Trusted Publishing
Publishing authentication in Developer tools
Removes long-lived npm tokens from CI pipelines by using short-lived OIDC credentials for publishing. Caveat: critics say it is not enough alone and is limited to some CI platforms.
Removes long-lived npm tokens from CI pipelines by using short-lived OIDC credentials for publishing. Caveat: critics say it is not enough alone and is limited to some CI platforms.
26 people gave an opinion
- recommend it
- 10
- criticize it
- 16
- approval share
- 38%
Recommended in 6 of 13 months
- November 2025: recommended
- December 2025: not recommended
- January 2026: recommended
- February 2026: not recommended
- March 2026: recommended
- April 2026: recommended
- May 2026: recommended
- June 2026: not recommended
- July 2026: not recommended
- August 2026: not recommended
- September 2026: not recommended
- October 2026: recommended
- November 2026: not recommended (month in progress)
Why it doesn’t carry the badge
- 10 people recommend itNeeds 10 or more, met.
- 0.6 recommenders for every criticNeeds 2 to 1 or better, not met.
- Recommended in 6 of 13 monthsNeeds 4 or more, met.
The same three rules apply to every product, and the badge can’t be bought. How the badge works
What people say about it
The reasons people give, with the number of comments that give each one. Open a reason to read what they said.
Why people recommend it
Each mark is one comment
Removes long-lived tokens and keys from CI
“the risk of long-lived, highly privileged credentials is the primary motivating reason for Trusted Publishing”
Comment from 12 May 2026 in “TanStack NPM Packages Compromised” “TP is amazing at removing long lived npm tokens from CI”
Comment from 12 May 2026 in “TanStack NPM Packages Compromised” “You shouldn't have any keys anywhere at all. Use OIDC”
Comment from 24 Nov 2025 in “Shai-Hulud Returns: Over 300 NPM Packages Infected” - Comment from 31 Mar 2026 in “Axios Compromised on NPM – Malicious Versions Drop Remote Access Trojan”
Limits CI takeover and worm-style attacks
“Trusted Publishing would make it harder for the parties behind Shai-Hulud to group and orchestrate the kinds of compromise waves we're seeing.”
Comment from 30 Nov 2025 in “Post-mortem of Shai-Hulud attack on November 24th, 2025” “it's a significant improvement that kills an entire class of CI takeover publish attacks”
Comment from 23 May 2026 in “GitHub introduces staged publishing and new install-time controls for NPM” “it eliminates/foreshortens the attack staging window significantly”
Comment from 24 Nov 2025 in “Shai-Hulud Returns: Over 300 NPM Packages Infected”
What people warn about
Each mark is one comment
Only some CI platforms supported
“"trusted publishing" means a type of reverse vendor lock in? Only some CI systems are allowed to be used for it.”
Comment from 7 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens” “NPM can and should support federating with CI/CD platforms other than GitHub Actions”
Comment from 8 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens” “trusted publishing doesn't solve that if you use self-hosted CI”
Comment from 8 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens” - Comment from 8 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens”
Creates vendor lock-in
“the path to dependency on closed publishers was opened wide with the introduction of both attestations and trusted publishing”
Comment from 7 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens” “"trusted publishing" means a type of reverse vendor lock in? Only some CI systems are allowed to be used for it.”
Comment from 7 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens” “If you rely on "Trusted Publishing" you are assisting Microsoft in making a moat for their CI platform.”
Comment from 20 Dec 2025 in “GitHub postponing the announced billing change for self-hosted GitHub Actions” Hard setup and poor documentation
“all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility”
Comment from 11 May 2026 in “TanStack NPM Packages Compromised” “it seems like a rushed decision. poor coordination and incomplete docs”
Comment from 4 Jan 2026 in “From fear to pain: NPM trusted publishing and oidc” “Turning on Trusted Publishers was a huge pain with so many package.”
Comment from 7 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens” Not enough alone; unnecessary
“Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI”
Comment from 11 May 2026 in “TanStack NPM Packages Compromised” “I'm struggling to understand why Trusted Publishers is any better.”
Comment from 24 Nov 2025 in “Shai-Hulud Returns: Over 300 NPM Packages Infected” “Standing on the sidelines it appears wholly unnecessary to me.”
Comment from 8 Jan 2026 in “NPM to implement staged publishing after turbulent shift off classic tokens” - Comment from 25 Nov 2025 in “Shai-Hulud Returns: Over 300 NPM Packages Infected”
What people said
All 31 comments that mention it, newest first. Each links to the original comment.
“the PyPI repository has an opt-in system called”
“So the malicious package would have gotten the happy little green star, with users assured it was "Built and signed with provenance."”
“it's a significant improvement that kills an entire class of CI takeover publish attacks”
“the risk of long-lived, highly privileged credentials is the primary motivating reason for Trusted Publishing”
“There is no gate you can put on a Trusted Publisher setup in github which requires 2fa to remove.”
“TP is amazing at removing long lived npm tokens from CI”
“all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility”
“Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI”
“Features like Trusted Publishing are a huge step in the right direction.”
“This helps mitigate spear phished privileges employees pushing hacked npm packages entirely.”
“No access token whatsoever.”
“a home-grown or personal use IdP will not be eligible”
“Standing on the sidelines it appears wholly unnecessary to me.”
“trusted publishing doesn't solve that if you use self-hosted CI”
“NPM can and should support federating with CI/CD platforms other than GitHub Actions”
“the term "Trusted Publishing" implies everyone else is untrusted”
“the path to dependency on closed publishers was opened wide with the introduction of both attestations and trusted publishing”
“"trusted publishing" means a type of reverse vendor lock in? Only some CI systems are allowed to be used for it.”
“Turning on Trusted Publishers was a huge pain with so many package.”
“we designed it to be generic across OIDC IdPs”
“it seems like a rushed decision. poor coordination and incomplete docs”
“This does seem wildly overcomplicated.”
“Why do people come up with such unbelievably complex solutions that don't actually achieve what a simple solution could do?”
“If you rely on "Trusted Publishing" you are assisting Microsoft in making a moat for their CI platform.”
“Honetsly the whole workflow bothers me”
“Trusted Publishing would make it harder for the parties behind Shai-Hulud to group and orchestrate the kinds of compromise waves we're seeing.”
“It does largely avoid the issue if you configure to allow only specific environments”
“it can open up other vectors of much more probable attack”
“I'm struggling to understand why Trusted Publishers is any better.”
“You shouldn't have any keys anywhere at all. Use OIDC”
“it eliminates/foreshortens the attack staging window significantly”
Counts come from 1,795,640 Hacker News comments, November 2025 to November 2026. How we count. Report a mistake.