npm Trusted Publishing configurations that have not completed a successful publish now expire 48 hours after creation. The change affects maintainers using GitHub Actions-based publishing and is intended to reduce the risk of stale trust relationships remaining authorized after repository or project ownership changes.
As of October 2, 2026, an expired configuration can no longer authorize a publish. Maintainers should review newly created trust relationships, confirm that their workflows meet npm’s requirements, and check whether any publishing jobs rely on events that npm no longer accepts for Trusted Publishing.
What changed in npm Trusted Publishing
According to the GitHub announcement, the 48-hour period begins when an unvalidated Trusted Publishing configuration is created. The configuration becomes validated, and is exempt from expiration, after its first successful publish.
If the first successful publish does not occur within that period, the configuration loses its publishing authorization. It remains visible in the Trusted Publisher settings, but it does not continue to authorize publishing and does not affect other valid configurations. Maintainers can recreate an expired configuration to start a new validation window.
A change to the repository or project identity also requires a new trust relationship and a fresh 48-hour validation period. The announcement says that ordinary edits do not restart the existing deadline. However, npm’s Trusted Publishers documentation says that existing trusted publisher connections cannot be changed and must instead be deleted and recreated. Those statements may refer to different types of operation, but the supplied documentation does not fully explain how they relate.
Workflow events need review
npm also rejects Trusted Publishing tokens from GitHub Actions issue_comment events, in addition to the existing restriction involving pull_request_target. A publishing workflow triggered by one of these events may therefore need to be redesigned.
The GitHub announcement identifies push, release, and workflow_dispatch as examples of events that can be used for affected workflows. These are documented examples, not a complete list of permitted events. The available evidence does not establish the full allowlist or the complete set of rejected events, so maintainers should avoid treating the examples as an exhaustive policy.
This restriction matters for teams whose release automation is tied to comments or pull-request workflows. The relevant job should be reviewed independently of the expiration change: a configuration can be within its validation window and still fail if the workflow uses an event from which npm will not accept the Trusted Publishing token.
Configuration and version requirements
For GitHub Actions, npm documents Trusted Publisher settings that include the organization or user, repository, and workflow filename. An environment and allowed actions can also be specified as optional fields. These values help define which workflow identity is trusted to publish a package.
Trusted Publishing workflows using npm require npm CLI 11.5.1 or later and Node.js 22.14.0 or later. GitHub Actions workflows also need the id-token: write permission so the workflow can obtain an OIDC token. npm’s documentation further specifies cloud-hosted runners for supported providers.
Administrators managing trust relationships through the npm trust command have a separate version requirement. The npm trust CLI reference documents npm 11.15.0 or later, package write access, account-level two-factor authentication, and an existing package as prerequisites.
These version requirements should not be conflated. npm 11.5.1 is the documented minimum for using Trusted Publishing in the workflow, while npm 11.15.0 is the documented requirement for the trust-management command.
Why the expiration window matters
Trusted Publishing uses short-lived OIDC-derived credentials rather than long-lived write tokens, according to npm’s documentation. The new expiration behavior adds a time limit to an unvalidated trust relationship. In practical terms, a configuration that was created but never successfully used will not remain authorized indefinitely.
The policy is particularly relevant when repository ownership or identity changes. A repository transfer, rename, or another change affecting the repository or project identity may require the maintainer to establish trust again rather than continuing to rely on the previous relationship. The announcement describes this as a new trust relationship with a new 48-hour validation window.
The supplied documentation does not specify how configurations created before October 2, 2026 are transitioned under the new rule. It also does not define the exact expiration timestamp beyond stating that the window is 48 hours from creation. Teams with older unvalidated configurations should therefore verify their current status rather than assume that historical setup is exempt.
What you should do
- Review unvalidated configurations. Check Trusted Publisher settings for configurations that have not completed a successful publish. Where the relationship is still needed, coordinate a successful publish within the 48-hour validation window.
- Recreate expired relationships. An expired configuration no longer authorizes publishing. Recreate it to begin a new validation period rather than relying on the visible, but inactive, entry.
- Re-establish trust after identity changes. If the repository or project identity changes, create a new trust relationship and complete validation again.
- Inspect workflow triggers. Review publishing jobs using
issue_commentorpull_request_target. Move affected jobs to an appropriate documented event, such aspush,release, orworkflow_dispatch, while confirming the event is suitable for the workflow. - Check OIDC and tool prerequisites. Confirm that the workflow grants
id-token: write, uses npm CLI 11.5.1 or later and Node.js 22.14.0 or later, and meets any runner requirements documented by npm. - Check trust-management access. If administrators use npm’s trust-management command, verify npm 11.15.0 or later, package write access, account-level two-factor authentication, and an existing package.
One configuration-limit detail remains unclear
Maintainers should be cautious when planning multiple trusted publisher connections. The Trusted Publishers documentation says that a package can have up to 10 trusted publishers, while the npm trust CLI documentation says that the registry currently supports only one configuration per package.
Because these official npm pages conflict, the precise per-package limit should not be treated as settled based on either page alone. Teams that need more than one connection should verify the currently applicable behavior before changing their publishing design.
