In early 2023, the Python Package Index (PyPI) began enforcing mandatory two-factor authentication for maintainers of critical projects. This wasn't a suggestion — if you maintained a package that PyPI classified as critical (top 1% by downloads), you needed 2FA enabled or you'd lose the ability to publish new versions. This policy shift represented one of the most significant security improvements in any major package registry's history.
Why This Happened
The decision came after years of account takeover attacks against PyPI maintainers. The pattern was painfully consistent:
- Attacker compromises a maintainer's email account or PyPI password
- Attacker publishes a new version of a popular package with malicious code
- Thousands of users download the compromised version before it's detected
- The malicious code steals credentials, installs backdoors, or mines cryptocurrency
Some notable examples that drove this decision:
- ctx package (May 2022): A popular Python package was compromised when the maintainer's account was taken over. The attacker published a version that exfiltrated environment variables.
- phpass package (May 2022): Another account takeover leading to credential-stealing malware being distributed.
- Multiple typosquatting campaigns: Hundreds of malicious packages were published on PyPI throughout 2022, many impersonating packages maintained by accounts without 2FA.
What "Critical" Means
PyPI defined critical projects as those in the top 1% by download count over the previous six months. This covered approximately 4,000 projects — packages like requests, numpy, flask, django, boto3, and pip itself.
The logic is straightforward: these packages are installed millions of times per day. Compromising any one of them would affect an enormous swath of the Python ecosystem. Requiring 2FA on these accounts provides disproportionate security benefit relative to the inconvenience.
The Implementation
PyPI's 2FA implementation supports both hardware security keys (WebAuthn/FIDO2) and TOTP (time-based one-time passwords via apps like Google Authenticator). They also support API tokens for automated publishing, which can be scoped to specific projects.
The rollout was phased:
- Notification: Maintainers of critical projects received emails and in-app notifications
- Grace period: A window to set up 2FA before enforcement
- Enforcement: Maintainers without 2FA could no longer upload new package versions
- Support: PyPI provided recovery options for maintainers who lost access to their 2FA devices
Industry Context: The Registry Security Gap
PyPI's move came as part of a broader industry recognition that package registries are critical infrastructure with insufficient authentication security.
npm's Parallel Efforts
npm had been on a similar trajectory, requiring 2FA for the top 100 packages by dependents and expanding the requirement over time. GitHub also invested in npm security by providing free hardware security keys to top package maintainers.
RubyGems
RubyGems.org began requiring MFA for accounts with more than 180 million total downloads, following a similar logic to PyPI's approach.
The Pattern
The industry converged on the same conclusion: the weakest link in package registry security was maintainer authentication. You can build the most secure package registry in the world, but if a maintainer's password is "password123" and they don't have 2FA, an attacker can publish malicious code through the front door.
Why Passwords Alone Don't Work
The maintainers of critical open-source projects are often individual developers, not corporations with security teams. They:
- Reuse passwords across multiple services
- Don't use password managers
- Have email accounts that may be compromised in data breaches
- Are targeted by phishing campaigns specifically because of their package maintainer status
A 2022 study found that over 18% of PyPI package maintainer email addresses appeared in known data breach dumps. That's 18% of accounts where an attacker might already have the credentials needed to publish malicious code to the Python ecosystem.
The Controversy
Not everyone was happy about mandatory 2FA. Some legitimate concerns were raised:
Accessibility: Some maintainers in regions with limited hardware availability couldn't easily obtain security keys. PyPI addressed this by supporting TOTP apps, which only require a smartphone.
Abandoned accounts: Some critical packages were maintained by developers who had moved on and weren't monitoring their PyPI accounts. The 2FA requirement highlighted the orphaned package problem — critical infrastructure maintained by people who aren't actively engaged.
Friction vs. security: Some maintainers argued that additional authentication friction would slow down their ability to publish security patches quickly. This is a valid concern but ultimately a trade-off worth making — the risk of unauthorized publishing far outweighs the 30 seconds needed to enter a 2FA code.
Open source sustainability: Several maintainers used the occasion to point out the broader problem: volunteer maintainers were being asked to add security processes without compensation, while companies worth billions depend on their work.
Impact Assessment
Six months after enforcement began, the results were clear:
- Account takeover attempts dropped significantly for critical packages
- No successful malicious version publications for 2FA-protected critical packages
- Increased adoption of API tokens for automated publishing, reducing the attack surface further
- Broader 2FA adoption across PyPI, even among non-critical package maintainers
The Remaining Gaps
2FA on critical packages is necessary but not sufficient. Several supply chain risks remain:
New Package Registration
Anyone can still register a new package on PyPI without 2FA. Typosquatting and dependency confusion attacks don't require taking over existing accounts.
Non-Critical Packages
The top 1% cutoff means the other 99% of packages — many of which are widely used — don't require 2FA. A package with 500,000 monthly downloads that's not in the top 1% is still a valuable target.
Build System Compromise
2FA protects against account takeover but not against compromised build systems. If a maintainer's CI/CD pipeline is compromised, malicious code can be published using legitimate, 2FA-authenticated credentials.
Dependency Chain Attacks
A critical package is only as secure as its dependencies. If a non-critical dependency of numpy is compromised, numpy itself is compromised, regardless of how strong the numpy maintainer's authentication is.
How Safeguard.sh Helps
Safeguard.sh complements registry-level protections like PyPI's 2FA mandate:
- Dependency Chain Analysis: Safeguard.sh doesn't just check your direct dependencies — it analyzes the entire dependency tree, identifying weak links in packages that might not meet the "critical" threshold for mandatory 2FA.
- Version Change Monitoring: When a package publishes a new version, Safeguard.sh analyzes the changes for suspicious patterns — new network calls, credential access, or obfuscated code — regardless of whether the maintainer used 2FA.
- SBOM Generation for Python Projects: Safeguard.sh generates comprehensive SBOMs for Python projects, giving you full visibility into what's installed and where it came from.
- Vulnerability Tracking: Safeguard.sh continuously monitors your Python dependencies against CVE databases and security advisories, alerting you when any package in your supply chain has known issues.
PyPI's 2FA mandate is a critical layer of defense, but it's one layer. Effective supply chain security requires visibility and monitoring at every level — from the registry to the build system to the deployed application.