The Real Cost of Build vs. Buy for Identity

Imagine a development team starting to build their own auth system from scratch. Talented developers, clean architecture, all the right OAuth 2.0 flows. When they succeed, they are proud of it, and they should be, because it works.

Months later, three sprints deep into adding SAML for a single enterprise customer. Their best Auth engineer had just given two weeks' notice. The compliance team is asking questions about session management that no one else on the team can answer. And the original six-week project? It had quietly become the single largest line item in their technical debt backlog.

"We'll just build it ourselves" is one of the most common and most expensive sentences in software engineering. The logic seems sound on the surface. Your team knows your requirements. You don't want vendor lock-in. You've got talented people. A few sprints, maybe a quarter, and you'll have exactly what you need.

Here's the thing nobody tells you during that planning meeting: the initial build is the cheap part. It's the years that follow — maintenance, security patching, protocol updates, compliance audits, incident response, and the features you didn't know you'd need — that quietly bleed budgets. And when things go truly wrong, the costs aren't measured in sprints. They're measured in breach notifications and lost customer trust.

This post breaks down the real total cost of ownership for identity systems, using data from the IBM/Ponemon Cost of a Data Breach Report and the Verizon DBIR. We'll be fair about when building makes sense. But we'll also make the case for a third option that most teams don't consider early enough, and it's where the smartest ones tend to end up.

The Visible Costs: What Teams Budget For

When a team decides to build auth, several considerations go into the project plan. It usually looks like this: two to three developers, one to two quarters, building a login page, token issuance, basic OAuth flows, user storage, and password hashing.

For a competent team, the scope of a "basic" auth implementation includes: authorization code flow, client credentials, refresh tokens, JWT signing, session management, and some admin tooling. This can be three to six developer-months.

In budget terms, that's $150,000 to $400,000 in loaded developer expenses. Those expenses are what leadership considers. Those are also the expenses that leadership compares against the annual license cost of an identity product.

And that comparison of developer vs. annual license cost is where the thinking goes sideways. Teams weigh a one-time build cost against an ongoing license cost. What they should be weighing is the total cost of ownership over three to five years.

The Hidden Costs: What Teams Don't Budget For

Nobody budgets for the thing they assumed would be temporary.

The visible costs are the tip of the iceberg. Below the waterline, the costs are higher, less predictable, and they compound every year.

graph LR
    A["💰 VISIBLE COSTS"] --> B["Initial Build: $150K–$400K"]

    C["🕵️ HIDDEN COSTS"] --> D["Ongoing Maintenance: 0.5–1 FTE/year"]
    C --> E["Security Patching & CVE Response"]
    C --> F["Compliance Audit Prep: $50K–$200K/year"]
    C --> G["On-Call & Incident Response: 24/7"]
    C --> H["Unplanned Feature Requests"]
    C --> I["Knowledge Loss from Turnover"]
    C --> J["Opportunity Cost: Engineers Not on Product"]

Ongoing Maintenance

OAuth 2.0 and OpenID Connect are not static specifications. They evolve. RFC 9700 introduced new security requirements. Pushed Authorization Requests, Demonstrating Proof of Possession, and other extensions are rapidly becoming table stakes for serious deployments.

Someone on your team has to track all of that. Not as a side project. Continuously.

That's roughly half to one full-time engineer just keeping your auth system current — not adding features, just maintaining protocol compliance. On top of that, your runtime releases new versions annually, each of which may deprecate APIs, change cryptographic defaults, or break the HTTP pipeline. Budget two to four weeks per major release, just for auth.

Then there's the dependency chain. Cryptographic libraries, JWT libraries, HTTP libraries — each with its own release cycle, its own CVEs, its own breaking changes. You're not maintaining one system. You're maintaining an ecosystem you didn't mean to own.

Security Patching and CVE Response

When a vulnerability drops in a cryptographic library or JWT implementation, the clock starts immediately. Assess impact. Develop a patch. Test it without breaking existing flows. Deploy everywhere. Verify. For critical CVEs, the window is hours to days.

With a dedicated identity product, the vendor handles the first three steps. You handle deployment and verification. With DIY auth, you do all five. Cross your fingers that the person who wrote that code is still at the company.

That's not hypothetical. The average developer tenure is two to three years. Your auth system will outlive its builders. The new engineer who inherits it will face a steep learning curve in the highest-risk codebase in your stack — the one where mistakes make the news. And the institutional knowledge of why certain decisions were made, what edge cases were considered, and what known limitations were accepted? That person walked out the door with the last departure.

Compliance Audits

Here's where hidden costs become unavoidable line items.

SOC 2 Type II requires demonstrating that security controls work effectively over time. For auth, that means documented policies, evidence of access-control enforcement, session-management controls, audit logging for every authentication event, and regular configuration reviews. With a DIY system, you build all of that tooling and write all of that documentation. With a dedicated product, much of it exists already, and auditors recognise the patterns.

PCI DSS mandates specific auth controls for payment card data. HIPAA requires them for health data. GDPR and state-level privacy laws impose their own requirements around consent and access logging.

The annual cost of maintaining compliance with a DIY auth system ranges from $50,000 to $200,000, depending on your regulatory environment. That number recurs. And it tends to grow because regulations only ever multiply.

On-Call and Incident Response

Auth is a Sev-1 dependency. When it's down, everything is down.

That means 24/7 on-call coverage, runbooks, escalation paths, and post-incident reviews. Someone needs to understand the internals of your custom auth system at 3 AM on a Saturday.

But outages aren't the scary part. Credential compromises are. Can you revoke all sessions for a user? For all users? How fast? Can you force a password reset at scale without locking everyone out? Can you trace exactly which accounts were accessed? Do you even have the logging to know who to notify?

These aren't features teams build in the first version. They're features teams scramble to build during or after an incident that taught them they needed.

Feature Requests You Didn't Plan For

There's a list of capabilities that arrive after the initial build, each triggered by something outside your control:

Each one is weeks to months of work. Collectively, they dwarf the original build cost. And they don't arrive on your roadmap schedule — they arrive on the schedule of your customers, your auditors, and your regulators.

The Breach Cost Data: When DIY Auth Fails

One in three breaches starts with a stolen credential. It takes nearly a year to find out.

That's not an opinion. That's what a decade of data from the Verizon Data Breach Investigations Report shows. And the IBM/Ponemon Cost of a Data Breach Report puts a dollar figure on it: the average breach costs $4.88 million. Credential-related breaches take an average of 292 days to identify and contain, among the longest of any attack vector. Longer detection means higher cost. Every time.

The numbers, specifically

From IBM/Ponemon:

Organisations with mature identity and access management had significantly lower breach costs. Compliance failures and skills shortages made them worse.

From the Verizon DBIR:

Credential stuffing and brute force remain common. Phishing-to-credential-theft is a dominant attack chain. Basic web application attacks (the kind that exploit authentication vulnerabilities) stay in the top breach patterns year after year.

The reports are too polite to state directly: authentication is the most-attacked surface in your entire stack. This is not where "good enough" custom code is actually good enough.

What a Dedicated Identity Framework Gives You

A fair evaluation means understanding what you actually get when you buy, rather than custom build.

A dedicated identity framework is built by engineers who specialise in OAuth, OIDC, SAML, and FAPI. Protocol compliance is their full-time job, not a side project squeezed between product features. When a CVE drops, their security team patches it. You apply an update. That's a fundamentally different posture from debugging cryptographic code at 2 AM, when the person who wrote it left six months ago.

Compliance readiness comes built in. Audit logging, session management, and policy enforcement are designed with regulatory requirements in mind, not bolted on after the first audit. And because the framework runs across thousands of deployments, edge cases you'd never encounter in your own usage are already identified and handled.

There's also the conformance question. A dedicated framework passes official OIDC and FAPI conformance test suites. If a customer or auditor asks for proof of protocol compliance, "we tested it internally" isn't a satisfying answer. Certified conformance is.

And unlike SaaS identity providers, a framework like IdentityServer runs in your environment. Your infrastructure. Your perimeter. No data leaving to a third party, no dependency on someone else's uptime. You get specialised expertise, and you keep control. That combination matters more than most teams realise until they've given it up.

A Fair Comparison: Three-Year TCO

Let's make this concrete. Here's a template — plug in your own loaded costs and regulatory reality.

A worked example

Say your fully loaded engineer cost is $180,000/year. You staff a three-person team for the initial build (six months), budget half an FTE for ongoing maintenance, operate in a SOC 2 environment, and need to add two unplanned capabilities over three years. Note: The $50K annual licensing figure is illustrative. Check our pricing page for accurate licensing costs according to your needs.

Your numbers will differ. The shape of the curve rarely does.

xychart-beta
    title "3-Year Cumulative Cost: DIY vs. Framework"
    x-axis ["Year 1", "Year 2", "Year 3"]
    y-axis "Cost (USD)" 0 --> 1200000
    bar [435000, 715000, 1115000]
    bar [80000, 145000, 210000]

Five questions to answer before you decide

1. How many engineers will maintain auth over three years? What's their fully loaded cost?
2. What regulations apply? SOC 2? PCI? HIPAA? What does annual compliance cost for a custom system?
3. What will you need in twelve months that you don't need today? Be honest. Look at the trigger table.
4. Can you handle a credential compromise right now? Session revocation, forced resets, audit trails — today, not someday?
5. What would those engineers build if they weren't maintaining auth?

That last question is the one that usually decides it.

When Building Genuinely Makes Sense

Buying isn't always right. A post like this loses credibility if it pretends there's only one answer.

Building makes sense when identity is your product. If you're building an identity provider as your core offering, you need full control over every protocol interaction. That's your value proposition.

It makes sense at an extreme scale, with unique constraints, if standard frameworks become a bottleneck and you have three or more dedicated identity/security engineers to build and maintain an alternative.

It makes sense when your requirements are genuinely novel. Not a "we want to customise the login page" novel, but an "our authentication protocol doesn't exist yet" novel.

And it makes sense for learning. Building a minimal OAuth implementation is one of the best ways to gain a deep understanding of the protocol. Just don't ship it to production.

For everyone else? The question isn't whether your team can build auth. Of course, they can. The question is whether they should.

The Third Option: Buy the Foundation, Build the Differentiation

Here's where most teams eventually land, usually after learning the hard way.

The build-versus-buy framing is a false dichotomy. There's a third option: buy the infrastructure, extend it where your business needs something specific.

Think about databases. Nobody builds their own database engine. You adopt one and build schemas, queries, and application logic on top of it. You get the reliability of a system maintained by specialists, and you invest your engineering effort in the parts that are actually unique to your business.

Identity works the same way. A dedicated SDK handles the hard, security-critical problems: protocol compliance, token issuance, key management, session handling, and cryptography. You extend the framework with your business logic: custom claims, tenant-specific behavior, integration with your user stores, your branding, your workflows.

Build on, not from scratch. The protocol layer is someone else's responsibility. The business logic layer is yours. That's not giving up control. That's focusing control where it creates the most value.

Making the Decision

flowchart TD
    A["Do you need identity infrastructure?"] -->|Yes| B["Is identity your core product?"]
    B -->|Yes| C["Build from scratch"]
    B -->|No| D["Do you need to own the infrastructure?"]
    D -->|No| E["Buy SaaS identity provider"]
    D -->|Yes| F["Do you need custom business logic?"]
    F -->|No| G["Buy framework, standard config"]
    F -->|Yes| H["Buy framework + extend"]

Build from scratch when identity is your product, you have a dedicated security team, and you've read this entire post and still think the TCO is worth it.

Buy SaaS when you want zero operational overhead and are comfortable with the trade-offs around data residency and vendor dependency.

Buy and extend when you need to own your infrastructure, want protocol expertise from specialists, and need room to customise. This avoids both the cost of building from scratch and the constraints of SaaS.

Conclusion

We've watched enough teams go through this cycle to know how it usually plays out. The initial build goes well. The team is proud. Twelve to eighteen months later, the auth system is the thing everyone's afraid to touch, the compliance team has questions nobody can answer, and the roadmap has a mysterious "identity hardening" epic that keeps getting pushed to the next quarter.

It doesn't have to go that way.

The smartest move for most teams is the third option: buy the infrastructure, own it in your environment, and extend it with the logic that makes your product yours. Let specialists handle protocol compliance and security maintenance. Put your engineers to work on the work your customers actually pay you for.

Because that's really what this comes down to. Not whether you can build auth, but what you're not building while you maintain it.

And if you've already built it? The best time to re-evaluate is at a natural inflection point: your first enterprise customer, your first SOC 2 audit, or the moment your auth engineer gives notice. The sunk cost of what you've built is real, but it's smaller than the ongoing cost of maintaining it.

Sources and Further Reading

1. IBM/Ponemon Cost of a Data Breach Report 2025 — https://www.ibm.com/reports/data-breach — The definitive annual study on breach costs, covering average breach costs by industry, cost amplifiers and reducers, and the impact of specific security practices.
2. Verizon Data Breach Investigations Report (DBIR) — https://www.verizon.com/business/resources/reports/dbir/ — Annual analysis of real-world breach data. Consistently shows stolen credentials as the most common breach vector.
3. OWASP Top 10 (2021) — https://owasp.org/Top10/ — Broken Access Control (#1) and Identification and Authentication Failures (#7) underscore the criticality of getting auth right.
4. OAuth 2.0 Security Best Current Practice (RFC 9700) — https://datatracker.ietf.org/doc/html/rfc9700 — The evolving security requirements for OAuth 2.0 — a reminder that "building auth" is never a one-time cost.
5. Duende IdentityServer — Licensing and Editions — https://duendesoftware.com/products/identityserver — Pricing and feature comparison for Duende IdentityServer editions.