Yes, when the registry and CI platform support it, because rotation still leaves a reusable secret in place between cycles. OIDC trusted publishing removes the standing credential entirely, which is a stronger control than trying to manage the lifetime of a token that should not exist in the first place.
Why OIDC Trusted Publishing Is the Better Default for npm Releases
oidc trusted publishing changes the release model from “protect a reusable secret” to “issue short-lived, context-bound release authority only when the CI workload proves who it is.” That matters because token rotation reduces exposure but still depends on a standing credential existing somewhere between rotations. For release pipelines, the stronger control is usually to remove that standing secret altogether.
For npm specifically, that means the release trust decision shifts to the identity provider and the CI platform’s federated trust configuration. The release path becomes narrower, because the pipeline receives just enough authority for the publishing event rather than carrying a long-lived npm token that can be copied, reused, or exfiltrated.
This is why the comparison is not just about convenience. A rotated token can still be stolen before the next rotation cycle, and rotation discipline can fail during handoffs, outages, or forgotten service paths. trusted publishing reduces the blast radius by changing the credential type, not merely shortening its lifetime.
How Token Rotation Compares to Trusted Publishing in Practice
Token rotation is a compensating control when a secret must exist. It can be effective, but it assumes the registry, pipeline, and operational process can all keep pace with the rotation schedule. In a release workflow, that assumption is often fragile because publishing tokens tend to be embedded in CI secrets, reused across environments, or copied into developer workflows.
OIDC trusted publishing avoids that accumulation. The CI job authenticates with federation and receives a scoped, ephemeral assertion for the publish action. That makes the control closer to OpenID Connect Core 1.0 than to secret management, because the trust is established at release time instead of being preserved in a reusable bearer token.
For teams managing non-human release identities, the practical distinction is clear in Guide to NHI Rotation Challenges: rotation lowers exposure, but it still leaves lifecycle overhead, dependency mapping, and failure risk. Trusted publishing removes the need to keep rotating a credential that should not have been standing in the first place.
Release Risk, Abuse Paths, and What Actually Changes
The main risk with token-based npm publishing is secret reuse across the CI boundary. If an attacker gets the token from logs, a compromised runner, a leaked environment variable, or a poisoned dependency step, they can publish malicious packages until the token is revoked or rotated. That is exactly the kind of abuse path that makes publishing credentials valuable to supply-chain attackers.
OIDC trusted publishing changes the failure mode. The attacker now needs to compromise the federated trust relationship, the CI workload identity, or the signing and policy conditions that allow the release assertion to be accepted. That is a harder problem than stealing a long-lived token, because the credential is no longer a static artifact sitting in the pipeline.
Recent npm supply-chain incidents show why this matters. ChainDrop npm worm 2026 illustrates how publishing tokens and CI secrets can be harvested and then used to spread further. Shai Hulud npm malware campaign and Nx s1ngularity attack 2025 show the same pattern: once a secret is present, it becomes a theft target.
Risk and Threat Considerations
Token rotation reduces dwell time, but it does not eliminate the exposure created by a reusable npm publishing secret. If that secret is present in CI, an attacker who reaches the pipeline, the logs, or a dependency execution path can still reuse it until the next rotation event.
Failure mechanism: The release credential remains a bearer secret, so compromise of the CI environment, workflow logs, or adjacent automation can expose a usable publishing path before rotation takes effect.
Impact: Attackers can publish tampered packages, poison downstream consumers, and extend compromise through the software supply chain. Trusted publishing lowers that risk by making the credential ephemeral and context-bound instead of durable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | npm publishing tokens are standing secrets that create release exposure. |
| NHI-02 — Secret Leakage | The question centers on avoiding reusable npm secrets in CI and release pipelines. | |
| NHI-04 — Insecure Authentication | OIDC trusted publishing replaces static token auth with federated workload authentication. | |
| Recommendation — Replace long-lived release tokens with ephemeral trusted publishing wherever supported. Eliminate stored publishing secrets and monitor for leakage in build and release systems. Use federated, short-lived authentication for package publishing instead of static tokens. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Package publishing depends on correct authentication to the registry and CI trust path. |
| Recommendation — Harden registry authentication so publishing cannot be performed with weak or stale credentials. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | CI workloads and release automation authenticate as non-human actors during publishing. |
| IA-5 — Authenticator Management | Token rotation and secret lifecycle management are directly implicated by npm publishing tokens. | |
| Recommendation — Authenticate CI workloads with short-lived service credentials instead of durable shared secrets. Manage publishing authenticators so static tokens are avoided or tightly time-bounded. | ||
Practitioner Guidance
What to prioritise: Use OIDC trusted publishing first when the registry supports it and your CI platform can issue the required federated assertion. Keep token rotation as a fallback for the systems that cannot yet move to federation.
What to verify: Confirm that the publish workflow is bound to the expected repository, branch, environment, and package namespace, and that no manual override recreates a standing secret for “temporary” convenience. If a token still exists in a secret store, treat that path as the weaker control.
Common mistake: Teams often rotate a token and assume they have solved publish security. The better question is whether the token should exist at all. If the answer is no, lifecycle reduction beats lifecycle management.
Practitioner takeaway: For npm releases, prefer removing standing release credentials over managing them more carefully, because an ephemeral federated trust path is materially safer than a reusable secret that must be protected forever.
Related resources from NHI Mgmt Group
- What breaks when a long-lived npm token is left active after adopting OIDC publishing?
- How should security teams implement Trusted Publishing for npm packages in CI pipelines?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?