What changed in npm 12
npm 12 reached general availability and is now tagged latest, turning on the install-time security defaults the team announced in June. The headline change: allowScripts defaults to off. Dependency lifecycle scripts, meaning preinstall, install, and postinstall, along with implicit node-gyp rebuilds, no longer run during installation unless you explicitly permit them. Two related defaults tighten the loop. The --allow-git flag now defaults to none, so git dependencies stop resolving, and --allow-remote defaults to none, blocking dependencies pulled from remote HTTPS tarballs. Together these turn npm install from a permissive command that executes arbitrary code into a restrictive one that asks first.
The release also softens one long-standing sharp edge. Unknown keys in .npmrc now warn instead of erroring outright, with an opt-in strict-npmrc mode for teams that want the old strictness back. The npm team is exploring backports of the v12 defaults to the Node 24 and Node 26 LTS lines, which matters because most enterprises pin to LTS and will not adopt a new major on day one. For anyone running a large JavaScript estate, this is the most consequential change to default install behavior in years, and it lands as a default rather than an opt-in.
Why install time is the real attack surface
The rationale is specific and grounded in recent history. npm's own framing is blunt: almost every worm and credential stealer that hit the registry since late 2025 ran at install time. Lifecycle scripts are the mechanism. A malicious package does not need you to import it or call its code. It only needs you to install it, at which point a postinstall script executes with the permissions of the developer or the CI runner. That is where credential theft, environment variable exfiltration, and self-propagating worms have repeatedly taken hold.
Blocking scripts by default removes that automatic execution path for the overwhelming majority of packages that never needed it. The legitimate cases, native modules that compile with node-gyp, become an explicit allowlist rather than a silent default. This is a deliberate trade of convenience for safety, and it inverts the historic assumption that installing a package is a safe read-only act. For security leaders who have spent two years worrying about software supply chain compromise, the default finally matches the threat model instead of trailing it.
The token deprecation timeline
npm 12 is also where the deprecation of 2FA-bypass granular access tokens begins, and it arrives in two phases. In early August 2026, granular access tokens configured to skip two-factor authentication lose the ability to perform sensitive account, package, and organization management actions. That covers password changes, 2FA settings, and package access modifications, the exact operations an attacker would want if they captured a token. Automating those changes with a long-lived token that dodges 2FA becomes impossible.
The second phase lands around January 2027 and hits publishing directly. 2FA-bypass tokens lose the ability to publish packages outright. Their remaining surface shrinks to reading private packages and staging a publish, where the package only goes public after a human completes a 2FA approval. The intent is to make the most dangerous automated action, pushing new code to millions of downstream consumers, require a person in the loop. Any team with tokens wired into release automation should read this as a hard deadline, not a suggestion.
What quietly breaks in your pipeline
The upgrade is not free, and the failures will be silent rather than loud. Plenty of build pipelines depend on install scripts without their maintainers knowing it. A postinstall that compiles a native addon, patches a dependency, or fetches a binary will simply not run under npm 12 defaults, and the failure may surface later as a missing artifact rather than a clear error at install. Git and remote-URL dependencies that teams added years ago for a fork or an internal package will stop resolving until explicitly allowed.
The safe path is to inventory before you upgrade. Audit which of your dependencies actually rely on lifecycle scripts, git URLs, or remote tarballs, then build an explicit allowlist for the genuine cases and remove the rest. This is exactly the kind of dependency hygiene that most organizations have deferred because the old defaults hid the cost. npm 12 surfaces it. The teams that treat the upgrade as a supply chain review rather than a version bump will come out with a smaller, better-understood attack surface.
The trusted-publishing endgame
Read the two changes together and the direction is clear. Blocking install scripts closes the inbound path where malicious code runs on developer and CI machines. Retiring 2FA-bypass tokens closes the outbound path where stolen credentials push malicious code to everyone else. The registry is being reshaped so that neither installing nor publishing is an unattended act of implicit trust. That is a structural answer to supply chain risk rather than a patch for the latest incident.
The token changes in particular steer teams toward trusted publishing via OIDC, where a CI provider proves its identity to the registry for a single job instead of holding a durable secret that can leak. For engineering leaders, this is the moment to move release automation off long-lived tokens and onto short-lived, verifiable identity. The deadlines are set, the phases are staged, and the registry is no longer going to accommodate the convenient-but-dangerous patterns that made the last two years of supply chain attacks so effective.
Your action list before the deadlines
There is a concrete sequence here. First, inventory every dependency that relies on install scripts, git dependencies, or remote-URL resolution, and decide which are legitimate. Second, build the explicit allowlists so your builds keep working under npm 12 defaults, and test in a staging pipeline before the LTS backports force the question. Third, catalog every 2FA-bypass granular access token in your automation and map it to what it publishes, because those tokens lose sensitive powers in August and publishing in January.
Then do the migration that makes the deadlines a non-event: move package publishing to trusted publishing with OIDC and put human 2FA approval on anything going public. None of this is glamorous, and none of it ships a feature your customers will notice. It is the unglamorous work that keeps a supply chain compromise from becoming your incident. The registry has finally set safer defaults. The remaining risk is a pipeline that upgrades without the inventory, discovers the breakage in production, and reaches for the escape hatch instead of doing the review.
