Eltherion
Build vs. Buy6 min read

Auth at scale: build vs buy for authentication

Auth at scale is an infrastructure decision that looks like plumbing until enterprise customers arrive. Buy when you need speed to revenue, standard MFA and social or passwordless login; build when your product needs custom SAML/SCIM workflows, strict data residency or a proprietary identity model.

By , founder of Eltherion · Editorial standards · Updated

person using MacBook pro

Auth at scale is commonly sold as a solved problem, but it rarely behaves like one. The login that is a simple SaaS call in month one tends to become a compliance, performance and integration project once enterprise customers, larger user counts and security reviews arrive.

A mistake here costs real money on both sides. People: the U.S. Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 (May 2025), before benefits and overhead (BLS), so every engineer you dedicate to identity is a large fixed cost. Risk: IBM's 2026 Cost of a Data Breach Report puts the global average breach at $4.99 million (IBM), and authentication is the front door. Vendor bills, meanwhile, scale with monthly active users and enterprise connections, so they grow as you do.

Direct answer: buy authentication when your needs are commodity (social login, password storage, MFA, passwordless, standard SAML/OIDC SSO), because a vendor gets you there in days and costs far less than the engineers needed to build and maintain it. Build, or run a hybrid, when identity is part of what you sell: custom SAML/SCIM provisioning rules, strict in-region data residency, a custom session model, or token validation that must stay in-process on a latency-critical path. In-house auth only becomes cheaper when the vendor's projected bill at your scale, plus the deals its limits cost you, exceeds the loaded cost of the team you would need. Opportunity cost counts too: every engineer on auth is an engineer not shipping core product.

Auth at scale is the set of systems that manage user identity, authentication flows (passwords, social, passwordless), authorization claims, session lifecycle, and provisioning (SCIM/SAML/OIDC) for your product and integrations.

Auth at scale: when to buy

Buying identity is almost always faster to revenue. Clerk, Auth0 (Okta), Firebase Auth, and WorkOS can get you from zero to account creation, social login, and MFA in days rather than months.

Vendor pricing is published, so price it from the source instead of guessing. As of October 2026, WorkOS lists its AuthKit user management as free up to 1 million monthly active users, with enterprise SSO and Directory Sync (SCIM) at $125 per connection per month for the first 15 connections (WorkOS pricing). Auth0's B2B Professional plan starts at $800 a month at 500 MAU with five enterprise SSO connections included, and its Enterprise tier is quote-only (Auth0 pricing). Pricing models differ (per user, per connection, per feature tier), so model each vendor at your projected user count and enterprise customer count, not today's.

Vendors also absorb part of the security burden. Okta (Auth0), WorkOS and similar providers maintain their own compliance attestations such as SOC 2, which helps when customers ask how login and credential storage are secured. It does not certify your product for you, but it removes the identity system from the list of things you must build, audit and defend yourself.

Operational velocity is the less visible cost. Homegrown auth keeps generating edge cases: account linking, session revocation, password-reset hardening, MFA recovery and bot protection. Track the engineering hours your team spends on these each sprint; that number, not a guess, is what buying would hand back to product work.

However, buying shifts control. If you check sessions against a hosted provider on every request, you add a network hop to your auth-critical path. Verifying signed tokens locally and caching avoids most of that, but measure the round trip from your own regions before you commit.

Auth at scale: when to build

Build when integrations, compliance or the identity model differentiate your product. Examples: SAML/IdP-first onboarding as the default for most of your paying customers, SCIM provisioning tied to complex group rules, or a customer requirement to store identity data in-region for GDPR/PDPA compliance.

Price the team honestly. Start from the BLS median of $135,980 per software developer (BLS), then add benefits, payroll taxes, recruiting and overhead to get your fully loaded cost per head. A credible in-house identity function usually needs more than one person: core engineers for SSO, MFA and provisioning, plus security and operations coverage so one departure does not leave login unowned.

An internal auth system removes the vendor's usage meter. Vendor bills grow with monthly active users and with every enterprise SSO or SCIM connection, so a product that scales fast on either axis should model that curve over three years and compare it with the fixed cost of its own team.

Control over session models and token lifetimes matters when token-check latency affects UX. Owning auth lets you validate sessions in-process with signed tokens and local caches instead of making a round trip to a hosted provider, and lets you set revocation and token lifetime rules that fit your product.

Security liability accrues to you if you build. Budget for penetration testing, dependency patching, monitoring and user-data incident response every year, not once. With the global average breach at $4.99 million in IBM's 2026 report (IBM), this line item is not optional.

Buy auth to ship fast; build auth to own integrations, compliance, and latency when your customer base and SLAs make vendor constraints a business risk.

What this means for a CTO

You must quantify the crossover. Start by mapping three numbers: the number of customers that will require SAML/SCIM in the next 24 months, projected MAU in 24 months, and the acceptable authentication latency on your critical path. Price the vendor at those numbers and compare it with the team cost below; build only when the vendor side is clearly more expensive or cannot meet the latency or residency requirement.

Run a 3-year TCO. Illustrative example using published inputs: three engineers at the BLS median wage of $135,980 (BLS) cost $407,940 a year in salary alone, or about $1.22 million over three years before benefits, overhead, security tooling and audits. On the buy side, 10 enterprise customers each needing SSO and SCIM on WorkOS at its listed $125 per connection per month (WorkOS pricing) comes to 20 connections, or $30,000 a year and $90,000 over three years, with user management free below 1 million MAU. You still need some engineering time to integrate a vendor, so the buy side is not zero people. The crossover arrives only when vendor fees at your scale, or the deals lost to vendor limits, exceed what the team would cost.

Negotiate vendor contracts not just on price but on SLAs for latency, SCIM correctness, data residency, and exportability. Contractual exportability reduces future switching cost; demand a machine-readable user export and a 30-day rollback window in writing.

When you decide to build, don't start from scratch. Adopt proven components: standard OIDC/OAuth flows with signed JWTs, a modern password hash such as Argon2id (the first choice in OWASP's Password Storage Cheat Sheet), an open-source identity broker such as Keycloak as an internal component, and automated dependency upgrades. Plan the first year around provisioning (SCIM), SSO (SAML/OIDC), MFA and a hardened recovery flow.

3-step checklist and cost levers

1) Measure your enterprise demand: count how many customers will insist on SAML/SCIM in the next 12 months and quantify lost ARR per failed integration. 2) Calculate auth latency budget: set a 95th-percentile bound for login-related API calls and measure vendor vs in-house delta. 3) Run a 3-year TCO with switching-cost line items (data export, migration scripts, account reconciliation).

Negotiation levers: demand per-request pricing caps, egress limits, and an export API. Engineering levers: session cache TTLs, signed tokens, and an internal provisioning queue to decouple SCIM bursts from onboarding latency.

Switching cost math: a migration means exporting user records, custom attributes and account links, moving password hashes (if the vendor lets you export them) or forcing resets, re-enrolling MFA, and reconciling accounts. Estimate it as engineering weeks times your loaded weekly cost, and compare that with one year of vendor spend. Check export terms before you sign, not when you want to leave.

Key takeaways

1) Buy authentication if your needs are commodity (social login, MFA, passwordless, standard SSO) and you value speed to revenue. 2) Build authentication if you need custom SAML/SCIM provisioning, in-region data residency, or in-process token validation on the critical path, and price the team from loaded salaries, starting from the BLS median of $135,980 per developer. 3) Always demand exportability and SLAs from vendors to keep switching cost bounded. 4) Include security, audit and incident-response budgets in any build decision. 5) Re-evaluate the decision at each doubling of MAU or enterprise customer count, because the crossover moves as you grow.

Your decision should be reversible. If you buy first, instrument for extraction: store canonical user IDs, track account links, and keep a migration path ready. If you build first, encapsulate auth as a platform service with a clear API so you can later add a vendor for redundancy or federated identity. To compare your own numbers, try the build vs. buy calculator.