Every identity system eventually gets tested by the same question: what happens when the user loses their second factor? PyPI has made real progress on authentication since it began rolling out mandatory two-factor authentication in 2023 (PyPI blog, "Securing PyPI accounts via Two-Factor Authentication," 8 July 2023), but recovery is where the trust model actually gets interesting. A maintainer who can't log in is one support ticket away from either locking themselves out of a widely installed package or handing their account to somebody who shouldn't have it. I spent a week in February 2024 reading through the Warehouse source, filed help threads, and PEP notes to map what the recovery model looks like in practice.
What PyPI Actually Offers Today
As of March 2024, PyPI account recovery is a fairly narrow surface compared to, say, GitHub or npm. There is no in-product self-service way to reset 2FA without an active session. If you still have one of your 2FA methods, you can log in, remove the lost factor, and enroll a new one. If you don't, you need the recovery codes that Warehouse generated when 2FA was first enabled. The help page at pypi.org/help confirms this explicitly: "If you have lost access to your 2FA methods and do not have your recovery codes, you will not be able to recover access to your account."
That sentence is doing a lot of work. It's the deliberate result of a threat model where email-based reset of 2FA would undo the protection that mandatory 2FA was meant to add. Donald Stufft and the PyPI admins have been consistent on this point in their public writing: a recovery flow that bypasses the second factor is just a second authentication factor by another name, and usually a weaker one.
Where Recovery Actually Happens
In practice, most lost-device cases land in one of three buckets.
The first is recovery codes. When you enroll TOTP or a WebAuthn key, Warehouse issues eight one-time recovery codes. Pull the codes from the enrollment page, print them, store them somewhere that isn't the same laptop. This is the only flow that works without human review.
The second is a second factor that still works. PyPI supports multiple WebAuthn credentials and TOTP simultaneously, so a maintainer with a YubiKey at home and another in a desk drawer can usually get back in even after one device is lost. The Warehouse documentation encourages registering at least two WebAuthn credentials for this reason.
The third is account abandonment. If neither recovery codes nor a backup factor exists, the account is effectively gone. The admins will not perform identity-verified 2FA resets. What they will do, under the PEP 541 process ("Package Index Name Retention," accepted March 2020), is transfer ownership of specific package names to a new account after a period of demonstrated non-response from the original maintainer. That's a package recovery path, not an account recovery path, and it's slow on purpose.
The Email Question
Email remains the one soft spot. A compromised email account can reset the PyPI password, and in the pre-2FA world that was enough. With 2FA enforced, the attacker who owns your email still can't log in without your second factor — but they can potentially intercept recovery-code delivery if you ever ask for new ones. Warehouse sends new recovery codes through the verified email on file, and it does not require re-authentication with the existing second factor before issuing them in every flow. I'd argue this is the single most interesting edge for threat modelers to look at, and it's one the PyPI team has been iterating on through 2023 and into 2024.
The practical mitigation is straightforward, if unglamorous: the email address you use for PyPI should have its own hardware-backed 2FA, should not be a shared team alias, and should not be the same account you use for package-related correspondence on GitHub issues and Stack Overflow. Attackers scrape these associations.
Organization Accounts Change the Math
The July 2023 launch of Organization Accounts (PyPI blog, "Introducing Organizations on PyPI," 25 July 2023) added a real lever that individual maintainers didn't have. Organization owners can now manage membership and publish rights for team members, which means losing one member's 2FA doesn't lock an organization out of its own packages. Another owner simply revokes the lost account and re-invites a new one.
For anyone shipping a business-critical package under a single personal account, migrating to an organization is probably the most important recovery improvement you can make in 2024. It moves the recovery question from "can I recover this one account" to "do I have at least one other owner who can recover for me," which is a much softer failure mode.
Trusted Publishing as a Side-Door Recovery
PEP 740 and the associated Trusted Publishing rollout (PyPI blog, "Trusted Publishers for All Packages," 20 April 2023) changed the recovery surface in a way that's easy to overlook. When a package is configured to publish from a GitHub Actions, GitLab, or Google Cloud workload identity, the PyPI account's ability to issue API tokens stops being the only path to publish. The identity provider's OIDC token becomes a parallel credential. If your PyPI account is locked out but your GitHub organization is healthy, new releases can still go out from CI. The account is locked; the supply chain is not. This is the first time PyPI has had anything close to a credential-independent publish path, and it changes how teams should think about publisher redundancy.
What I'd Change If I Were Planning for an Outage
From a pure security-engineering perspective, here's what I'd do this week if I maintained a top-1000 PyPI package:
Store recovery codes in a team password manager, not a personal one, and document the retrieval procedure. Register at least two WebAuthn credentials with physically different keys. Migrate personal-account packages to a PyPI Organization with at least two owners. Configure Trusted Publishing from the CI system that already builds your releases, so a locked maintainer account doesn't halt shipping. Treat the email address on file as a security-critical identity of its own, with hardware 2FA, session expiry, and no shared access.
None of this is novel advice in isolation. What's new in 2024 is that PyPI finally has the primitives — Organizations, Trusted Publishing, multiple WebAuthn — to make the advice actually work end-to-end.
How Safeguard Helps
Safeguard tracks the provenance of every package your builds pull from PyPI, including which identity published it and whether that identity matches the repository's Trusted Publisher configuration. When a publisher changes hands, when a long-dormant account suddenly ships a release, or when a package begins publishing from a new OIDC identity, Safeguard flags the event in your supply-chain timeline. This lets security teams catch account recovery and takeover incidents at the point of consumption, not weeks later when somebody files an advisory. For teams managing their own PyPI Organizations, Safeguard also monitors which of your internal publisher identities are active and alerts when a previously quiet credential starts pushing releases.