npm Overhauls Authentication to Reduce Supply Chain Risk but Attacks Still Possible

npm has completed a major update to how developers authenticate when publishing packages. The change aims to reduce the risk of supply chain attacks by replacing long-lived publish tokens with short-lived session-based credentials and stronger identity integrations. The new system also encourages OpenID Connect (OIDC) Trusted Publishing for continuous integration (CI) workflows.

While these improvements increase security, experts warn that npm projects remain vulnerable to account compromise and supply chain abuse if multi-factor authentication (MFA) is bypassed or poorly configured. Official npm documentation and recent incident analysis show the ecosystem still has risk to manage.

What changed and why it matters

In late 2025, npm announced major changes to tokens used for publishing packages. Historically, npm relied on classic tokens. These tokens were long-lived and broad in scope. If a classic token was stolen, attackers could publish malicious updates under a maintainer’s name for months without further verification.

The npm team wrote that the classic token model made supply chain attacks easier because stolen credentials could persist indefinitely. npm now uses session-based tokens by default and disallows classic tokens for new workflows. npm states: “Credential rotation and limited-lifetime tokens significantly reduce the risk associated with stolen credentials.”

Session tokens expire quickly, often every two hours. This limits how long stolen credentials remain valid. npm also makes MFA the default requirement for publishing, and short-lived tokens must be obtained via a logged-in session.

OIDC Trusted Publishing and why it helps

npm encourages developers to adopt OIDC Trusted Publishing. With OIDC, CI systems like GitHub Actions or GitLab pipelines can request per-run credentials from the identity provider. These credentials are tied to the specific workflow run and expire automatically.

OIDC reduces risk because:
Compromised CI secrets do not grant indefinite publish rights.
CI tools no longer need to store long-lived tokens.
Each run gets a temporary, limited credential.

What supply chain risk still looks like

Token changes make it harder for attackers to reuse stolen credentials for long periods. However, there remain scenarios where attackers can still publish malicious code.

MFA bypass tokens

npm still allows developers to create 90-day tokens that bypass MFA if configured as such in account settings. These tokens behave similarly to the old classic tokens, offering broad access for an extended period.

Security analysts point out that if attackers gain access to a console where such tokens exist, they can publish malicious packages or versions. A maintained advisory from GitHub Security notes: “Any token that bypasses MFA poses a risk to the package ecosystem because it allows attackers to push releases without interactive verification.”

Phishing and social engineering remain effective

Recent high-profile attacks on npm for packages like ChalkJS show that credential theft often begins with MFA phishing and social engineering. Even with session tokens and MFA, attackers can trick maintainers into handing over one-time passwords or session cookies, allowing them to publish malicious updates.

What’s improved and what isn’t

Change	Status	Notes
Classic tokens revoked	Yes	Long-lived tokens no longer work for publishing
Default MFA on publish	Yes	MFA is now standard
Session tokens	Yes	Short–lived, two-hour tokens
OIDC Trusted Publishing	Supported	Recommended for CI workflows
MFA-bypass 90-day tokens	Still allowed	Optional unless policy enforced
Malware-immune ecosystem	No	Supply chain threats remain

These improvements reduce the window attackers have to abuse credentials. They do not eliminate the underlying risk of account compromise.

Practical recommendations for developers

• Enable MFA everywhere. Do not allow MFA bypass tokens unless absolutely necessary.
• Use OIDC for CI/CD automation. Avoid storing publish tokens in repository secrets.
• Rotate tokens often. Prefer session tokens over long-lived ones.
• Audit package maintainers. Check if maintainers have strong account settings.
• Educate contributors. Train developers to recognize phishing attempts targeting MFA codes.

Security teams and maintainers should treat these steps as baseline hardening measures.

Practical recommendations for developers

• Enable MFA everywhere. Do not allow MFA bypass tokens unless absolutely necessary.
• Use OIDC for CI/CD automation. Avoid storing publish tokens in repository secrets.
• Rotate tokens often. Prefer session tokens over long-lived ones.
• Audit package maintainers. Check if maintainers have strong account settings.
• Educate contributors. Train developers to recognize phishing attempts targeting MFA codes.

Security teams and maintainers should treat these steps as baseline hardening measures.

Why supply chain security still matters

Supply chain attacks occur when attackers manage to inject malicious code into the software developers and end users trust. A compromised package can lead to widespread impact because it may be included indirectly through dependencies. In many cases, malicious packages do not modify the source code. Instead, they alter the published artifact, meaning the code in version control stays safe while the distributed package contains malware.

One supply chain study found that 98.5% of malicious packages did not contain malware in the upstream source code, only in the published artifact. This highlights the difference between secure source and insecure artifacts. Source: industry analysis.

Until identity and multimedia workflow guards become universal and default, npm projects continue to face risk from compromised CI systems, stolen credentials, or social engineering.

FAQ