Build vs. buy authentication: the hidden cost of rolling your own

At a glance

What this is: This is a cost-case analysis of build versus buy authentication, arguing that managed providers usually win because production auth is dominated by upkeep, security hardening, and compliance, not the first login screen.

Why it matters: It matters because IAM teams and product owners often underestimate the operational and security burden of homegrown auth, then inherit a control surface that keeps changing long after launch.

By the numbers:

• Building a compliance-grade passkey rollout for a 5M-user product across web, iOS, and Android takes 27.5 FTE-months, according to Clerk.

Context

Authentication programs fail when teams treat the login form as the project instead of the security lifecycle behind it. The real question is not whether a team can ship a sign-in screen, but whether it can sustain password storage, session handling, recovery, federation, MFA, and compliance over time.

This article focuses on the build versus buy decision for authentication infrastructure. That decision affects human IAM first, but it also sets the operating model for federation, account recovery, and the security work that sits behind every user session.

Key questions

Q: When should teams build authentication instead of buying a managed provider?

A: Build only when authentication is truly core infrastructure and the organisation can own the full lifecycle, including security maintenance, recovery, standards updates, and compliance evidence. For most teams, buying is the better fit when speed, staffing, and predictable operating cost matter more than custom control.

Q: Why does homegrown authentication become expensive after the first release?

A: Because the first release covers the visible workflow, while the expensive work lives in session revocation, abuse prevention, recovery design, standards changes, and dependency patching. Those obligations continue every year, so the system behaves like a standing security service rather than a one-time build.

Q: What do security teams get wrong about building authorization in-house?

A: They often price the initial implementation but ignore the recurring cost of maintenance, evidence gathering, and developer time diverted from product work. A small first version can become a permanent roadmap item once customer types, compliance needs, and edge cases start multiplying. The mistake is treating authorization as a feature instead of a lifecycle control.

Q: What is the difference between a managed auth provider and self-hosted auth?

A: A managed provider takes on protocol maintenance, patching, and hardened defaults, while self-hosted auth keeps those responsibilities inside your team even if the software is packaged for you. The difference is not just deployment location, but who owns the long-term security burden.

Technical breakdown

Why authentication is more than a login form

Authentication proves identity, while authorization governs what that identity can do. In practice, a production system has to manage password hashing, sessions, token issuance and revocation, federation, recovery, MFA, and rate limiting as one connected control plane. Each piece has its own failure modes, and the security burden grows when they are wired together. The hard part is not the front-end form. It is maintaining the policy, cryptography, and lifecycle controls that keep the system secure after users arrive and attackers adapt. See the Workforce Identity Security Guide.

Practical implication: Treat auth as a long-lived control surface, not a feature ticket.

Why the build cost keeps climbing after launch

A homegrown auth stack accumulates cost because standards, attack techniques, and implementation expectations keep moving. OAuth requirements tighten, passkey behavior evolves, and dependency CVEs land continuously. A team that ships a working implementation still has to maintain redirect handling, token discipline, recovery flows, and abuse protection as the ecosystem changes. The cost curve is therefore not linear. The initial delivery is only the start of the security and maintenance obligation.

Practical implication: Budget for standards drift and ongoing security maintenance, not only initial delivery.

Why managed authentication changes the risk model

Managed authentication does not remove identity risk, but it changes who owns the hardest parts of the control stack. The provider carries the burden of patching, hardened defaults, and protocol maintenance, while the customer remains responsible for configuration, policy, and integration. That shift matters because authentication failures often come from uneven implementation rather than from the idea of identity management itself. A managed service can reduce exposure to common implementation errors, but only if teams still govern recovery, session policy, and trust boundaries carefully. See the IAM and Identity Provider Buyer's Guide.

Practical implication: Use managed auth to reduce protocol-implementation risk, then govern configuration tightly.

Threat narrative

Attacker objective: The attacker wants to gain trusted access through identity weaknesses that can be reused across applications and workflows.

1. Entry begins when attackers target weak or inconsistently implemented authentication flows, especially login, recovery, and federation paths that are easy to expose but hard to harden.
2. Credential access follows when password stuffing, token abuse, session weaknesses, or OAuth and SAML misconfiguration let an attacker impersonate a user or replay a trusted session.
3. Escalation happens when the authentication layer is trusted broadly across applications, letting a compromise of one identity path expand into broader account or API access.
4. Impact is unauthorized access, account takeover, breach response cost, and the operational burden of rebuilding trust in the identity layer.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build versus buy is really a governance decision, not a feature decision. Once authentication becomes a core control plane, the question shifts from what can be coded to what must be continuously owned. The article's cost case shows that maintenance, recovery, standards drift, and compliance are the real budget drivers. For identity teams, the practical conclusion is that auth should be treated as an enduring governance surface, not a one-off engineering milestone.

Authentication security has become a lifecycle problem, not a launch problem. A system can be shipped quickly and still become expensive to govern because its standards baseline changes underneath it. That is why the initial build is rarely the expensive part. The implication for human IAM programmes is that ownership of sign-in, recovery, and federation never ends, even if the original implementation was technically sound.

Managed authentication does not eliminate control responsibility, it reassigns it. The provider absorbs protocol upkeep and patching, but the customer still owns configuration, policy, and trust boundaries. That distinction matters because many identity failures happen in the handoff between service capability and enterprise governance. Teams should evaluate where they want implementation risk to live, then govern the rest with the same rigor they would apply to any privileged control surface.

Identity control is increasingly a recurring expense, not a static asset. The article's three-year cost framing shows why auth should be budgeted like a living security programme. What once looked like software scaffolding now behaves like a standing operational service. For practitioners, the key takeaway is that authentication should be evaluated over its full lifecycle, including maintenance, compliance, and incident response, not only initial delivery.

What this signals

The build-versus-buy decision for authentication is really about where identity risk will live. Teams that build inherit not just code ownership but the obligation to track standards changes, vulnerability work, recovery flows, and security evidence over time. That shifts auth from a project milestone into an operating discipline.

Authentication programmes now need lifecycle thinking from day one. The systems that look cheapest at launch are often the ones that keep consuming engineering time later, especially when recovery, federation, and session controls are part of the stack. A mature IAM programme should therefore evaluate auth infrastructure the same way it evaluates any other long-lived control surface.

Managed identity services can reduce implementation risk, but they do not remove governance responsibility. Teams still need to decide how recovery, session policy, and trust boundaries are administered inside the enterprise. The practical signal is simple: if no one owns the ongoing control model, the auth choice is already unsafe.

For practitioners

• Define the authentication ownership model Decide whether your team will own the protocol stack, the recovery workflow, and the ongoing security maintenance before any implementation starts.
• Price the full three-year lifecycle Estimate build, patching, compliance, and support effort together so the decision reflects real operating cost rather than just initial engineering time.
• Separate prototype scope from production scope Treat a demo login flow as a proof of concept only, and do not let prototype shortcuts define your production security baseline.
• Validate recovery and federation controls early Test account recovery, session revocation, and SSO or OAuth flows before launch, because those paths usually carry the highest hidden risk.
• Re-evaluate when internal auth is still justified Keep the build case narrow: regulated environments, air-gapped systems, strict sovereignty constraints, or a team that can genuinely operate authentication as core infrastructure.

Key takeaways

• The main risk in homegrown authentication is not the first login screen, but the long tail of upkeep, policy change, and security hardening.
• The article's cost case shows why teams underestimate auth by focusing on build time and ignoring maintenance, compliance, and breach liability.
• For most organisations, the deciding factor is ownership of the full identity lifecycle, not whether the initial implementation is technically possible.

Related NHI Mgmt Group resources: IAM and Identity Provider Buyer's Guide · Workforce Identity Security Guide · Identity Provider and SSO Security Guide

Key terms

• Authentication lifecycle: The authentication lifecycle is the full sequence of controls that decide whether an identity is trusted, from sign-up and verification through sign-in, session handling, and recovery. It matters because attackers do not need to beat every control if one stage leaks trust or creates a reusable session.
• Managed Authentication Provider: A third-party service that supplies authentication capabilities such as sign-in, recovery, federation, MFA, and session handling. The organisation still owns configuration and policy, but the provider absorbs much of the protocol maintenance, patching, and standards upkeep that a homegrown stack would otherwise require.
• Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.
• Federation: Federation is the arrangement that lets one organisation accept identity assertions from another trusted identity provider. It reduces separate credentials, but it also creates dependency on token validation, trust configuration and certificate or key management. Defenders should check claims, audience restrictions, signing keys and trust relationships.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.