Build vs buy authentication hinges on SSO, SCIM, and control

At a glance

What this is: This is a build-versus-buy analysis for authentication that concludes managed providers usually win on time, cost, and governance, with DIY reserved for narrow constraint-driven cases.

Why it matters: IAM teams should treat authentication as an identity platform decision, because the wrong choice expands their SSO, lifecycle, audit, and compliance burden far beyond the login page.

By the numbers:

• Paid plans include one Directory Sync connection per app as production Directory Sync connections become separately billed from SSO connections on January 1, 2027.

Context

Authentication is not just a login implementation, it is an identity governance choice that affects how quickly teams can ship, how much security they inherit, and how much compliance evidence they must produce themselves. For most organisations, the build-or-buy question only makes sense once they separate product needs from the controls that will eventually govern SSO, provisioning, and access lifecycle.

This article focuses on the decision boundary between custom auth and a managed identity provider, especially where enterprise features such as SSO, SCIM, RBAC, and session control become unavoidable. That boundary matters because a platform decision made too early can create years of hidden identity debt.

The practical issue is not whether a team can code a sign-in flow. It is whether the team wants to own the full operating burden of authentication, identity provider and SSO security governance, and the controls that sit behind every future access decision.

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 do SSO and SCIM usually push teams toward a managed identity provider?

A: Because those features are governance controls as much as technical integrations. SSO affects federation and user experience, while SCIM governs onboarding and offboarding at scale. Building them correctly means owning protocol correctness, lifecycle logic, and auditability, which is rarely efficient unless identity is the product.

Q: What should security teams check before trusting a managed authentication platform?

A: Confirm how the provider handles recovery, session revocation, exportability, audit logs, and enterprise connection management. The goal is to know whether you can control access lifecycle and exit cleanly if the platform no longer fits. That is the real test of operational trust, not the sign-in widget.

Q: What is the difference between managed authentication and self-hosted identity infrastructure?

A: Managed authentication reduces implementation and maintenance burden, while self-hosted identity infrastructure gives more control but requires the team to own upgrades, monitoring, backups, and compliance evidence. The difference is not just deployment style. It is where identity operations and accountability live.

Technical breakdown

What you actually build when you build authentication

A custom authentication stack is not just a login form. It includes credential lifecycle handling, session issuance, recovery flows, abuse resistance, federation logic, and the ongoing task of tracking protocol and browser changes. Once a team adds SSO, passkeys, or directory sync, the work expands into standards maintenance, identity assurance, and operational monitoring. The hidden cost is that every feature appears simple only until it must survive abuse, outages, and edge cases at scale. See the IAM and Identity Provider Buyer's Guide.

Practical implication: Treat DIY auth as a long-lived platform programme, not a feature project.

Why SSO, SCIM, and RBAC change the economics

Enterprise identity features are not bolt-ons in practice. SSO changes how users authenticate across applications, SCIM changes how accounts are provisioned and deprovisioned, and RBAC changes how access decisions are standardised across teams and apps. Each one adds governance requirements that are expensive to implement correctly from scratch, especially when the organisation needs auditability, offboarding, and consistent tenant isolation. The longer a product lives, the more likely these features become mandatory rather than optional. See the Workforce Identity Security Guide.

Practical implication: Evaluate authentication providers against the enterprise controls you will need later, not only the sign-in flow you need today.

What passkeys and modern sessions really shift

Passkeys, passwordless sign-in, and short-lived managed sessions move complexity out of application code, but they do not eliminate identity design decisions. Passkeys rely on WebAuthn ceremonies, browser support, and recovery handling. Managed sessions trade custom cookie logic for provider-controlled token lifetimes and revocation. The architectural question is whether your team wants to own protocol correctness and session security or consume those controls as a service. See the Passwordless and Passkeys Guide.

Practical implication: Choose the session and authentication model you can operate safely over time, not the one that looks simplest in a quick prototype.

Threat narrative

Attacker objective: The attacker seeks durable access to user accounts and downstream application data by exploiting weak authentication, recovery, or session controls.

1. Entry occurs through authentication paths that are either custom-built or inherited from a managed provider, and weak implementation makes those paths a target for abuse.
2. Credential access follows when attackers exploit weak recovery, leaked passwords, token handling errors, or poorly defended federation flows.
3. Escalation and persistence happen when session management, offboarding, or enterprise access controls are incomplete, letting access outlive the original event.
4. Impact is privilege abuse across applications, tenant boundaries, or account recovery paths, with the organisation absorbing both breach and operational recovery cost.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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-versus-burden decision: the choice is not only about engineering effort, but about who owns the identity control plane over time. A managed provider shifts authentication operations, audit evidence, and lifecycle mechanics into a service model, while DIY makes those obligations permanent internal work. The practitioner implication is that auth architecture should be evaluated as an operating model, not a coding preference.

Enterprise identity features become mandatory much earlier than teams expect: SSO, SCIM, organisations, and RBAC are not premium extras once a product reaches real customers. They are the controls that let identity scale across tenants, joiners, movers, and leavers without bespoke code around every edge case. The implication is that buying too late creates migration pressure when governance needs are already established.

Directory sync is an identity lifecycle control, not just an integration feature: once directory-connected accounts are billable and separately managed, provisioning and deprovisioning choices affect both cost and control ownership. That makes lifecycle governance part of the platform decision itself, especially where enterprise customers expect fast offboarding and consistent session revocation. The implication is that teams should assess whether directory sync is being treated as an auth feature or as a governed access pathway.

Authentication customisation has a ceiling that matters operationally: theming can be enough for many teams, but deep UI and flow changes often require hook-driven work and bespoke error handling. That boundary matters because the more a team departs from defaults, the more it inherits security testing, upgrade friction, and recovery complexity. The practitioner implication is to separate acceptable UX customisation from custom identity logic.

Identity lock-in is not only about exportability of user records: the real test is whether passwords, sessions, memberships, and enterprise connections can be moved without recreating hidden assumptions in the target system. Exportable data reduces exit risk, but it does not eliminate migration design. The implication is that portability should be assessed as a transition process, not a file format.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
• Read next: IAM and Identity Provider Buyer's Guide

What this signals

Identity platform choice becomes a lifecycle decision once enterprise features are in scope: the moment a product needs SSO, SCIM, and org-level access controls, the team is no longer choosing a login library. It is choosing who will govern authentication, provisioning, and recovery as the business scales.

The strongest signal in this kind of decision is not whether a provider can authenticate users today, but whether it can absorb the controls that arrive later without forcing a redesign. That is why teams should look for federation, recovery, and account portability as programme requirements, not optional extras.

Build-versus-buy pressure rises when auth becomes part of the customer promise: once identity is embedded in product delivery, every recovery flow, session policy, and deprovisioning path becomes customer-facing risk. Teams should assume that future enterprise buyers will ask for proof, not just functionality.

For practitioners

• Define the build threshold explicitly Document the narrow conditions that justify custom authentication, such as regulatory restriction, sovereignty, air-gapping, or a dedicated identity team.
• Score providers against future enterprise controls Evaluate SSO, SCIM, org isolation, RBAC, session management, and audit logging before you choose a provider, not after the first enterprise customer arrives.
• Test data portability before commitment Verify export of users, password hashes, memberships, and connection state so a future migration does not turn into a flag-day rebuild.
• Treat recovery and offboarding as first-class requirements Make account recovery, session revocation, and directory-driven deprovisioning part of the selection criteria rather than future implementation work.

Key takeaways

• Authentication should be treated as an identity governance decision because the operating burden extends far beyond the login page.
• The practical tipping point is enterprise readiness, where SSO, SCIM, and RBAC become controls you either inherit or own.
• Managed providers reduce implementation burden, but teams still need to verify portability, recovery, and lifecycle control before committing.

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

Key terms

• Managed Authentication Provider: A managed authentication provider supplies sign-in, federation, recovery, and session services as an external platform. It shifts protocol handling, uptime, and many security controls out of the application team, but the organisation still owns governance, integration decisions, and the business risk of switching later.
• Directory Sync: Directory sync is the operational process of moving identity changes from a source directory into downstream applications. The important distinction is that sync must preserve both data quality and governance scope, otherwise the application receives incomplete or mis-scoped lifecycle events that create access drift.
• 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.
• Credit Portability: Credit portability is the ability to move a loan or credit relationship from one provider to another through a standardised digital process. In open finance, it depends on authenticated participants, governed consent, and auditable settlement so that customer choice does not weaken control.

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 IAM programme, it is worth exploring.