PyPI launched Organization Accounts in July 2023 (PyPI blog, "Introducing Organizations on PyPI," 25 July 2023) after what had effectively been two decades of a strictly individual-account model. For most of PyPI's history, every package was owned by a single user, and shared ownership meant adding other users as collaborators — a model that never really scaled to enterprise publishing or community-maintained projects with rotating maintainer teams. Eighteen months on, Organizations have had enough production use to draw real conclusions about what the security model actually provides and where its edges still are.
The Account Model in Summary
An Organization on PyPI is a named entity — for example, psf or numpy — that can own projects, have members, and act as a publisher. The critical structural difference from a user account is that Organizations decouple the publishing identity from any single human. Projects owned by an Organization are published under the Organization's name, members can be added and removed without affecting package ownership, and the organization itself persists across any individual membership change.
Organization membership has three role tiers: owner, billing manager, and member. Owners can manage membership, billing, and the set of projects the organization owns. Billing managers can do billing but not membership. Members can publish to the organization's projects subject to per-project role assignment. The role model is intentionally simpler than GitHub's fine-grained permissions — there is no "admin with read-only" or "publisher for these three projects only" as of January 2025, though the roadmap includes expansions.
What the Model Gets Right
The thing Organizations actually solve, and solve well, is the "what happens when a maintainer leaves" problem. Before Organizations, a package owned by an individual maintainer who changed jobs or lost interest was effectively stuck until the PEP 541 process transferred it, which could take months. With Organizations, removing a departing maintainer is a membership change, and publishing continues from the organization's identity without any PEP 541 involvement.
This matters more for enterprise publishers than for open-source projects. A company shipping a widely-used Python library under an Organization account is not exposed to the bus-factor risk that individual-account publishing has historically carried. If the one person who knew the publishing flow leaves, another owner can still ship.
Organizations also cleaned up the identity story for consumers. When you install openai from PyPI today, the project page shows it as published by the OpenAI organization, not by a named individual. This is a weak signal — nothing about Organization ownership is cryptographically verified to a corporate entity — but it's a better signal than the pre-Organization state, where corporate packages were often visibly owned by gmail.com personal accounts.
The Trusted Publishing Interaction
The most valuable single property of the Organization model is how it composes with Trusted Publishing (PyPI blog, "Trusted Publishers for All Packages," 20 April 2023). An Organization can configure trusted publishers for its projects at the organization level, binding the projects to a specific GitHub organization, GitLab namespace, or Google Cloud workload identity. Once configured, publishing requires both membership in the PyPI Organization and access to the CI environment that can mint the OIDC token.
This creates a layered identity model that was not available before. To ship a release, an attacker needs either a PyPI Organization member account (which, under 2FA enforcement, requires compromising a hardware credential) or control of the CI identity (which requires compromising the SCM). Neither alone is enough. In practice, this is a meaningful improvement on the pre-2023 world where a single API token leak was enough.
What It Still Doesn't Solve
Organizations are not a full enterprise identity layer, and it's worth being clear about what they don't do as of January 2025.
No domain verification. A PyPI Organization named microsoft is not automatically associated with Microsoft Corporation. There is no verified-by-DNS binding between an organization name and an external identity. PyPI admins do review Organization registrations and will reject obvious impersonations under PEP 541, but this is manual and not comprehensive. Consumers who trust microsoft on PyPI are trusting a name, not a verified entity.
No SSO integration. Organization members log in with their individual PyPI accounts, authenticated by individual 2FA. There is no SAML or OIDC integration to a corporate identity provider. This means membership lifecycle — onboarding and offboarding — is a PyPI-admin task, not something that flows automatically from the company's HR system.
No SCIM or fine-grained permission model. You can't scope a member to "can publish to these three projects but not these twenty." Membership is at the organization level, with per-project role assignments that are coarse. Enterprises with large Python publishing teams typically work around this with multiple Organizations rather than complex permission schemes within one.
No audit log access for Organization owners. Organization activity is logged on PyPI's side, but owners don't have programmatic access to their organization's audit stream. If you need a full record of who published what and when, you build it by watching publish events externally.
The Billing and Sustainability Story
PyPI Organizations ship as free for open-source projects (defined as projects distributing under OSI-approved licenses) and paid for commercial/closed-source usage. The free tier was the entire product for the first year; the paid Corporate Organizations tier rolled out later in 2023. Revenue from Corporate Organizations funds PyPI's operational sustainability, which is a model worth noting from a supply-chain-security perspective — the registry's financial health is part of its security posture.
As of early 2025, Corporate Organization pricing is in the $5-50/user/month range depending on tier, with the bulk of the value being access to private organization features and priority support. Commercial publishers who are currently shipping from a personal PyPI account should strongly consider the migration — the pricing is trivial for the risk reduction involved.
Migration Patterns
For an organization migrating from individual-account publishing to Organization-based publishing, the pattern that works:
Create the Organization first, with at least two owners from different reporting lines. Migrate low-risk projects first — an internal tool, a minor utility — to validate the workflow. Migrate high-visibility projects in a planned window with the security team available. Update CI workflows to use the organization's Trusted Publishing configuration rather than account-scoped API tokens. Retire the individual accounts' ability to publish to migrated projects, but keep the accounts alive for a while to handle edge cases.
The migration typically surfaces undocumented assumptions — someone's personal account was the only one that could publish a critical internal library, nobody realized. Budget 2-4 weeks for a real migration, not a weekend.
Where the Model Is Likely to Evolve
The PyPI roadmap discussions through 2024 have pointed toward several expansions of the Organization model in 2025 and beyond:
Fine-grained permissions per project within an Organization. SSO integration for Corporate Organizations. A machine-readable audit log for Organization owners. Possibly, organization-namespaced packages under the PEP 752 discussion, which would tie organization identity more tightly to the package namespace itself.
None of these are committed features as of January 2025, but they are recurring themes in the public discussions on discuss.python.org and in PyPI team talks at PyCon US 2024.
How Safeguard Helps
Safeguard tracks which of your consumed PyPI packages are published by Organizations versus individual accounts and flags supply-chain risk when a corporate dependency is shipped from a personal-email account — a common legacy pattern worth migrating. For organizations publishing through PyPI Organizations, Safeguard monitors member changes, publish events, and the configured Trusted Publisher bindings, alerting when a publish arrives from outside the expected CI identity. Combined with Safeguard's policy engine, this lets security teams gate production deployments on packages published from verified organizational identities with Trusted Publishing in place.