npm has introduced a 48‑hour expiration for any trusted publishing configuration that has not yet been validated by a successful publish. After the window closes the configuration can no longer authorize package uploads, and the token is rejected for certain GitHub Actions events.
Change Overview
When a developer creates a new trusted publishing entry, npm marks it as unvalidated. If the first publish does not occur within two days, the entry automatically expires and loses its publishing rights. The entry becomes validated—and therefore exempt from expiration—once the initial publish succeeds. Changing the repository or project name does not reset the timer; a fresh configuration must be created for the new identity. Expired entries stay visible in the trusted publisher UI but are excluded from per‑package limits, while any other active configurations continue to work.
Impact on CI/CD and Supply‑Chain Security
CI pipelines that rely on trusted publishing must now ensure that the first publish happens quickly, or they risk a sudden loss of publishing capability. Additionally, npm has extended its event restrictions: tokens issued from issue_comment events are rejected, leaving only push, release, and workflow_dispatch as permitted triggers. This narrows the attack surface for malicious actors who might otherwise hijack a repository name and use a stale trust relationship to push compromised packages.
Operational Adjustments
- Schedule the initial trusted publish within the 48‑hour window, or automate recreation of the configuration if the window is missed.
- Audit GitHub Actions workflows to confirm they use
push,release, orworkflow_dispatchevents for publishing steps. - Monitor the trusted publisher UI for expired entries to avoid unexpected limit calculations.
- Document the need for a new trust relationship whenever a repository or project name changes.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Teams should treat the 48‑hour period as a hard deadline for validating new trusted publishing setups and adjust automation to use only the allowed GitHub Actions events. Proactive monitoring and quick remediation of expired configurations will keep supply‑chain pipelines reliable and reduce exposure to stale trust relationships.