Topic starter
11/08/2026 3:15 pm
TL;DR: Akeyless reports that GitHub’s July 31, 2026 change forces live 2FA for npm account and package management, then moves publishing toward OIDC trusted publishing in January 2027 after the Mini Shai-Hulud campaign used one compromised npm token to push 639 malicious versions across 323 packages in 22 minutes. Standing credentials remain the real problem: once a token exists, attackers can steal, reuse, and chain it into wider machine identity compromise.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “npm Just Killed the Skeleton Key: What It Means for Every Other Credential You Own”.
Key questions
Q: What breaks when CI pipelines still rely on standing npm tokens?
A: Standing npm tokens turn a release workflow into a reusable identity artifact.
A: Long-lived tokens expand the window in which an exposed credential can be reused, especially when build and deployment systems have broad permissions.
Q: What are the signs that a release pipeline is over-reliant on machine identity secrets?
A: Common warning signs include tokens stored in CI variables, publish access shared across multiple jobs, and runners that can reach unrelated cloud or vault secrets.
Practitioner guidance
- Replace standing publish tokens with OIDC release identity Use OIDC trusted publishing for package release workflows wherever the registry and CI platform support it, so the credential exists only for the duration of a single run.
- Quarantine remaining npm tokens in the transition window Store any bypass-2FA npm tokens outside CI variables, restrict their use to the smallest possible egress path, and log every read and reissue event.
- Separate release credentials from adjacent secrets Keep cloud keys, signing certificates, database passwords, and registry tokens in different trust boundaries so a compromised runner cannot harvest them together.
Bottom line: The article shows that npm hardening is really about removing standing credentials from CI, not just making them harder to steal.
What's in the full article
Akeyless's full analysis covers the operational detail this post intentionally leaves for the source:
- How the transition from bypass-2FA npm tokens to OIDC trusted publishing affects release workflows and self-hosted runners
- How Akeyless positions secret storage, controlled reissue, and audit logging during the January 2027 transition window
- How the same secretless model is applied to cloud keys, signing material, and other machine identities in CI
- How privileged npm administration shifts into a PAM-style human access pattern under the new model
👉 Read Akeyless's analysis of npm token hardening and CI standing secrets →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
11/08/2026 3:28 pm
Standing CI secrets are now a governance failure, not a convenience choice. A reusable npm token creates a control problem because its authority outlives the workflow that needed it. That breaks the basic assumption that build credentials can be reviewed, rotated, and contained after the fact. Practitioners should treat token persistence as a design defect in machine identity governance.
A question worth separating out:
Q: Should teams prioritize OIDC trusted publishing over token rotation for npm releases?
A: Yes, when the registry and CI platform support it, because rotation still leaves a reusable secret in place between cycles. OIDC trusted publishing removes the standing credential entirely, which is a stronger control than trying to manage the lifetime of a token that should not exist in the first place.
👉 Read our full editorial: npm token hardening shows why standing secrets fail in CI pipelines
This post was modified 5 days ago by NHI Mgmt Group