PyPI extends two-factor authentication to every maintainer

A dependency does not have to be popular to put its consumers at risk. One compromised project can deliver hostile code to the people who install it, and those people may maintain other packages. Download counts identify large targets, but they do not describe all the routes through which an attacker can reach a developer. PyPI is using that argument to widen its account security requirements.

The May 25 announcement says every account maintaining a project or organization will need two-factor authentication by the end of 2023. This is an announced requirement with a staged rollout ahead, not a claim that all affected accounts are already enrolled today. PyPI plans to gate some site functionality and may select users or projects for earlier enforcement.

I rely on Python largely because of its libraries, which makes control over their release accounts part of the value of the ecosystem. A package can have excellent code and still become unsafe for consumers if an unrelated attacker gains the authority to publish its next version.

Popularity was a practical starting point

The announcement describes the preceding policy, introduced in July 2022, as covering the top one percent of projects by downloads. That approach concentrated protection on accounts with the broadest immediate reach. It also limited the disruption and support burden while PyPI gained experience with mandatory enrollment.

Extending the policy changes what the registry treats as the minimum requirement for maintaining software. Protection no longer depends on a package crossing a popularity threshold. A project can remain small and still have a release account whose compromise matters to its consumers.

This is a dependency problem with an administrative consequence. An application author usually chooses a set of libraries, including libraries selected by other dependencies. The security of that collection cannot be reduced to the download rank of its most visible component. Attackers can use whichever authorized upload path is available to them.

The announcement also points out that a compromised developer may maintain other PyPI projects. A successful attack can therefore affect more than the package through which it began. Protecting a less popular maintainer account can help prevent an attacker from acquiring a further route into the ecosystem.

Two-factor authentication addresses the case where an attacker knows a password but lacks the additional factor. It should not be interpreted as a guarantee that any uploaded distribution is trustworthy. The policy strengthens a condition under which PyPI grants account access. It does not inspect the intent of every change an authorized maintainer makes.

Human login and automated upload need different credentials

PyPI recommends enabling either a security device or an authentication app, with a preference for the security device. It separately recommends moving uploads to trusted publishing or API tokens. These recommendations address different interactions with the registry. A person signing into the website and a release job uploading distributions do not need to authenticate through the same mechanism.

The April trusted-publishing launch supplies the automation mechanism referenced in the May announcement. For GitHub Actions, a registered workflow can exchange an OIDC identity token for temporary upload authority. This avoids requiring a human to supply an interactive second factor for every automated upload.

The launch-day security model explains the limits of that arrangement. Project publishers remain independent of the users who registered them. Removing a human maintainer does not automatically remove their registered workflow publisher. Account enrollment and publisher configuration therefore need to be understood separately.

That distinction prevents a misleading conclusion about the new requirement. Enrolling every maintainer does not revoke every other credential or remove every external system authorized to upload. A project can have well-protected human accounts while retaining a workflow publisher whose repository no longer has the intended maintainers.

I prefer a release arrangement in which the human login protects administrative changes and the automated publisher has a defined project relationship. That makes the authorization easier to inspect. It also makes clear why a login policy cannot replace reviewing the systems that perform releases.

The boundary follows the ability to affect a project

PyPI is not announcing that every account must enroll immediately upon registration. The announcement distinguishes accounts with project authority from accounts without it. The latter impose less immediate risk to other users, while mandatory enrollment still brings costs for the account owner and the registry support team.

For users who do not yet maintain a project or belong to an organization, PyPI describes an expected future prompt when they attempt an action requiring the additional protection. Creating a project or accepting an invitation are examples. This connects enrollment to acquiring authority, while allowing the ordinary account registration process to remain separate.

The tradeoff is practical. A user has to retain another authentication method, and losing it may require recovery help. Administrators must investigate those requests carefully because restoring access can itself grant publishing authority. The announcement acknowledges these costs instead of treating enrollment as operationally free.

Support capacity influences the policy

The May explanation names increased confidence in PyPI two-factor support and the availability of trusted publishing as reasons the wider requirement is now feasible. It also identifies funding for a PyPI Safety and Security Engineer. Those are changes to the capacity supporting the policy, not changes to the underlying fact that stolen passwords can authorize harmful releases.

Account takeover investigations already consume a small group of volunteers. The announcement argues that preventing more of those emergencies lets account recovery become routine support work instead of repeated urgent incident response. That is an infrastructure sustainability argument as well as an account security argument.

Individual developers also depend on these protections. The announcement rejects limiting supply-chain security to corporate concerns, pointing out that individuals may have fewer resources for dependency investigation and recovery. Requiring an additional factor at the maintainer account places a shared control at the registry boundary. Every consumer of the affected project can benefit without independently reconstructing how its maintainer password is managed.