One Identity Vendor or Many Across a PE Portfolio

At the level of a single portfolio company's product, the Auth0 versus Clerk decision comes down to the same fundamentals as anywhere else: team size, whether enterprise SSO is a current sales requirement, and how much engineering bandwidth exists to own a more configurable tool. A portco with a lean engineering team and a self-serve sales motion is usually better served by Clerk's faster path; one with an enterprise sales motion already underway benefits from Auth0's federation depth.

The wrinkle unique to a PE-owned company is that this decision often gets made, or remade, right after a platform investment, when a new operating team arrives and inherits whatever the prior team set up, sometimes without full documentation of why.

PE firms often push standardization across portfolio companies for systems like accounting platforms or HR software, where the operational efficiency gains are clear and the underlying business needs are similar enough across the portfolio. Identity infrastructure doesn't standardize as cleanly, because a portco's authentication needs are downstream of its specific product and customer base, not a shared back-office function every portco needs in roughly the same shape.

An operating partner used to seeing clean efficiency gains from standardizing a back-office system can reasonably expect the same from identity, and that expectation is worth correcting early rather than after a portco's engineering team has already pushed back on a mandate that doesn't fit its product.

Forcing a portco with enterprise SSO requirements onto Clerk because it's the portfolio standard, or forcing a self-serve portco onto Auth0's heavier configuration because that's what a sister company uses, tends to create friction without the efficiency gain standardization is supposed to deliver.

What does transfer well across the portfolio is the evaluation process itself: a shared framework for how a portco's operating team should weigh the Auth0-versus-Clerk decision, and a shared vendor relationship for compliance tooling like Vanta or Drata that plugs into either identity provider. This gives the firm's operating partners a consistent lens to evaluate a portco's identity choice without dictating the specific product, which respects that each portco's technical needs genuinely differ.

Whichever tool a portco chose, a future acquirer's technical diligence team will ask about it, specifically how well-documented the configuration is and whether the choice was deliberate or accidental. A portco that can explain, with documentation, why it's on Auth0 or Clerk and how the setup maps to its customer base signals operational maturity in a diligence process that a portco with an undocumented, ad hoc identity setup does not. This is a smaller line item than most diligence findings, but it's the kind of detail that compounds with others into a buyer's overall impression of how well-run the business is.

Don't mandate a portfolio-wide identity vendor. Instead, require every portco to document its identity provider choice and the reasoning behind it as part of standard technical hygiene, the same way you'd expect documentation for any other core system. Review that documentation during quarterly technical check-ins, and flag any portco whose setup looks undocumented or accidental rather than deliberate, since that's the actual risk worth managing at the portfolio level, not which specific vendor a given portco happens to use.

Operating partners can apply this in three steps:

1. Decline to mandate a single identity vendor across the portfolio, since each portco's needs and engineering capacity differ.
2. Require every portco to document its identity provider choice and the reasoning behind it, as it would for any other core system.
3. Review that documentation during quarterly technical check-ins, and flag any portco whose setup looks undocumented or accidental.

The one place standardization genuinely does make sense is a shared services layer the firm itself operates, such as a portfolio-wide reporting tool or a holding-company system used by finance staff across multiple portcos. That system isn't downstream of any single portco's product or customer base, it's the firm's own infrastructure, and it's fair to treat it like any other firm-level system decision, choosing one identity provider deliberately rather than letting it inherit whatever a given portco happened to already use.

Keep this carve-out narrow and explicit, though, so it doesn't quietly expand into the argument for standardizing every portco's customer-facing product identity, which is the mandate this whole approach is deliberately avoiding.