Tokens Expiring Tomorrow: Why npm Permanently Retired 'Classic Tokens'

Image Unavailability Note: GitHub/npm official security policy documents and token management UI screenshots are copyright-protected and subject to real-time changes, making long-term URL acquisition impossible. This article is text-focused.

Tomorrow Morning, Your CI/CD May Stop

On the morning of February 24, 2026, npm tokens for millions of developers worldwide will expire simultaneously. This is the day when Granular Access Tokens named "NPM_TOKEN" complete their 90-day validity period and disappear. When these tokens vanish, automated deployment pipelines will halt, package publishing will fail, and GitHub Actions workflows will light up red.

This is not merely a technical inconvenience. It's a signal of a massive shift in software supply chain security.

TL;DR

• December 9, 2025: GitHub npm permanently retired expiration-free 'Classic Tokens'
• Granular Access Tokens (GAT) mandatory migration: 90-day maximum validity, scope restrictions
• February 24, 2026: First-issued GATs set to expire → concerns of large-scale CI/CD failures
• Background: Surge in supply chain attacks including September 2025 Shai-Hulud worm
• Alternative: Trusted Publishing (OIDC) migration recommended

📌 Facts: What Happened

The End of Classic Tokens

On December 9, 2025, GitHub permanently retired Classic Tokens (long-term tokens) from the npm registry. These tokens, usable indefinitely without expiration dates, were the most common method developers used to authenticate packages in CI/CD pipelines.

Existing Classic Tokens no longer authenticate and cannot be regenerated. Developers must choose one of two options:

1. Granular Access Tokens (GAT): 90-day maximum validity, permission scope restrictions, manual renewal required
2. Trusted Publishing (OIDC): OpenID Connect-based, automatic authentication from GitHub Actions/GitLab CI without tokens

February 24, 2026: The First Expiration Date

Tokens from developers who migrated to GAT in November-December 2025 will expire en masse on February 24, 2026 (tomorrow). npm sent warning emails titled "Granular access tokens expiring tomorrow" to millions of developers today (February 23).

Without token renewal:

• CI/CD pipeline interruption: npm publish failures in GitHub Actions, GitLab CI, Jenkins, etc.
• Automated deployment disabled: Manual token reissuance and CI environment variable updates required
• Project release delays: Emergency patch deployment impossible

🔍 Expansion Factors: Why Did GitHub Force This?

September 2025: The Shai-Hulud Worm Incident

On September 8, 2025, the Shai-Hulud worm attack shook the npm ecosystem. Attackers sent phishing emails (support@npmjs.help) targeting package maintainers to steal 2FA credentials.

Attack Process:

1. Send fake "2FA update required" emails to maintainers
2. Real-time theft of IDs, passwords, OTPs via man-in-the-middle (AiTM) attacks
3. Obtain write permissions to 18 core packages using stolen sessions
4. Inject malicious code into packages depended upon by tens of thousands of projects

This incident exposed the fundamental vulnerabilities of Classic Tokens:

• No expiration → Permanently usable once stolen
• Full permissions → Access to all packages
• Lack of audit logs → Delayed attack detection

@ctrl/tinycolor Incident: GitHub Actions Workflow Attack

In the second half of 2025, the @ctrl/tinycolor package (2 million weekly downloads) was infected with malicious code. Attackers pushed malicious code to GitHub Actions workflows in a collaborative repository to steal npm tokens and deployed malicious versions to 20 packages.

This incident demonstrated the limitations of "token-based authentication." If tokens are stored in CI environment variables, attackers who manipulate workflows can steal them at any time.

🧠 Context and Background: Paradigm Shift in Software Supply Chain Security

Surge in Supply Chain Attacks

The Node.js ecosystem has deep dependency chains. A single package depends on dozens to hundreds of other packages, which in turn depend on other packages. Attackers can infect tens of thousands of projects by compromising just one package at the bottom of this chain.

Statistics (GitHub Security Research Team):

• npm supply chain attacks increased 300% in 2025 compared to 2024
• Maintainer account theft via phishing is the most common attack vector
• Average detection time: 72 hours (after malicious code has already spread to thousands of projects)

Classic Tokens vs. Granular Access Tokens

GAT enforces the principle of least privilege. By restricting a single token to access only specific packages, damage can be minimized when tokens are stolen.

Trusted Publishing: A Token-Free Future

GitHub's most recommended approach is Trusted Publishing (OIDC-based).

How It Works:

1. Execute npm publish from GitHub Actions workflow
2. GitHub automatically issues short-term OIDC token (lifespan: minutes)
3. npm trusts GitHub's OIDC provider for authentication
4. Token not stored in environment variables → Cannot be stolen

Advantages:

• No token renewal needed → Eliminates operational burden
• Automatic Provenance generation → OpenSSF standard compliance
• Defense against workflow manipulation attacks → Tokens not exposed

Limitations:

• Only supports GitHub Actions, GitLab CI (no Jenkins, CircleCI, etc.)
• Requires extensive workflow modifications
• Learning curve

🔮 Outlook: Renewal Hell Every 90 Days, or OIDC Migration

Short-term: Token Renewal Automation War

Most developers will continue using GAT for now. The problem is renewal every 90 days.

Automation Strategies:

1. Calendar reminders: Register renewal schedules in Google Calendar, Notion, etc.
2. Token management tools: Track expiration dates in Vault, 1Password, AWS Secrets Manager, etc.
3. Script automation: Generate tokens via CLI and automatically update CI environment variables

However, this significantly increases operational burden. A team managing 10 packages must perform 40 token renewals annually.

Mid-term: Accelerated OIDC Migration

In the first half of 2026, when token renewal fatigue reaches a critical point, OIDC migration will gain momentum.

Expected Scenario:

• Q1-Q2: Major open-source projects (Next.js, Vite, React, etc.) publicly share OIDC migration cases
• Q3: Major CI platforms like Jenkins, CircleCI add OIDC support
• Q4: npm officially designates OIDC as the "default recommended method"

Long-term: New Standard for Software Supply Chain Security

OIDC will become the standard for all package registries, not just npm.

Expected Expansion:

• PyPI (Python): Already supports Trusted Publishing
• RubyGems: OIDC introduction planned for first half of 2026
• Maven Central (Java): Under discussion
• Docker Hub: GitHub Container Registry leading the way

Ultimately, "token-free publishing" will become the industry standard, and Provenance Attestations (proof of where, who, and how packages were built) will become mandatory requirements.

✅ Developer Checklist

What to Check Right Now

Mid-term Response (1-3 months)

Long-term Migration (3-12 months)

What to Avoid

• ❌ Committing tokens to code repositories
• ❌ Sharing one token across multiple packages (entire damage on compromise)
• ❌ Indiscriminate use of "Bypass 2FA" option
• ❌ Ignoring token expiration and attempting renewal on deployment day

🔗 References

1. GitHub Changelog: npm classic tokens revoked (2025-12-09)
2. npm Docs: About Granular Access Tokens
3. GitHub Security: Our plan for a more secure npm supply chain
4. The Hacker News: npm's Update to Harden Their Supply Chain
5. CIO Korea: 깃허브, NPM '클래식 토큰' 전면 폐기
6. OpenJS Foundation: npm Security Best Practices
7. Socket.dev: npm Revokes Classic Tokens

Conclusion: Don't panic when you receive token expiration notifications tomorrow morning. This is not just an inconvenience, but part of the journey toward a more secure development ecosystem. If the 90-day renewal cycle feels burdensome, now is the time to seriously consider OIDC.