npm Trusted Publishing Configs Now Expire in 48 Hours
Quick answer: Since 2 October 2026, an npm trusted publishing configuration expires 48 hours after you create it unless a successful publish happens first. npm also now rejects trusted publishing tokens from issue_comment workflow events. Neither rule appears on npm's own trusted publishers documentation page.
npm put a fuse on trusted publishing. If you create a trusted publisher for a package and do not publish within 48 hours, the configuration stops working — and you will find out the way everyone finds out about registry changes, which is when a release fails at 2am.
The change landed in a GitHub changelog entry on 2 October 2026, alongside a second entry the same day that finally lets npm stage publish create brand-new packages. The two interlock, and the interlock is the part nobody has written down.
What the 48-hour rule actually says
A trusted publishing configuration is unvalidated until its first successful publish. Unvalidated configurations now expire 48 hours after creation and can no longer authorize publishing. Once a configuration has validated through that first publish, it is exempt from the deadline forever.
Four details matter more than the headline.
Expired configurations stay visible. They remain in your trusted publisher settings, looking exactly like working ones. The UI does not become the source of truth here; the publish attempt does.
Expired configurations stop counting toward the per-package limit. npm allows up to 10 trusted publishers per package, and dead ones no longer eat a slot. That is the only consolation prize here.
Recreating resets the clock. If a configuration expires, you delete and recreate it to get a fresh 48-hour window. There is no "revalidate" button.
Changing identity starts a new relationship. Per the changelog, changing the repository or project identity requires a new trust relationship with another 48-hour window, while routine edits do not restart the deadline. Which edits are "routine" is left as an exercise.
The issue_comment rejection will break a working pipeline today
Buried in the same entry: npm now rejects trusted publishing tokens minted by GitHub Actions issue_comment events. The guidance is to move publishing to a permitted event such as push, release, or workflow_dispatch.
That is the 48-hour rule's quieter sibling and the one more likely to bite. ChatOps release flows are common and reasonable: a maintainer comments /release patch on the PR, a workflow picks it up on issue_comment, bumps and publishes. That pattern is now dead for OIDC publishing, and the fix is a real refactor: comment handler validates and dispatches, a second workflow on workflow_dispatch does the publish.
The security logic is sound — issue_comment is an attacker-reachable trigger in the same family as pull_request_target, whose own default block we covered in GitHub's workflow execution protections. The complaint is not the decision. It is that this is a breaking change to publishing, announced in a bullet, inside an entry about something else.
npm's documentation does not mention any of it
We checked docs.npmjs.com/trusted-publishers, which is the page a developer lands on when something fails. As of this writing it documents neither the 48-hour expiry nor the event restrictions. What it does document:
| Documented on the trusted publishers page | Detail |
|---|---|
| Supported providers | GitHub Actions (GitHub-hosted runners), GitLab CI/CD (GitLab.com shared runners), CircleCI (CircleCI cloud) |
| Per-package limit | Up to 10 trusted publishers at the same time |
| Provenance | Automatic for GitHub Actions and GitLab — no --provenance flag needed; not supported for CircleCI |
| Self-hosted runners | "not currently supported but are planned for future releases" |
| 48-hour expiry | Absent |
| Permitted / rejected workflow events | Absent |
There is also a straight contradiction worth knowing about before you go looking for a settings screen. The docs page lists, under limitations, that existing trusted publisher connections cannot be changed. The changelog describes edits that either do or do not restart the 48-hour deadline. Both cannot be a complete description of the same system. If you hit this, trust the registry's behaviour over either page.
This is not the first npm behaviour change to ship ahead of npm's own reference docs — the retired audit endpoints are still documented as a working fallback. Treat the changelog as the spec and the docs as a lagging summary.
New packages: the chicken-and-egg finally has a door
Until 2 October, trusted publishing had an awkward first-run problem: you configured a trusted publisher on a package, which meant the package had to exist, which meant somebody had to publish it by hand first. The second changelog entry that day removes that step — npm stage publish can now create a package that does not yet exist, for public scoped and unscoped packages and private scoped packages.
The mechanism is more public than you might expect. Per npm's staged publishing docs, when you stage a package that does not yet exist, npm publishes a placeholder version numbered 0.0.0-stage. That placeholder is publicly visible while the real staged content stays private until approval. So the act of creating a package from CI also claims the name in public, immediately. If you are name-squatting-averse or working on something unannounced, know that going in.
Approval is a human step: a maintainer with publish access and 2FA enabled runs npm stage approve <stage-id>, with npm stage list, view and download available for inspecting the tarball first. That is the right design — see why token-free publishing matters for the threat model it closes.
The interlock nobody documented
Put the two changes side by side and a question falls out. A configuration is unvalidated until its first successful publish. A staged publish is not a publish — the version enters a queue and waits for a human to approve it with 2FA. Meanwhile a 48-hour clock is running on the configuration.
So: does submitting to the stage validate the configuration, or does approval? Neither page says. We are not going to guess, because the two answers have different consequences. If approval is what validates, a maintainer who goes away for a long weekend comes back to an expired trusted publisher and a 0.0.0-stage placeholder sitting in public.
Until npm documents it, the safe operating rule is simple: do not create a trusted publisher until the release that will use it is ready to run and someone is available to approve it. Treat the configuration as perishable, not as infrastructure.
Registries are putting clocks on everything
This is not an npm quirk. Package registries spent 2026 adding time windows to operations that used to be timeless, and the motivation is the same every time: shrink the interval during which a stolen credential is useful.
| Registry | Clock | What it limits |
|---|---|---|
| npm | 48 hours | Life of an unvalidated trusted publishing configuration |
| PyPI | 14 days | Window for adding new files to an existing release |
| npm, pnpm, Yarn, Bun | Configurable | Install cooldown before a freshly published version is resolvable |
PyPI's version is instructive: it rejects new files uploaded to releases older than 14 days, to stop long-stable releases being poisoned if a publishing token or workflow is compromised. PyPI also said plainly that users should not yet rely on the behaviour, since no API confirms a release's status. npm said no such thing, and shipped its rule as enforced.
If you maintain packages across ecosystems, this is now a category of thing to track rather than a series of surprises. The third row is the one worth auditing yourself: install cooldowns are configured per client, and a policy that reads as equivalent across four repositories often is not, because the clients do not agree on how the value is expressed. Worth the same discipline you would apply to any tool comparison.
What to do this week
Grep your workflows for issue_comment. Any job that both triggers on it and runs npm publish with OIDC is already broken. Split it into a dispatcher and a publisher. If you are reading workflow YAML in bulk, a YAML to JSON converter plus jq beats eyeballing fifty files.
Audit trusted publishers you created but never used. Configurations you set up in a planning sprint and did not exercise are now dead weight that looks alive. Delete and recreate them when you actually ship.
Stop treating configuration as setup. Fold it into the release runbook, immediately before the release, not into onboarding docs written months earlier.
If you are on self-hosted runners, you are still out. Trusted publishing remains cloud-hosted-only, with self-hosted support described as planned. That is unchanged, and it is the single biggest reason teams still hold long-lived tokens. See the cloud and DevOps tool directory for the CI options that do support it today.
FAQ
Does the 48-hour expiry affect trusted publishers I already use?
No. A configuration is exempt once it has completed a successful publish. The rule targets configurations that were created and never exercised.
How do I tell whether a configuration has expired?
npm does not surface it clearly: expired configurations stay visible in the trusted publisher settings. The practical test is a publish attempt. Delete and recreate if it fails authorization.
Which GitHub Actions events can mint a trusted publishing token?
The changelog names push, release and workflow_dispatch as permitted examples and issue_comment as rejected. Neither the changelog nor the trusted publishers page publishes a complete allowlist, so treat anything outside those three as unverified.
Can I create a new package from CI now?
Yes, with npm stage publish since 2 October 2026. npm creates a publicly visible 0.0.0-stage placeholder, and a maintainer must approve the real version with 2FA before it is installable.
Does a staged publish validate the trusted publishing configuration?
Unknown. Neither the trusted publishers page nor the staged publishing page says whether submission or approval counts as the "first successful publish". Assume the stricter reading and have an approver ready inside the 48-hour window.
Does this apply to GitLab CI and CircleCI too?
The expiry rule is described as applying to trusted publishing configurations generally, so assume yes for all three supported providers. The issue_comment rejection is GitHub Actions specific by nature.
Compare CI/CD and registry tooling in the TechLogHub developer tools directory, or browse open-source listings for the publishing automation people actually run.