Feel free to add passkeys if you want, but do not remove TOTP.
This demand epitomizes the friction GitHub has generated with its latest wave of security measures for npm.
It announced the stance at the end of September 2025, following a large-scale attack on the package manager. In the weeks that followed, the classic legacy tokens would be removed. As for granular tokens with write permissions, they could no longer enjoy an unlimited lifetime. By mid-October, lifespans were to be capped at 90 days—and to 7 days by default (down from 30 previously).
The timing for removing TOTP was (far) too tight
GitHub also planned that after a period of “a few months,” strong TOTP-based authentication would no longer be available. That decision was largely justified by the protocol’s vulnerability to phishing and relay attacks. Risks to which, it argued, passkeys are not exposed, even if the generator itself is compromised.
Within the npm community, it was pointed out that the passkey approach was not ideal for automated systems. And that, in fact, it was rather convenient to publish from the terminal without having to authenticate in a browser. Some were more forthright, invoking a lock: “Passkeys aren’t that portable.”…
In the end, GitHub stayed the course… but pushed things far into the future. In February, it again explained that it did not intend to remove TOTP until the rest of its security measures had been widely adopted.
Des tokens finalement un peu moins éphémères
The removal of classic tokens was also postponed multiple times. It ultimately occurred in early December. For local publishing, it was replaced by ephemeral tokens, initially valid for 2 hours. When pressed about the constraints this imposed, GitHub eventually widened the window to 12 hours. It also recommended limiting these tokens to publishing and using granular read-only tokens for ongoing access to private packages.
Alongside the cap on the lifetime of write-enabled granular tokens, the standard package configuration evolved. At creation, 2FA is now enabled by default, gating any publication.
GitHub serre la vis sur les scripts install
The latest measure will take effect with npm v12, slated for July (for now it emits alerts). It disables by default the execution of preinstall, install and postinstall scripts from dependencies. This includes native node-gyp builds (which perform an implicit node-gyp rebuild). So beware of packages like bcrypt, canvas, sharp and database drivers. Also Cypress, Playwright and Puppeteer, but for a different reason: they download binaries via postinstall.
Another behavior will disappear by default: the resolution of dependencies from remote URLs (–allow-remote), including https tarballs. The same applies since February to the resolution of direct or transitive Git dependencies (–allow-git). It blocks a vector for code execution (a dependency’s .npmrc could bypass the executable, even with –ignore-scripts).
For now, GitHub has not announced any change in behavior for the flags –allow-file and –allow-directory.
Le trusted publishing, en manque de fournisseurs CI/CD
The removal of TOTP will likely depend on the rollout of trusted publishing. This feature implements a standard defined by OpenSSF. It uses OIDC authentication to establish a trust relationship between npm and CI/CD providers. PyPI was the first package manager to adopt it, in 2023. On npm, it has been available since July 2025, but it still only supports three services:
- GitHub Actions (managed runners)
- GitLab CI/CD (shared runners)
- CircleCI (cloud version)
The batch configuration of trusted publishing is relatively new (February 2026). Malware detection in dependencies with Dependabot is even newer (March)… at least in its new incarnation. GitHub had suspended the previous version in 2022, due to the volume of false positives reportedly caused by naming conflicts between public and private packages.
