npm Puts a 48-Hour Clock on Unused Trusted Publishing Configurations

GitHub has added an expiration date to unused npm trusted publishing configurations. Any configuration that doesn’t complete a successful publish within 48 hours of creation now expires and can no longer authorize a release.

It’s a small change. But it closes a gap that matters to anyone who publishes packages from a CI/CD pipeline.

How Trusted Publishing Works

Trusted publishing lets teams publish an npm package from a CI/CD workflow without storing a long-lived token in repository secrets. Instead, the maintainer tells npm which repository and workflow to trust. When that workflow runs, the CI provider issues a short-lived OpenID Connect (OIDC) token. npm checks it against the configuration before it accepts the release.

GitHub made the feature generally available in July 2025. Adoption picked up after the Shai-Hulud worm hit the npm registry and GitHub moved to retire long-lived classic tokens. Trusted publishing requires npm CLI 11.5.1 or later and Node.js 22.14.0 or later.

The Gap

A trusted publishing configuration states trust in a name. It points to a repository or project identity. If that name changes hands, the trust can follow.

Security researchers know this pattern well. It’s called repo-jacking. When an organization renames itself, GitHub redirects the old name to the new one. But if an attacker registers the old name, anything that depends on it pulls from the attacker instead. Aqua Security found that about 3% of the repositories it sampled were exposed, estimating roughly 9 million projects on GitHub. Earlier, Checkmarx showed that bypassing GitHub’s namespace retirement protection put more than 10,000 packages on Go, Swift, and Packagist at risk.

Now apply that to npm. A maintainer creates a trusted publishing configuration, then never runs the workflow. Maybe the project stalls. Maybe the repo gets renamed, or the org gets reorganized. That dormant configuration sits there, still willing to accept a publish from whoever controls that name next. GitHub says the expiry limits the risk of trusting a repository or project name that changes ownership.

What Changed

The rules are simple:

• A new configuration has 48 hours to complete a successful publish. After that, it expires.
• Once a configuration publishes successfully, it’s validated and exempt from expiry.
• Ordinary edits don’t reset the clock. Changing the repository or project identity does. That creates a new trust relationship with its own 48-hour window.
• Expired configurations stay visible in trusted publisher settings, but they don’t count against per-package limits. Other valid configurations on the package keep working.
• If a configuration expires, recreate it to start a new window.

npm also now rejects trusted publishing tokens from GitHub Actions workflows triggered by issue_comment events. That joins the existing block on pull_request_target. Both triggers can fire in response to activity from people outside the project, which makes them a poor place to mint publishing credentials. Teams that publish from those events need to move to push, release, or workflow_dispatch.

“npm now puts an expiration date on software trust,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group. “A trusted publishing configuration is a standing grant tied to a repository name, and repository names change owners. An unused grant left open indefinitely gives an attacker the path that short-lived tokens were built to close.”

What DevOps Teams Should Do

Most teams won’t notice. If you set up a configuration and published from it the same day, you’re done.

The teams that will feel it are the ones that configure trust ahead of time. Think of a bootstrap script or a platform team’s onboarding checklist that sets up publishing days or weeks before the first release. Those configurations will now lapse.

A few practical steps:

• Create the configuration when you’re ready to publish, not before.
• Plan the first release inside the 48-hour window.
• Audit workflows for issue_comment and pull_request_target publishing triggers. Fix them before a release fails.
• When a repo is renamed or transferred, expect to re-establish trust. That’s by design.

Part of a Bigger Push

This is one of several npm changes in recent weeks. In September, npm began allowing multiple trusted publishing configurations per package. By default, every configuration can stage a release, and direct publishing is opt-in. GitHub recommends keeping configurations staging-only, so a human approves each version before it goes live.

Later that month, npm added an opt-in permission that lets configurations manage dist-tags with OIDC credentials. Maintainers no longer need to keep a granular token around just to move the latest tag after a release or rollback. And on Oct. 2, staged publishing gained the ability to create brand-new packages from automation. The first version waits in a queue until a maintainer promotes it.

The direction is clear. npm wants every publishing path to run on short-lived credentials, with a human checkpoint where it counts and no trust that outlives its purpose.

And that standard won’t stay limited to public registries. “The pressure on that model rises as coding agents start cutting releases,” Ashley said. “Enterprises should hold their internal registries and pipelines to the same standard.”

The Bottom Line

A 48-hour window is a modest constraint. Most pipelines will never hit it. But dormant trust is where a lot of supply chain attacks start. An expired configuration costs a maintainer a few minutes to recreate. A hijacked one can cost every downstream user far more.