Because legacy tokens preserve an alternate path to publish releases without the workflow identity and provenance that trusted publishing is meant to enforce. If both paths remain active, attackers only need the weaker one. Teams should remove old credentials once a modern release mechanism is in place and verify that no bypass path remains.
Why legacy publishing tokens remain a supply chain weakness
Legacy publishing tokens are risky because they preserve a second way to publish artifacts outside the newer trusted publishing path. That second path often relies on long-lived credentials, which are easier to steal, reuse, or accidentally retain. In practice, the security model is only as strong as the weakest enabled route to release.
Trusted publishing improves release integrity by binding publication to workflow identity and provenance, but it does not automatically invalidate older credentials. If an old token still has publish permission, an attacker can ignore the stronger path entirely and abuse the weaker one. That is why migration must include token removal, not just setup of the new mechanism.
For release systems, the key issue is path equivalence. Two working publish paths mean two different trust assumptions, and the older one usually lacks the same auditability, short-lived authorization, and provenance guarantees. The moment both remain active, the intended control boundary becomes optional rather than enforced.
How alternate publish paths undermine provenance and trust
Trusted publishing is meant to make the publishing event attributable to the workflow, build context, and identity controls that produced the artifact. A legacy token bypasses that chain. The artifact may still appear legitimate, but the release no longer proves that it came through the expected automation, so consumers inherit a weaker trust signal.
This matters most when the older token can publish without additional checks. If the token is copied into scripts, secret stores, developer machines, or CI variables, it creates a reusable credential that outlives the workflow security model. That is a classic supply chain problem: a control added for safety is neutralized by an older exception that still works.
The operational lesson is that release security depends on removing redundant authority, not just adding better authority. A modern publishing path and a dormant legacy path are not equivalent from a risk perspective, because only one of them is designed around short-lived, verifiable release identity.
What teams should verify before declaring the migration complete
Migration is complete only when the old route is gone, not merely unused. Teams should verify that every publish-capable credential has been identified, rotated or revoked, and that no package, registry, or automation job can still authenticate with an obsolete token. They should also confirm that the release process fails closed if trusted publishing is unavailable.
That verification needs to include the full publish surface, not just the primary repository. Common gaps include mirrored automation, forgotten environment variables, local scripts, inherited secrets in CI, and service accounts with package registry write access. If any of those still allow publication, the stronger workflow path is not yet the only effective path.
Teams should also test for evidence of bypass paths in practice, not only in documentation. A control is not enforced until a legacy token is denied or invalidated and the package can still be published only through the intended modern flow.
Risk and Threat Considerations
Legacy tokens create a standing compromise opportunity because they are often long-lived, widely copied, and difficult to inventory once trusted publishing is introduced. Attackers do not need to defeat the newer workflow if they can steal or reuse the older credential that still publishes releases.
Failure mechanism: An obsolete token remains valid after migration, so publication can occur through an unauthenticated or weakly governed path that bypasses workflow identity, provenance, and release approvals.
Impact: Malicious or unauthorized packages can be published under a trusted project name, which increases the chance of downstream compromise, dependency poisoning, and loss of confidence in release integrity.
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 addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Build provenance and artifact integrity | Trusted publishing and release provenance are central to artifact integrity. |
| Recommendation — Require verifiable provenance for every release artifact and reject releases without it. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Legacy publish tokens are a leftover credential that should be retired after migration. |
| NHI-07 — Long-Lived Secrets | Old publishing tokens are long-lived secrets that preserve bypass access. | |
| Recommendation — Revoke obsolete publishing credentials as soon as the trusted path is active. Replace long-lived publish tokens with short-lived, workflow-bound credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | Retiring old publish tokens is an account and credential lifecycle control. |
| Recommendation — Inventory and remove any account or secret that can still publish releases. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Publishing tokens are authenticators that must be rotated and invalidated. |
| IA-9 — Service Authentication | Trusted publishing relies on workflow/service identity instead of reused tokens. | |
| Recommendation — Rotate or revoke any authenticator that can still authorize publishing. Bind release authorization to workflow identity and eliminate token-based fallback. | ||
Practitioner Guidance
What to prioritise: Treat token retirement as part of the trusted publishing rollout, not as a cleanup task. The release process is not hardened until every old publish path is either revoked or provably unreachable.
What to verify: Confirm that the registry rejects legacy credentials, that CI secrets no longer contain publish tokens, and that the only successful release path is the intended workflow-based one. If a token can still publish, assume the migration is incomplete.
Common mistake: Teams often enable trusted publishing and stop there. That leaves a parallel path alive, which preserves the original blast radius and defeats the main purpose of the change.
Practitioner takeaway: The security gain comes from shrinking publication to one controlled path, not from adding a better path while an older one still works.