npm Packages Can Now Have Multiple Trusted-Publishing Configs. Set Yours Up Before January.
GitHub pushed three npm publishing changes live on September 3, and on their own they read like routine infrastructure housekeeping: multiple trusted-publishing configurations per package, mandatory malware scanning before a staged package can be approved, and a per-version staging history in the npmjs.com UI. None of that sounds urgent. The reason it's worth ten minutes of your time this week is the deadline sitting quietly underneath it: if you publish an npm package with a classic long-lived token, or a 2FA-bypass granular access token, that publishing method is on a countdown that ends around January 2027.
What changed on September 3
A package can now carry more than one OIDC trusted-publishing configuration instead of being limited to exactly one. Before this, if you had separate CI workflows for stable releases, prereleases, and a staging pipeline, you either had to force all three through one shared configuration or keep a long-lived publish token around to cover whatever OIDC couldn't. Now each workflow can get its own configuration, independently scoped to its own repository, workflow, and environment. A publish is authorized if the incoming token matches any one of them; GitHub is explicit that configurations don't restrict each other and you shouldn't build logic that depends on match order.
The second change closes a real gap: since npm added publish-time malware scanning, packages get scanned before becoming available, but the staged-publishing approval button could previously be clicked before that scan finished. Now the approval button stays disabled until the scan completes, so a human can't accidentally rubber-stamp a package that hasn't been checked yet. Third, the versions tab on npmjs.com now shows maintainers a real history per version: approved, rejected, or still staged.
The deadline this is quietly building toward
None of the September 3 changes are the deadline themselves, they're GitHub making the destination easier to move to. The actual dates, laid out in GitHub's own July changelog: 2FA-bypass granular access tokens lost the ability to perform account, package, and organization management actions (creating tokens, changing package access, managing org membership) around early August 2026. The bigger one: those same bypass tokens are expected to lose the ability to publish packages directly around January 2027. After that, a bypass token's publishing capability shrinks to reading private packages and staging a publish, with a package only going public after a human completes a 2FA approval.
If your CI pipeline still authenticates to npm with a classic token or a 2FA-bypass GAT to run npm publish automatically, that automation has a hard stop coming in about four months, not a vague someday.
What to do this week
I went and checked my own release workflow for a small CLI tool I publish, and found exactly the pattern this is aimed at: a long-lived NPM_TOKEN secret sitting in a GitHub Actions workflow, working fine, and not going anywhere near an OIDC config. Go check yours the same way. If it's a long-lived token, or any token type set to bypass 2FA, that's the thing to replace. Set up an OIDC trusted-publishing configuration scoped to your actual release workflow, and if you also cut prereleases or use a separate staging pipeline, add a second configuration for that rather than trying to force everything through one. Given the mandatory malware-scan-before-approval change, if you use staged publishing, expect a short delay between "staged" and "approvable" that wasn't there before, budget for it in any release-automation timing you've hard-coded.
The honest reason to do this now instead of in December: trusted publishing migrations always take longer than the fifteen minutes the docs imply, because CI permissions, environment scoping, and whatever your release script assumes about credentials being present synchronously tend to surface a small surprise or two. Four months is enough runway to hit that surprise, fix it, and verify a real release goes out clean. One week in January is not.
The honest take
I think GitHub's sequencing here is reasonable: they gave an early warning in June, shipped the first restriction in August, and are still adding capability (multiple configs) to make the destination more usable before the January cutover rather than just yanking the old path and leaving people to figure it out. My pushback: "around January 2027" is still doing a lot of work in that sentence, GitHub hasn't nailed down an exact date as of this writing, and soft deadlines are exactly the kind of thing that let solo maintainers with one package and no dedicated DevOps time keep deferring until the actual cutover breaks a release at the worst moment. If you maintain even one published package solo, don't wait for the firm date. Migrate this month while it's a calm afternoon project instead of a January fire drill.
Author
Lukas
@lukcombinator