What breaks when a long-lived npm token is left active after adopting OIDC publishing?

The newer publishing path stops being authoritative because the fallback credential can still authenticate. That creates a hidden bypass route for anyone who steals the legacy token. The practical failure is not just weak access control, but incomplete lifecycle closure, where a retired credential remains able to publish packages and override the intended identity flow.

Why This Matters for Security Teams

Leaving a long-lived npm token active after moving to OIDC publishing creates two parallel trust paths: the intended federated identity path and the old static credential path. That matters because package publishing is not just a build-step convenience; it is a software supply chain control point. If the legacy token remains valid, compromise of that token can bypass the newer authentication flow entirely, even when OIDC is correctly configured. NIST SP 800-53 Rev 5 Security and Privacy Controls treats credential lifecycle management and access enforcement as core controls, not optional hygiene. In practice, many security teams encounter this only after a package overwrite, credential leak, or dependency incident has already turned a retired token into an active attack path.

The issue is similar to what NHI research highlights in secret sprawl and token persistence: a new control does not eliminate an older one unless revocation is completed. NHIMG’s Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs — Static vs Dynamic Secrets both frame this as a lifecycle failure, not a point-in-time misconfiguration. The practical risk is hidden bypass, not just weak access control.

How It Works in Practice

OIDC publishing is meant to replace a reusable secret with a short-lived, identity-bound exchange. The publisher proves its workload identity at runtime, receives a temporary authorization decision, and completes the publish without storing a long-lived credential. That model is stronger because the trust decision is tied to the current build context, branch, repository, or environment rather than a static token that can be copied and replayed later.

When the old npm token is still active, the system now has two acceptable authentication methods:

• the new OIDC flow, which is intended to be the authoritative path;
• the legacy token, which remains valid until explicitly revoked.

That creates several operational problems:

• incident responders may assume the migration is complete when it is not;
• attackers who obtain the old token can publish without using OIDC at all;
• policy changes in the federated path do not apply to the fallback token;
• audit trails become ambiguous because publish events can arrive through different trust mechanisms.

This is why identity migration needs revocation as a first-class step. NHIMG’s Shai Hulud npm malware campaign shows how package ecosystems turn exposed credentials into supply chain abuse, while Salesloft OAuth token breach demonstrates the same pattern in a different system: one valid token is enough to defeat the intended authentication design. NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the operational need for access revocation, credential inventory, and separation of duties. These controls tend to break down when CI/CD is distributed across many maintainer accounts because no single team owns the full credential retirement path.

Common Variations and Edge Cases

Tighter publishing controls often increase release overhead, requiring organisations to balance stronger assurance against developer friction and emergency-release speed.

There is no universal standard for this yet, but current guidance suggests the safest pattern is to treat OIDC as a replacement, not an additive option. If both methods remain enabled indefinitely, the organization preserves a hidden exception path that undermines the migration. In practice, teams need to decide whether the legacy token is disabled immediately, kept only for a short overlap window, or removed after validation of all repository and automation workflows.

Edge cases often appear in:

• multi-repo organisations where one package owner forgot to rotate the old token;
• third-party automation that still depends on the legacy credential;
• disaster recovery plans that quietly retain a fallback secret “just in case”;
• shared maintainer accounts where the token is copied into multiple environments.

The strongest control is to combine short-lived OIDC authentication with explicit inventory and revocation of every older publishing token. NHIMG’s research on the Guide to the Secret Sprawl Challenge is relevant here because duplicated or forgotten secrets are what keep these bypasses alive. Best practice is evolving, but the operational rule is clear: if the legacy token can still publish, the migration is not finished. The failure usually shows up first in package provenance investigations, not during the rollout itself.

Related resources from NHI Mgmt Group

• What breaks when MCP access is left on long-lived tokens?
• What breaks when API keys are left active after a project ends?
• What breaks when npm install scripts can access long-lived credentials?
• What breaks when a SaaS integration credential is left active after a project ends?