Authentication Is Infrastructure. Stop Treating It Like a Feature.

Authentication is one of the few parts of a software system that becomes more expensive the longer you own it. Unlike business features, it never reaches a point where it's "done." New attack vectors emerge. New standards appear. Enterprise customers demand federation. Compliance teams ask for stronger authentication. Security auditors want better logging. The login page you built in two weeks quietly becomes a product that requires continuous investment. Most SaaS companies don't set out to build an identity platform. They simply wake up one day and realize they already have.

Part of why this keeps happening is that identity gets classified wrong from day one. It goes into the same bucket as checkout flows, dashboards, and reporting — a feature, owned by whichever team happens to build it, prioritized against other feature work in the normal roadmap process. That classification is the root of most of the pain that follows, because authentication doesn't actually behave like a feature. It behaves like infrastructure, and infrastructure and features have different properties that call for different ways of building and owning them.

What makes something infrastructure

Infrastructure, in the way distributed systems and platform teams use the term, tends to share a specific set of characteristics regardless of what it's infrastructure for.

It's shared — many parts of the system depend on it, rather than it serving one specific workflow. It's standardized — its behavior follows external, well-defined protocols rather than internal, ad hoc conventions, precisely so that other systems can integrate with it predictably. It's centrally managed — there's a single source of truth for its configuration and behavior, rather than each consumer maintaining its own copy. It's independently deployed — it can be updated, patched, and scaled on its own schedule, not bundled into whatever release cycle a specific product feature happens to be on. It's highly available — its failure doesn't degrade one feature, it degrades everything that depends on it. And it's observable — it needs its own monitoring, logging, and alerting, because when it breaks, the blast radius is the whole system, not a corner of it.

Compare that to what defines an application feature: it typically encodes business logic specific to the product, models customer workflows that are genuinely unique to what you're selling, and expresses domain models that only make sense in the context of your particular application. Features are the reason customers buy the product. They're supposed to be different from every competitor's version of the same idea — that's the whole point of building them in-house.

Which category authentication belongs to

Run authentication against both lists and the answer isn't ambiguous. It's shared — literally every part of the product depends on knowing who the current user is. It's standardized — SAML, OIDC, SCIM, and WebAuthn are external protocols with specifications your implementation has to conform to, not internal conventions you get to invent. It benefits enormously from centralized management — a session revoked or an MFA policy changed needs to apply consistently everywhere, not per-feature. It has independent release and patch cycles driven by security disclosures and protocol updates, not by your product roadmap. Its availability requirements are the strictest in the entire system, because if login is down, nothing else matters — a bug in your reporting feature inconveniences some users, a bug in session validation can take down the whole product or, worse, silently misauthorize access across it. And it needs dedicated observability, because the questions you need answered when something goes wrong — who authenticated, when, from where, with what method, and did anything about that pattern look unusual — are a different shape than the metrics that matter for a feature.

None of the properties that define authentication line up with the feature column. All of them line up with infrastructure. The reason it keeps getting built and owned as a feature isn't that this classification is unclear — it's that the two-week login page it started as genuinely was small enough to reasonably treat as a feature, and nobody revisited the classification as it grew.

What treating it like a feature actually costs

Feature teams optimize for shipping the specific thing they're building, which is exactly the wrong bias to apply to something meant to be shared and standardized. A feature team building login for the second time, for a second customer's IdP, tends to solve the immediate problem in front of them rather than build the general abstraction — because building the general abstraction isn't what that sprint was scoped for. That's how you end up with three slightly different SAML implementations, one per major customer, none of which share code, all of which need to be separately patched when the next vulnerability disclosure comes out.

Feature-style ownership also means authentication code inherits a feature's release cadence and testing rigor, which is usually far lighter than what something with this blast radius actually needs. A feature shipping with a minor bug is a bug ticket. Authentication code shipping with a minor bug can mean one tenant's session tokens are valid for another tenant's account, and that gap can sit undetected for a long time precisely because nobody built the observability layer that infrastructure would have needed from the start.

And because it's owned like a feature, it competes for prioritization like a feature — against the next customer-facing capability that has a clearer, more immediate revenue story attached to it. Infrastructure investment consistently loses that fight in the short term, which is exactly how identity code ends up years behind where it needs to be, discovered only when a security review or an incident forces the issue.

What treating it like infrastructure looks like

Infrastructure gets a different set of defaults. It gets a small number of people who deeply understand it, rather than being touched by whoever happens to be working nearby. It gets designed against external standards from the start, rather than backfilled into standards compliance after the third customer asks for SSO. It gets monitored and alerted on independently of whatever feature happens to be using it that day. It gets patched on a schedule driven by its own risk profile — a security disclosure, a protocol deprecation — rather than waiting for the next feature sprint that happens to touch the same files. And critically, it gets evaluated with the build-vs-operate question infrastructure decisions normally get: is this something worth building and running ourselves indefinitely, given what it actually costs to keep current, or is this a category better served by a system built specifically to be that infrastructure, the way most companies don't build their own database or their own CDN?

That last point isn't an argument for or against any particular vendor — it's an argument for asking the question at all, on purpose, rather than defaulting into ownership because the first version happened to be small enough to build in two weeks. Databases, message queues, and CDNs all started, historically, as things individual companies built in-house before the industry converged on treating them as infrastructure best obtained from specialists. Identity is following the same arc, later, because it's easier to underestimate — a login page looks nothing like a database until you've watched it grow for five years.

The companies that get this right aren't the ones who avoid ever building authentication themselves. They're the ones who classify it correctly early, staff and prioritize it the way infrastructure actually requires if they choose to keep owning it, and revisit that decision deliberately as the requirements grow — rather than discovering, one enterprise deal at a time, that they've been operating a category of infrastructure without ever having decided to.