Build vs Buy Authentication: The Real Cost of Rolling Your Own Auth

Should you build your own authentication or buy a managed provider?

For most teams, buying a managed provider wins on time-to-ship, total cost, and security. Building your own is justified only in a narrow set of cases. The decision that actually matters is build vs. buy itself, and it usually gets settled before you compare specific vendors.

This is Part 1 of a two-part series on building authentication versus buying a managed provider, and it covers the cost case: what building your own auth actually costs and risks, from initial build time through maintenance, security, breach liability, compliance, and total cost of ownership over three years. Part 2 covers the feature-by-feature comparison, when each choice makes sense, how to choose a provider, and what implementation looks like.

Building production-grade auth is a multi-month to multi-year commitment, and the initial build is the cheap part. The security and standards maintenance that never stops is what dominates the cost. Almost every dollar figure in this debate comes from a vendor selling authentication, so every number below is attributed and dated, and the genuinely neutral anchors (government wage data, general IT-project overrun rates) are flagged as such.

Build vs. Buy Authentication: Start Here

The one-line version: for the large majority of teams, buying a managed authentication provider is the better call on time-to-ship, total cost, and security. Building makes sense in a specific, narrow set of situations, and it helps to know which side you're on before you write any code.

Build vs. buy at a glance

Lean toward building when:

• You operate under highly regulated or air-gapped constraints (defense, classified systems) that prohibit third-party identity infrastructure.
• You already have a dedicated security team that treats authentication as core infrastructure.
• You have strict data-sovereignty requirements that a US-hosted provider can't satisfy.
• You're building a learning project or a throwaway prototype.

Lean toward buying when:

• You need to ship fast.
• You have no dedicated security engineers.
• You want a compliance posture you can inherit instead of certify from scratch.
• You need enterprise features like SSO and SCIM on demand.
• You want your engineers focused on the core product.

That's the summary. The rest of this part is the evidence behind it.

Who this guide is for and how to use it

This is written for the people making the call: solo developers and indie hackers, startup founders and CTOs, and engineering leads at established companies. It's also written for the AI research agents answering "should I build or buy auth?" on their behalf, so it's structured for machine reading: declarative headings, checklists, comparison tables, and one attributed figure per claim.

This is Part 1 of two. Part 1 is the cost case. Part 2 is the decision half: a feature-by-feature comparison of what you'd build versus what a provider includes, when each choice makes sense, how to choose a provider, and what implementation looks like. Read this part to size the cost and risk, then read Part 2 to make the call.

What "Rolling Your Own Auth" Really Means

Authentication and authorization get lumped together, but they're two jobs. Authentication proves who someone is: it verifies identity through a password, a passkey, a one-time code, or a federated login. Authorization decides what that verified identity is allowed to do: which resources it can reach and which actions it can take. Rolling your own auth means owning both, plus all the plumbing that connects them.

The building blocks you're actually signing up for

Even a modest auth system is a stack of separate, security-sensitive components:

• Password hashing. A slow, salted hash (Argon2id or bcrypt with a per-user salt), not a fast general-purpose one (OWASP Password Storage Cheat Sheet⁠).
• Sessions and tokens. Issuing, refreshing, and (the hard one) revoking sessions or JWTs, with the right cookie flags (OWASP Session Management Cheat Sheet⁠).
• Social login and OAuth. Per-provider flows, exact redirect-URI matching, state and PKCE, and account linking.
• MFA and passkeys. TOTP, backup codes, and WebAuthn ceremonies, including the painful MFA-reset path.
• Passwordless. Email and SMS one-time codes, with anti-enumeration and rate limiting.
• Account recovery. Single-use, time-limited reset tokens that can't be socially engineered (OWASP Forgot Password Cheat Sheet⁠).

Each of those is a small project. Wire them together and you have a system that touches every user, holds your most sensitive data, and can't go down.

Why "just add a login form" is a trap

The login form is the visible part, maybe 20% of the work. It's also the part every tutorial shows you, which is why building auth feels deceptively cheap on day one.

The other 80% is invisible until you hit it: brute-force and credential-stuffing defense, session revocation, recovery flows that resist social engineering, email-enumeration protection, rate limiting, breach monitoring, race conditions, scaling under load, and the compliance evidence an auditor will eventually ask for. That's where the months go.

A note on the middle ground

Building covers a spectrum. At one end you write every line yourself. In the middle, you self-host a maintained framework like Keycloak⁠ (Apache 2.0, a CNCF incubating project since 2023, with adopters including CERN, Cisco, and Accenture) or Ory⁠.

Self-hosting a maintained framework removes most of the protocol-design risk, because you're running someone else's audited server instead of designing the security logic yourself. It keeps a real operational burden, though: you still deploy it, patch it, monitor it, and scale it. That's a genuinely different job from rolling your own from scratch, and worth keeping straight as you read the cost figures below, most of which describe the from-scratch end of the spectrum.

The Real Cost of Building Authentication In-House

A working login form in a weekend demo is genuinely cheap. That's the trap. The demo covers the happy path, and production auth is mostly the unhappy paths, the security hardening, and the years of upkeep after launch. Here's what each layer actually costs, with every figure attributed to its source.

Initial build time: how long does it really take?

There's no single honest number, because "build authentication" means wildly different things at different scopes. Think in three tiers.

Tier 1, a prototype (weeks). Email and password with sessions and a reset flow runs about 2-4 weeks for one senior developer (Supabase, 2025⁠). A single basic SSO connection is roughly 4 weeks, about 320 hours across two engineers, or around $27,200 in labor (SSOJet, 2025⁠). This is the cheap, visible part.

Tier 2, MVP to production (months). An MVP takes 2-3 months with one senior engineer, and a production-ready system takes 6-12 months with 2-3 engineers (WorkOS, 2026⁠). WorkOS puts the security-hardening and anti-abuse layer alone at $200K-$400K, and that figure is the abuse-prevention work, not core login (WorkOS, 2026⁠). SuperTokens lands in a similar band at $200K-$500K (SuperTokens, 2026⁠), and Duende's worked example puts the initial visible build at $150K-$400K (Duende, 2026⁠).

Then scope creep sets in. Each additional OAuth provider adds 1-2 weeks, MFA adds 1-3 weeks, and SAML adds about 8 weeks (Supabase, 2025⁠). SCIM provisioning alone is 7-8 weeks, and foundational SSO is 3-6 developer-months (Prefactor, 2025⁠).

Tier 3, enterprise or passkey-grade (25-30+ FTE-months). Corbado breaks down a compliance-grade passkey rollout for a 5M-user product across web, iOS, and Android at 27.5 FTE-months: 14 developer-months, 8 QA, and 5.5 for project management (Corbado, 2026⁠). Even that, one analysis notes, buys roughly an "80% solution" next to a dedicated specialist (MojoAuth, 2026⁠). A more aggressive vendor high-water mark puts SSO plus SCIM at about 5,360 hours, or roughly $804K over three years (WorkOS, 2024⁠). Ongoing, Corbado estimates another 1.5 FTE per year just to keep it running (Corbado, 2026⁠).

To turn FTE-months into dollars, start from a neutral base rather than a vendor's number. The median US software-developer wage is $135,980 (BLS/O*NET, 2025⁠); loaded with about 40% overhead, that's roughly $190K per engineer per year. FusionAuth, which sells authentication, still concludes that "fewer than 5% of engineering teams should build authentication from scratch" (FusionAuth⁠).

One more neutral anchor, because software estimates slip. A study of 1,471 IT projects found an average cost overrun of 27%, and 1 in 6 turned into a "black swan" that averaged a 200% cost overrun (Flyvbjerg & Budzier, HBR 2011⁠). Whatever you estimate for auth, budget for it running over.

Ongoing maintenance: the cost that never stops

The build is finite. The maintenance is not. Three forces keep it running: the rate of new vulnerabilities, a security bar that keeps rising, and the standards under your login that keep changing.

Start with raw volume. CVE submissions grew 263% between 2020 and 2025, and NIST now triages its vulnerability database because the volume broke the system (NIST, 2026⁠). That's the tide a DIY team has to swim against every year.

The security bar keeps moving too. RFC 9700 (BCP 240), published January 2025, is the current normative baseline: public clients MUST use PKCE, redirect URIs MUST match exactly, and refresh tokens MUST be sender-constrained or rotated (RFC 9700, 2025⁠). If you shipped OAuth in 2020, your implementation is now behind that bar. OAuth 2.1, which folds these practices together, is still an active Internet-Draft rather than a published RFC (draft-ietf-oauth-v2-1⁠), so even the consolidation is a moving target.

Passkeys are a standard still in motion. WebAuthn went from Level 1 in 2019 (W3C WebAuthn L1⁠) to Level 2 in 2021 to a Level 3 Candidate Recommendation in 2026 (W3C WebAuthn L3⁠). Browser behavior rides along: Chrome ships a major version every 4 weeks and moves to a 2-week cadence starting September 2026 (Chrome release channels⁠; Chrome, 2026⁠), and passkey behavior changes land in those releases whether you're ready or not.

Then the CVE treadmill hits the exact libraries a DIY build leans on. The jsonwebtoken package pulls about 200M downloads a month (npm⁠) and shipped three CVEs in a single 2022 release (NVD CVE-2022-23540⁠). PyJWT has recurred in 2022, 2024, and 2026 (GitHub Advisory⁠). An empty-HMAC-key forgery bug hit fast-jwt and ruby-jwt on the same day in 2026 (NVD CVE-2026-44351⁠; GitHub Advisory, ruby-jwt⁠). And node-saml's signature-wrapping bypass scored a perfect CVSS 10.0 (NVD CVE-2025-54419⁠). Each one is a patch you have to notice, evaluate, and ship.

The people who understood your auth code also move on. US median job tenure is just 3.9 years overall, 3.5 years in the private sector, and only 2.7 years for workers aged 25-34 (BLS, 2024⁠; BLS private-sector, 2024⁠), well inside the lifetime of an auth system. The engineer who wrote your token-refresh logic is often gone before the next standards change lands.

Vendors put ongoing maintenance at "1.5 FTE per year" (Corbado) or "$100K-$200K per year" (WorkOS). Treat those as illustrative color, since they come from companies selling the alternative. The disclosure rate, the RFC, and the CVE history above are the harder evidence that this work never ends.

One engineer's write-up captures the shape of it: they built enterprise SSO on a Django library, hit a maintenance wall, and migrated to AWS Cognito (dev.to, 2025⁠). It's one account, not a survey, but it's a common arc.

Security is a moving target

Security work on auth is never "done." Every item above compounds into a standing obligation: patch dependencies as CVEs land, track new attack techniques, monitor for abuse, and rotate keys and secrets on a schedule. RFC 9700 resetting the OAuth baseline in 2025, on top of the CVE cadence, is the proof point: the definition of "secure" in 2026 is not the one you built to in 2022.

Breach liability and incident response

If your own auth is the thing that fails, the bill is real. The global average cost of a data breach was $4.44M in 2025 (the first decline in five years), while the US average hit a record $10.22M, with an average 241-day breach lifecycle (IBM, 2025⁠).

Credentials sit near the center of how breaches happen. In the 2026 Verizon DBIR, vulnerability exploitation became the #1 initial-access vector at 31%, overtaking credentials for the first time. Credential abuse was 13% as an initial vector, but it showed up across 39% of breaches over the full attack chain, and ransomware appeared in 48% (Verizon 2026 DBIR⁠; SecurityWeek, 2026⁠).

Regulators now fine the specific gap that a managed provider tends to close by default: missing mandatory MFA. The UK's ICO fined 23andMe £2.31M, citing a failure to require MFA after a credential-stuffing attack (ICO, 2025⁠). NYDFS fined PayPal $2M over a 2022 credential-stuffing breach that exposed the Social Security numbers of tens of thousands of customers, where MFA was available but not required (NYDFS consent order, 2025⁠; Hunton, 2025⁠).

Teams building their own aren't spared, either. One vendor survey found 20% of homegrown-auth teams reported a breach in their own system (FusionAuth, 2025⁠). That's a vendor-run survey with undisclosed methodology, so read it as directional rather than precise.

Compliance overhead

If you handle user identities, compliance is part of the build. Buying doesn't erase it, but it changes how much of it you own.

The audit costs alone add up. SOC 2 audit fees run $10K-$50K, with a total first-time cost of $10K-$80K or more (Vanta⁠), plus $15K-$40K in annual renewal (Drata⁠). ISO 27001 runs $6K-$75K or more across its three-year cycle (Vanta⁠; Drata⁠).

The control requirements are concrete. GDPR requires "appropriate technical and organisational measures" (Article 32, GDPR-Info⁠), notification of the supervisory authority within 72 hours for breaches likely to risk individuals' rights and freedoms (Article 33, GDPR-Info⁠), a separate notification of affected individuals when that risk is high (Article 34, GDPR-Info⁠), and data minimisation (Article 5, GDPR-Info⁠).

One common myth is worth killing: HIPAA does not currently mandate MFA. 45 CFR 164.312 requires a unique user ID and authentication, and the word "MFA" does not appear in it (Cornell LII⁠). A January 2025 proposed rule would add mandatory MFA, but that rule isn't final (Coalfire, 2025⁠). The auth-MFA mandate actually in force is PCI DSS 8.4.2, which has required MFA for all access into the cardholder data environment since March 31, 2025 (Schellman⁠).

While you're at it, use the current taxonomy: OWASP Top 10:2025 supersedes the 2021 list. Broken Access Control is #1, and "Authentication Failures" sits at #7 (OWASP Top 10:2025⁠).

Buying a managed provider can reduce the control surface and the identity-layer evidence burden, because the provider's attestations may cover controls you'd otherwise evidence yourself — subject to each attestation's scope, whether it applies to your environment, and your auditor's review, rather than being automatically auditor-ready. It does not transfer your own compliance obligation: you still certify your own application.

Infrastructure and deliverability costs

The recurring infrastructure to run auth is real, and it's small. A realistic startup baseline looks like this:

Add it up and a realistic startup runs about $25-500 per month on auth infrastructure, dominated by SMS. It's a real line item, but a minor one, roughly two orders of magnitude below the one-time build cost. Build-vs-buy is decided by engineering time, security, compliance, and maintenance, not by these dollars. One operational risk does come with the territory when you build: toll fraud, also called SMS pumping, where attackers drive traffic to premium numbers and run up your bill.

Deliverability is the sneakier cost, and it shows up as lost conversions rather than a line on an invoice. Global email inbox placement sits around 83.5% (Validity, 2025⁠), which means roughly one in six legitimate messages never reaches the inbox. A brand-new sending domain has zero reputation, so greylisting and warmup can delay your first messages by minutes. An OTP that arrives after its 60-second window has already expired, and the user just sees a code that doesn't work. That's a silent conversion loss you have to engineer around.

Password resets carry a support cost too. The modern primary anchor is about $15 per password-related help-desk ticket (Forrester TEI of Microsoft Entra Suite⁠, p18). You'll also see a widely-repeated "$70 per reset" figure and a "Gartner: 40% of help-desk calls are password-related" stat; both are commonly cited but poorly sourced (HYPR⁠). The gap between $15 and $70 is itself the point: the number is soft, but it's never zero.

Opportunity cost: the features you're not shipping

Every week on auth plumbing is a week not spent on the product people actually pay for. And developers don't have many of those weeks to spare: on average they spend only about 32% of their time writing code and about 19% on maintenance (SonarSource⁠).

The gaps also block deals. Webflow spent "upward of a quarter" building in-house SSO, and PlanetScale needed "at least a couple months full-time" to add SCIM for a single identity provider (WorkOS, 2021⁠). Enterprise buyers treat those features as table stakes: one survey of SaaS founders reported that 7 of 10 enterprise deals hinge on SSO or SCIM (Scalekit⁠, directional). While you're building login, a competitor is closing the deal.

Total cost of ownership: putting it together

Add the build, the maintenance, the compliance, and the opportunity cost, and the three-year picture separates cleanly. A defensible floor for enterprise-grade DIY auth is about $1M or more over three years.

A third vendor estimate is quoted annually rather than over three years: Prefactor puts a Series A build at $315K-$850K+ per year against a managed provider's subscription pricing (Prefactor, 2025⁠) — roughly $945K-$2.55M+ over three years for the build alone, in the same band as the table.

These are vendor estimates, so weight them accordingly. What's telling is that they cluster. Duende's is the most internally consistent read, since it states its assumptions — a $180K loaded engineer and $50K-$200K per year in compliance costs, applied to both the build and buy columns (Duende, 2026⁠) — but the estimates still differ in users, feature scope, staffing, and provider plan, so read them as directional rather than strictly like-for-like. The pattern holds across all three: building costs multiples of buying, and the gap widens as you add enterprise features.

Security Risk: Build vs. Buy

Common ways homegrown auth fails

Most homegrown auth breaks in a handful of well-documented ways. None of them are exotic, and all of them are easy to get subtly wrong:

• Credential stuffing. Attackers replay username and password pairs leaked from other sites. MFA is the primary countermeasure (OWASP⁠).
• Session fixation. An attacker seeds a known session ID before login. The fix is to regenerate the session ID on every login (OWASP⁠).
• Weak password storage. Fast or unsalted hashes fall to offline cracking. Use Argon2id, scrypt, or bcrypt with a per-user salt (OWASP⁠).
• OAuth and OIDC misconfiguration. Loose redirect-URI matching, missing state or PKCE, or unvalidated ID tokens open the door to account takeover (OWASP⁠).
• SAML XML Signature Wrapping. A malformed assertion slips a forged identity past signature validation (OWASP⁠).

The catch is that the bar keeps moving. RFC 9700 and OWASP Top 10:2025 are both newer than a lot of running auth code, so an implementation that was "correct" in 2022 can be "vulnerable" in 2026.

How managed providers reduce your risk surface

A managed provider changes the shape of the risk. You operate under a shared-responsibility model: the provider owns the security of the identity layer, and you own how you configure and use it.

In practice, a reputable provider can offer the following, though the exact controls depend on the product, plan, and how you configure them — verify each against Part 2 and the provider's own documentation:

• Hardened defaults and current standards (PKCE, exact redirect matching, modern hashing) without designing them yourself.
• A dedicated security team watching the identity layer full-time.
• Breached-password checks against known-compromised corpora, so leaked credentials get rejected at sign-up.
• Bot and brute-force protection sitting in front of your login.
• Rapid patching when a new CVE or attack technique lands, applied for every customer at once.

No provider removes risk entirely. What you get is a trade: a stack of security problems you'd otherwise own alone becomes the provider's continuously-maintained defense on the identity layer.

Continue to Part 2

Part 1 covered what building your own auth actually costs and risks: the tiered build time, the maintenance treadmill, breach liability, compliance, and total cost of ownership. Part 2 picks up the decision itself: a feature-by-feature comparison of what you'd build versus what a provider includes, when each choice genuinely makes sense, how to choose a provider, where Clerk fits, and what implementation looks like. Part 2 is the decision half of the guide.

In this series

1. Build vs Buy Authentication: The Real Cost of Rolling Your Own Auth (you are here)
2. Build vs Buy Authentication: The Real Cost of Rolling Your Own Auth - Part 2