npm Trusted Publishing Tightens Security With 48-Hour Expiry

npm trusted publishing tightened its security model on 2 October 2026. New trusted-publisher configurations that have not completed a successful publish now expire after 48 hours, and npm also rejects trusted-publishing tokens issued from GitHub Actions issue_comment events.

The change is small on the surface, but it closes an important gap in the trust relationship between npm packages and CI/CD workflows. A configuration that points at a repository or workflow should not remain usable indefinitely before anyone proves that the intended workflow can actually publish from it.

What changed in npm trusted publishing

Unvalidated trusted-publisher configurations now expire 48 hours after they are created. Once the first successful publish completes, the configuration becomes validated and is exempt from that expiry.

If the repository or project identity changes, npm requires a new trust relationship and a fresh 48-hour validation window. Ordinary edits do not restart the deadline. Expired configurations remain visible in trusted-publisher settings but can no longer authorise publishing.

npm also now rejects trusted-publishing tokens from GitHub Actions workflows triggered by issue_comment. That joins the existing restriction on pull_request_target. GitHub recommends moving affected publishing workflows to permitted events such as push, release or workflow_dispatch.

Why trusted publishing matters

Traditional npm publishing often relies on a long-lived token stored in CI/CD secrets. If that token leaks through logs, misconfiguration or a compromised workflow, an attacker may retain publishing access until the credential is noticed and revoked.

Trusted publishing uses OpenID Connect instead. The CI provider presents a short-lived identity token tied to a specific workflow, and npm exchanges it for the authority needed to publish. npm’s current documentation supports GitHub Actions, GitLab CI/CD and CircleCI cloud environments, with provider-specific restrictions.

The security benefit is narrower credential scope and shorter lifetime. There is no reusable npm publish token sitting in a repository secret store waiting to be stolen. For package maintainers, that removes one of the most persistent forms of publishing credential.

The 48-hour window reduces stale trust

The new expiry is designed to address a specific risk: a trusted-publisher configuration can refer to a repository or project name before the first successful publish proves that the expected identity really controls that path.

Requiring validation within 48 hours does not guarantee that the workflow is safe, but it narrows the period during which an unused configuration can become dangerous. If a maintainer creates a configuration and does not publish within that window, it must be recreated.

Staged publishing adds another control

Earlier in 2026, npm made staged publishing generally available. Instead of making a package version immediately installable, a workflow can upload the package to a staging area and require a maintainer to approve it with two-factor authentication before release.

Independent reporting from The Hacker News highlighted the security value of that model: automated CI can prepare a package, but a human must still prove presence before the package becomes public. npm’s own guidance now recommends combining trusted publishing with stage-only permissions for the strongest available posture.

This matters because authentication and release approval solve different problems. OIDC reduces the risk of a stolen long-lived credential. Staged publishing reduces the risk that a compromised or misconfigured workflow can immediately release a package without human review.

Provenance is useful, but it does not prove the code is safe

A recent Socket investigation into compromised npm packages illustrates an important limitation. The malicious versions carried valid npm provenance attestations because they were genuinely produced through the repository’s authorised GitHub Actions publishing workflow.

The weakness was in the workflow design. A comment-triggered path allowed untrusted pull-request code to reach the publishing process. Provenance correctly identified the workflow that produced the package, but it could not determine whether that workflow had been tricked into building malicious source.

Trusted publishing and provenance can prove identity and build origin, but they do not replace secure workflow triggers, branch protection or code review.

What maintainers should review now

• Check unvalidated trusted publishers. Any newly created configuration now needs a successful publish within 48 hours.
• Inspect workflow triggers. Avoid publishing from issue_comment, pull_request_target or other flows where untrusted code can influence a privileged job.
• Prefer OIDC over long-lived publish tokens. Revoke automation tokens that are no longer required after migration.
• Consider staged publishing. Requiring a 2FA-backed human approval adds protection against a compromised CI pipeline.
• Review repository identity carefully. The package metadata, repository URL and configured workflow need to match the intended project.
• Treat provenance as evidence, not approval. A valid attestation tells you where an artifact came from, not whether the workflow itself was secure.

Nevelit’s article on GitHub vulnerability reporting controls examined another part of the software-security process: reducing low-quality vulnerability intake. npm trusted publishing addresses a different layer, but the principle is similar — security controls work best when they narrow the path from untrusted input to privileged action.

Trade-offs and operational limits

Trusted publishing is not universal. npm currently requires supported cloud-hosted CI environments, and self-hosted runners remain outside the documented supported set. Teams with bespoke build infrastructure may therefore need a transitional design.

OIDC also does not replace every npm credential. Private dependency installation can still require a read-only token, and some npm operations remain interactive. Maintainers need to separate publishing credentials from dependency-read credentials rather than assume trusted publishing eliminates authentication entirely.

Staged publishing introduces deliberate friction. A human approval step can slow fully automated release pipelines, particularly for projects that publish frequently. The decision is therefore a trade-off between release speed and resistance to compromised automation.

Critical analysis

The 48-hour expiry is a sensible hardening measure because it targets stale trust without disrupting configurations that have already proved themselves through a successful publish. Blocking issue_comment-based trusted publishing also removes a trigger that can be difficult to secure safely.

The more important lesson is that package security cannot be reduced to one control. OIDC improves credential handling. Provenance improves traceability. Staged publishing introduces human approval. None of them can compensate for a workflow that executes untrusted code with publishing authority.

For small teams maintaining npm packages, the practical priority is to simplify and constrain the release path: use trusted publishing, remove unnecessary long-lived tokens, restrict workflow triggers and add staged approval where the consequences of a bad release justify the extra step.

Sources

• GitHub Changelog — Unvalidated npm trusted publishing configurations now expire, 2 October 2026.
• npm Docs — Trusted publishing for npm packages, accessed 6 October 2026.
• The Hacker News — npm Adds 2FA-Gated Publishing and Package Install Controls Against Supply Chain Attacks, 23 May 2026.
• Socket — OpenAPI React Query Codegen Compromised in Mini Shai-Hulud npm Supply Chain Attack, September 2026.