On October 2 GitHub announced that unvalidated npm trusted publishing configurations expire 48 hours after creation. The aim is to limit the risk of trusting a repository or project name that changes ownership.
Trusted publishing ties npm publish rights to an approved CI/CD workflow through OpenID Connect (OIDC). It removes the need to store long-lived npm write tokens.
Where the 48 hours apply
A newly created configuration is unvalidated, and the 48 hours start then. A first successful publish through it validates the configuration and exempts it from the expiry rule.
If the 48 hours end first, it can no longer authorize publishing. Expired entries stay visible in trusted publisher settings but do not count toward per-package limits.
A fresh 48 hours requires recreating the configuration, and ordinary edits do not restart the deadline. Changing the repository or project identity requires a new trust relationship, and other valid configurations on the package are unaffected.
GitHub Actions events whose publishes are rejected
The same announcement includes a GitHub Actions event restriction. Alongside the existing pull_request_target restriction, npm now rejects trusted publishing tokens issued from issue_comment events.
Affected projects are directed to move publishing to a permitted event such as push, release or workflow_dispatch.
Run conditions the setup docs require
The npm docs require npm CLI 11.5.1 or later and Node.js 22.14.0 or later. Supported environments are GitHub-hosted Actions runners, GitLab.com shared runners and CircleCI cloud, and self-hosted runners are not yet supported.
A package can have up to 10 trusted publishers. On GitHub Actions the organization or user, repository, workflow filename and optional environment name must match exactly, and the workflow needs the id-token: write permission.
npm stage publish is always allowed, and permission to publish directly with npm publish is selected separately. npm does not verify the configuration when it is saved, so errors surface only at publish time.
A setup order aligned with the first release
Preparing the release workflow’s trigger, runner and publish permissions first, then creating the trust relationship just before the planned first release, fits the deadline well. There is no need to rush review to keep a configuration alive.
If one has already expired, it is recreated once the release is ready and checked by publishing successfully through the intended trusted publishing path. Permitted events still need review and release controls.
Caveats: the existing token path and a docs change
The 48-hour deadline applies only to unvalidated trusted publisher configurations. Where package settings allow it, traditional token authentication remains a separate publish path.
When checked on October 6 the npm setup docs did not mention expiry, but on recheck on October 14 they had a section requiring the first publish within 2 days. The docs say to delete an expired configuration and create a new one.
The changelog does not say how configurations created before the announcement but not yet validated are handled. Their actual status cannot be told from the changelog alone.
An npm trusted publisher is no longer something set up in advance; it is created just before the first release and validated within 48 hours.