The Identity Tax: Why Every Enterprise Customer Costs More Than You Think

The pitch to the board is always the same: land an enterprise logo, and the ACV justifies whatever it took to close the deal. What that math usually leaves out is that the deal doesn't end at signature. It starts a slow-drip tax on the engineering roadmap that doesn't show up on the deal's own P&L, because it doesn't get billed to that customer — it gets billed to every feature shipped afterward, for every customer, indefinitely.

Here's what that tax actually looks like, deal by deal, on a fairly ordinary SaaS sales trajectory.

Customer 1: Azure AD

The first enterprise deal always feels like a one-off. Security review comes back with a single line item: "Must support SSO via Azure AD." Reasonable — it's the market leader in the segment you're selling into. Someone on the team spends two or three weeks implementing SAML or OIDC against Azure AD specifically, tests it against that one tenant, ships it, closes the deal. It feels like a feature. It is, technically, a feature. Nobody's roadmap has been meaningfully bent yet.

Customer 2: Okta

The second enterprise deal runs on Okta, and this is where the shape of the problem starts to show. The SAML implementation built for Azure AD assumed things — attribute naming conventions, certificate rotation behavior, specific claims formats — that don't hold for Okta. What looked like "we support SAML" was actually "we support this one IdP's version of SAML," and now it has to become genuinely IdP-agnostic. That's not a two-week job anymore. It's a rework of the first feature, disguised as building the second one.

Customer 3: Ping

By the third IdP, the pattern is obvious enough that someone finally proposes doing this properly — an abstraction layer that can onboard a new IdP through configuration instead of a code change. That's the right call. It's also, itself, a multi-week infrastructure project that has to get prioritized against everything else on the roadmap, funded not because a single customer asked for it but because three customers in a row revealed that the ad hoc approach doesn't scale.

Customer 4: MFA

A different customer's security team asks for enforced multi-factor authentication, tied to their own compliance obligations. This sounds like a feature flag — "add a checkbox" — and turns out to touch nearly everything: enrollment flows, recovery flows for users who lose their second factor, session handling for partially-authenticated states, and the interaction between MFA and every one of the SSO paths already built for the first three customers, because federated login and locally-enforced MFA don't automatically compose cleanly.

Customer 5: SCIM

A customer's IT team doesn't want to manually manage user accounts in yet another vendor's admin panel — they want provisioning and deprovisioning to happen automatically from their own identity provider, the moment someone joins or leaves the company. That's SCIM, and it's a meaningfully different problem from authentication: it's a full user-lifecycle API, with its own schema, its own edge cases around partial updates and group membership sync, and a very sharp security expectation attached to it, because the entire point of SCIM is making sure an offboarded employee's access dies immediately. Get deprovisioning wrong and it's not a bug ticket, it's an incident report.

Customer 6: Session timeout

A compliance-driven customer wants configurable session timeouts — idle timeout, absolute timeout, maybe a "log out on password change" requirement — enforced per-tenant, not globally. This looks trivial and rarely is, because session handling by this point is spread across however many auth methods have accumulated, and "log the user out after N minutes of inactivity" now has to mean the same thing whether they logged in via password, SAML, or OAuth, and has to be configurable without becoming yet another branch in already-branchy code.

Customer 7: Audit exports

Security and compliance teams don't just want logs — they want structured, exportable audit trails: who logged in, when, from where, what changed, delivered in a format their SIEM can ingest, often continuously rather than on request. This is the point where "authentication" quietly expands to include an entire logging and export pipeline, usually built under time pressure because it's frequently a hard blocker in a security review rather than a nice-to-have.

Customer 8: Passkeys

The newest wave of enterprise buyers, increasingly influenced by their own security teams' phishing-resistance mandates, wants WebAuthn-based passkey support — which means yet another authentication method to integrate into the same session model, the same account-recovery flows, and the same admin tooling as everything that came before it, plus fallback handling for the users and devices that don't support it yet.

Eventually your roadmap becomes identity

Look at that list end to end and notice what happened: not one of these eight items was unreasonable on its own. Every one of them was a rational ask from a customer trying to meet their own security or compliance obligations, and every one of them was, in isolation, a defensible thing to say yes to. The problem isn't any single yes. It's that there was never a point where the team sat down and decided "we are now going to build and maintain a full enterprise identity platform." That decision got made anyway, retroactively, one deal-driven feature at a time — and by the time it's visible as a pattern, it's already load-bearing across the entire product.

The tax shows up in a few predictable places. Engineering time that should be going to the product's actual differentiation instead goes to keeping pace with whichever IdP, compliance framework, or authentication standard the newest enterprise logo cares about. Two or three engineers become the only people who can safely touch the identity code, because it's grown too tangled and too risky for anyone else to confidently modify — which makes them a bottleneck and a single point of failure at the same time. And the sales team, entirely reasonably, keeps closing deals that each add one more identity requirement, because from where they sit, each individual ask looks small and each individual deal is worth saying yes to.

None of the individual customers did anything wrong. Azure AD, Okta, and Ping are all legitimate identity providers your buyers actually use. MFA, SCIM, session policy, audit exports, and passkeys are all things a serious security team is right to ask for. The tax isn't a sign that you picked bad customers. It's a sign that identity requirements compound in a way that most other feature requests don't — each one doesn't just add its own cost, it multiplies against every identity feature that came before it, because they all have to keep working together, correctly, indefinitely.

The founders who see this coming aren't the ones who refuse enterprise deals. They're the ones who recognize, somewhere around customer three or four, that they're no longer negotiating feature scope one request at a time — they're deciding, by accumulation, whether identity is a permanent part of their own product they intend to build and staff for, or a category they'd rather not be in the business of owning at all. Making that decision on purpose, early, is a very different position than discovering it retroactively once the roadmap is already identity's.