Managed vs self-hosted authentication: where AaaS fits best

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Clerk's blog post: Auth-as-a-service decisions compare managed, self-hosted, open-source, and custom authentication models.

Why it matters: It matters because IAM teams need to decide whether authentication belongs in a vendor service, a self-hosted platform, or a build-your-own stack before they inherit the security and operational burden.

By the numbers:

• The guide says basic custom authentication takes about 300 hours and $45,000, while enterprise SSO can take 3 to 6 developer-months and $250,000 to $500,000.
• The Keycloak HA sizing docs say 1 vCPU handles roughly 15 logins per second, and 100,000 active sessions consume about 500 MB of RAM per pod.
• The guide says 53% of consumers have enabled passkeys on at least one account, according to FIDO Alliance research cited by Clerk.

Context

Authentication has become a governance decision, not just an implementation detail. Teams choosing auth-as-a-service are deciding where login policy, credential handling, recovery, session state, and abuse protection will live for the life of the product, and that choice affects identity risk as much as feature delivery.

The managed versus self-hosted split is really about who owns operational accountability. Managed platforms absorb patching, uptime, certifications, and abuse response, while self-hosted and custom models shift those responsibilities back into the engineering and security programme.

For identity programmes, the question is not whether authentication works at launch, but whether the organisation can keep governing it as scale, compliance pressure, and attack volume increase. That is where the build-versus-buy decision becomes an IAM architecture decision, not only a cost decision.

Key questions

Q: When should teams choose managed auth-as-a-service instead of self-hosting?

A: Choose managed auth when the team needs fast delivery, standard login patterns, broad feature coverage, and a lower operational burden than running authentication internally. Self-hosting usually makes sense only when data residency, air-gapping, or highly unusual flows outweigh the cost of owning security, uptime, and maintenance yourself.

Q: Why do custom authentication builds create long-term security risk?

A: Custom auth becomes risky because it must continuously get hashing, session handling, recovery, federation, and audit logging right under active attack. The initial build is only the first cost. After launch, the team still owns patching, response, testing, and every edge case that emerges in production.

Q: How should organisations evaluate lock-in in authentication platforms?

A: Assess whether identity data, session state, entitlements, and user records can be exported and reconstituted without a redesign. If portability is weak, the platform may be easy to adopt but hard to exit. That turns a procurement decision into a long-lived governance dependency.

Q: What should IAM teams compare when weighing managed versus self-hosted auth?

A: Compare who carries security operations, compliance evidence, incident response, and scale management, not just price or feature lists. The right choice is the one that matches the organisation's ability to run authentication as a governed service over time, not just at go-live.

Technical breakdown

Managed AaaS versus self-hosted authentication platforms

Managed auth-as-a-service centralises runtime operations in a vendor service, while self-hosted platforms move those same responsibilities into the customer environment. The architectural difference is not just hosting location. It changes who patches vulnerabilities, who absorbs traffic spikes, who maintains availability, and who proves control effectiveness during audits. A managed service can reduce integration work, but it also introduces dependency on vendor data models, release cadence, and portability mechanisms. Self-hosted platforms preserve more operational control, but the team must run capacity planning, hardening, observability, and incident response itself. The practical distinction is control plane ownership versus service consumption. See the IAM and Identity Provider Buyer's Guide.

Practical implication: treat hosting model selection as an operating-model decision and assign explicit ownership for uptime, patching, and recovery.

Why custom authentication becomes a security and lifecycle liability

Custom authentication is not just a software project. It is a security subsystem that must correctly implement password hashing, session management, token issuance, MFA, account recovery, federation, and logging under active attack. That is why auth logic often fails through timing leaks, session fixation, weak recovery paths, and inconsistent audit trails. Every custom control becomes a permanent lifecycle obligation, because patching, testing, and incident response never stop after launch. In governance terms, custom auth turns identity into application code that must be continuously revalidated against changing threats and standards. The risk is not only initial defects, but long-term drift between the codebase and the security programme. See the MFA Guide.

Practical implication: avoid treating custom auth as a one-time engineering milestone; budget for perpetual security maintenance and review.

Hybrid auth patterns reduce lock-in without removing governance duties

Most real deployments end up hybrid. Webhook sync, custom database connections, custom domains, and token customisation all reduce coupling, but none of them remove accountability for identity data, session claims, or offboarding. These patterns are useful because they separate user experience from some infrastructure dependencies, yet they also create consistency problems across systems of record. The more identity data is copied or embedded, the more carefully teams must govern event ordering, replay handling, and schema drift. Hybrid auth is therefore a governance pattern as much as an architecture pattern. It can reduce vendor dependency, but it does not eliminate identity lifecycle complexity.

Practical implication: define how identity data is synchronised, owned, and retired before adopting any hybrid auth pattern.

Threat narrative

Attacker objective: The attacker seeks durable access to accounts, sessions, or identity flows that can be used for fraud, lateral movement, or persistence.

1. Entry occurs through authentication surface exposure, where poor design or weak controls create a path for credential stuffing, enumeration, or session abuse.
2. Credential harvesting or abuse follows when timing leaks, weak recovery, or lax MFA handling reveal accounts or let attackers reuse legitimate login paths.
3. Impact lands in account compromise, fraudulent access, or governance drift when authentication logic cannot be patched or observed quickly enough.

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

Authentication has become a lifecycle governance problem, not a code choice. The managed versus self-hosted decision changes who owns patching, auditability, abuse response, and data portability for the full life of the product. That means IAM teams should evaluate auth platforms as governed identity services, not as interchangeable implementation shortcuts.

Custom auth creates control debt that compounds over time. Every local implementation of password handling, session state, federation, and recovery becomes a permanent obligation to test, patch, and re-certify. The practical lesson is that the real cost of custom auth is not launch effort but the continuing governance load it creates across engineering and security.

Hybrid identity architectures are useful because they decouple experience from infrastructure, but they do not decouple accountability. Webhooks, custom claims, and BYO domain patterns can reduce lock-in, yet they also create new synchronization and ownership boundaries. Teams need to govern those boundaries explicitly, because the identity record, the session token, and the operational source of truth are rarely the same thing.

Data portability is now part of identity risk management. The guide makes lock-in a governance question rather than a procurement footnote, because the ability to move users, sessions, and entitlements is what determines whether a managed auth choice remains reversible. Practitioners should treat portability as a control requirement, not just a migration convenience.

Feature breadth matters because identity controls fail most often at the edges. MFA, SSO, passkeys, organizations, and machine authentication are not optional extras once a product scales. The more the auth layer must support unusual flows, regulated customers, or service-to-service access, the more important it becomes to decide whether those functions belong in vendor runtime or in a self-hosted stack.

What this signals

Identity portability is becoming a core control, not a migration afterthought. Teams adopting managed auth need to know how quickly they can move users, memberships, and session state if the service changes or the relationship ends. The decision framework should therefore include exit design, not just onboarding design.

Authentication ownership now sits inside broader IAM architecture decisions. As products add SSO, passkeys, machine authentication, and audit logging, the line between application login and identity governance narrows. Programmes that ignore that boundary tend to discover the real cost only when audit, scale, or incident pressure arrives.

For practitioners

• Define the operating model for authentication first Map who owns uptime, patching, incident response, and audit evidence before selecting a managed or self-hosted path. See the IAM and Identity Provider Buyer's Guide.
• Separate identity portability from feature selection Document how user records, memberships, session claims, and recovery data can move if the provider or platform changes.
• Use workload and customer scale as decision gates Set explicit thresholds for MAUs, SSO requirements, and compliance deadlines so the auth choice matches operational reality.
• Treat custom auth as a permanent security programme If you build authentication in-house, assign continuing ownership for testing, vulnerability response, logging, and recovery review.

Key takeaways

• Managed authentication reduces operational burden, but it also shifts identity governance, auditability, and recovery responsibilities into the vendor relationship.
• Custom authentication carries persistent control debt because every login, session, and recovery path becomes part of the security programme.
• The best decision framework is not build versus buy in the abstract, but whether the organisation can govern authentication throughout its full lifecycle.

Related NHI Mgmt Group resources: IAM and Identity Provider Buyer's Guide · Group Managed Service Accounts (gMSA) Guide · MFA Guide · NIST CSF 2.0 Guide

Key terms

• Auth-as-a-Service: Auth-as-a-Service is a managed authentication model where a vendor operates the login and identity infrastructure for an application. It typically includes MFA, federation, recovery, and session handling, shifting operational burden away from the application team while creating dependency on the provider's governance and portability controls.
• Self-Hosted Authorization: An authorization deployment model where the policy control plane runs inside the customer’s environment rather than in a vendor-managed cloud. It is commonly chosen when residency, auditability, or internal integration requirements make local custody of policy data and decision logs non-negotiable.
• Identity Portability: The ability for identity evidence and claims to move across systems, channels, and relying parties without losing integrity or privacy. In delegated commerce, portability only works when claims can be verified by merchants and constrained by policy at the point of use.
• Custom Authentication Backend: A custom authentication backend is a Django component that defines how incoming credentials or tokens are validated and mapped to a user object. It is used when default authentication does not fit the identity flow, such as token-based login, session refresh, or external identity provider integration.

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.