npm now freezes high-impact accounts after risky account changes

What it is

A registry-level control from npm: high-impact accounts (packages with >1M weekly downloads or 500+ dependents — npm hasn't restated the threshold but the post infers it from the existing 2FA-enforcement policy) are frozen read-only for 72 hours after a sensitive action, with an alert to the previous email. The freeze auto-lifts. This doc carries the maintainer/consumer action list and the design rationale the summary omits.

How it works

The freeze blocks registry- and security-affecting actions — publishing, token management, package visibility changes, org membership changes — while leaving installs and downloads working. The trigger events are things npm can actually observe: an email swap or use of a 2FA recovery code. The key insight the post makes: in a takeover like axios, almost the entire attack chain (Slack social engineering, a RAT installed via a fake "system out of date" prompt on a video call, a live hijacked npm session) is invisible to the registry. The email change is the single step npm has any view into — attackers change it to sever the owner's recovery path and redirect alerts. The cooldown turns that one visible step into a delay-and-alert.

Where it fits

The three controls each cut a different path; the cooldown covers the one the other two route around:

flowchart TD
    A[Attacker goal: publish malicious version] --> B[Steal long-lived token]
    A --> C[Push unreviewed CI release]
    A --> D[Take over live account]
    B -.blocked.-> TP[Trusted publishing: short-lived OIDC, no token to steal]
    C -.blocked.-> SP[Staged publishing: human 2FA approval]
    D -.delayed + alerted.-> CD[72h cooldown]
    D --> E[Attacker can approve own staged package]

Trusted publishing does "a whole lot of nothing" once an attacker holds a live session; staged publishing can be bypassed by approving your own staged package. The cooldown is what handles the takeover case.

What to do

If you maintain a popular package:

• Confirm the email on your npm account is one you control and actively monitor — you'll miss the alert otherwise.
• Move to FIDO2 where possible.
• Treat an unexpected email-change notice as a security incident, not spam; contact npm support.
• If publishing from CI, configure trusted publishing as stage-only and disable tokens, so every release needs human approval and no long-lived credential exists to steal.

If you only consume packages, you benefit automatically — but many packages still don't enable these settings. The post points to Safe Chain by Aikido (the author's own tool), a free OSS wrapper for npm/npx/yarn that scans packages for malware pre-install and enforces a waiting period on new versions.

Caveats

The threshold is inferred, not restated by npm. The cooldown doesn't cover the self-approval bypass of staged publishing, and the Safe Chain recommendation is vendor self-promotion.