NPM strengthens safety with ephemeral tokens and OIDC, but the supply chain is still at risk

In December 2025, npm applied a profound change in its authentication system to reduce the risk of supply chain attacks: it revoked the so-called "classic tokens" and promoted session tokens and OIDC-based flows. It is a significant improvement in default defenses, but it does not completely eliminate the possibility of a malicious actor publishing harmful code.

For years the basis of the problem was simple: the old credentials were long valid, with a wide range, and if they fell into the wrong hands they allowed to publish new versions of packages without having to prove the source of the code. That model made npm an attractive target for those who seek to insert malware directly into highly used libraries. Well documented incidents in the ecosystem have shown how committed credentials are enough to cause large and rapid damage.

The npm response focused on three ideas: short expiry of interactive credentials, better tokens management and promoting the use of identities linked to CI executions through OIDC. You can read the official explanation of these changes in the npm team ad Here.. In practice this means that, for normal operations, interactive tokens expire quickly and publications may require multifactor authentication.

However, real security depends on both technical improvements and how people and equipment use them. Two key points still open the door to attacks. First, phishing attacks aimed at multifactor authentication remain effective: if a maintainer is misled and delivers his password and a second factor code, an attacker can get a valid session token and publish a malicious version within minutes.

Second, the platform continues to allow for flows thought for automation that, if configured with MFA bypass or long-term tokens (for example, 90-day tokens), essentially recreate the previous problem. That is, the existence of permanent tokens or with omitted MFA retains an important risk vector when those secrets are stored or exposed in CI / CD systems.

This leads to a practical conclusion: npm improvements reduce the exposure window and increase the difficulty for the attacker, but do not eliminate it. As long as there are ways to generate persistent credentials or to deceive a human to deliver credentials of a single use, there will always be an unauthorized publication risk.

In specific terms of mitigation, three complementary lines of work should be promoted. The first is the broad adoption of ODO in the CI integrations; using tokens linked to a specific and very short-lived execution drastically reduces the utility of any stolen secret. GitHub offers documentation on how to configure OIDC for deployments that can serve as a practical reference: set OIDC in GitHub Actions.

The second line is to tighten MFA policies and minimize exceptions: not allowing tokens to avoid the additional factor for publishing operations and forcing MFA on the console reduces the possibility that a phishing is sufficient to publish code. The guidelines on phishing prevention and good authentication practices published by agencies such as CISA help to understand why even users with MFA can be victims if no additional controls are combined: recommendations on phishing (CISA).

The third line goes beyond authentication: reexamine how the artifacts reach our environments. If instead of downloading pre-compiled packages from the registry we reconstruct each unit from your verifiable source code, the risk that a released version with malware will reach our supply chains is much reduced. A practical investigation by Chainguard maintains that, in its public database of committed packages, most of the cases investigated showed malware present only in the published package, not in the upstream source code. You can check that analysis at the Chainguard site: Chainguard: mitigating malware in npm.

This "reconstruct from the source" approach is not trivial: it involves investing in reproducibility, signature of artifacts and chains of trust, but has a tangible effect on reducing the attack surface. Tools and services that provide verifiable built libraries can fit into an in-depth defence model that combines strict access policies, audit and verification in time of implementation.

In the end, what draws attention is that there is no single miraculous solution. Effective safety is a sum of layers: good practice in the management of credentials, widespread use of OIDC for automation, compulsory MFA in sensitive actions and, where possible, verified reconstruction of devices from the source. Each measure reduces the remaining risk left by the others.

For projects and organizations this translates into concrete decisions: to review and rotate tokens, to enable MFA and to remove bypass exceptions, to migrate pipelines to OIDC when feasible, and to consider the adoption of repositories or services that ensure that what is installed comes from the verified source code. Practical recommendations and public tool guides - such as GitHub's for OIDC or incident analysis of security providers - are useful resources for planning this transition.

npm has moved in the right direction by changing the default policies and eliminating peremptory credentials. Still, as long as human vectors (phishing) exist and the possibility of generating long-term tokens, the threat over the supply chain remains. The most sensible thing for the community is to combine improvements in the platform with changes in processes and in the adoption of technologies that raise the barrier for an attacker to the point that exploiting the system will no longer be profitable.

If you want to deepen the background and specific cases of how the credentials committed in the past have been used, Snyk offers an informative analysis of the incident "event-stream," one of the most cited examples of the JavaScript supply chain attack: analysis of the incident event-stream (Snyk). And if you are interested in exploring technical alternatives focused on building artifacts from the source, Chainguard's documentation on its JavaScript libraries explains that approach with examples and data.

In conclusion, it should be recalled that this article is based on work and analysis of the technical community. The recommendations do not seek to alarm, but rather to put into perspective that the npm improvements reduce risk but do not disappear it, and that the most effective response is to combine technical controls with operational hygiene and source verification.