TL;DR: As teams scale, Ory Kratos can become costly and operationally heavy, especially when enterprise needs such as SSO, multi-tenancy, MFA, and agent-ready access enter the picture, according to Descope. The real issue is that self-hosted identity infrastructure often outgrows the assumptions baked into early-stage auth design.
At a glance
What this is: This is an analysis of why teams look for Ory Kratos alternatives when self-hosted identity starts to strain under enterprise IAM requirements.
Why it matters: It matters because the scaling pain shows up in governance, support, and feature gaps that IAM teams must absorb across human users, NHIs, and AI-ready access patterns.
Context
Ory Kratos is an open-source identity and user management system, but the article argues that self-hosted identity becomes harder to sustain once organisations move beyond early-stage authentication needs. The central problem is not just deployment style, but the widening gap between what a basic auth stack can do and what enterprise identity governance now demands.
As applications grow, teams run into upgrade friction, manual SSO setup, claim mapping, schema changes, and tenant isolation gaps. In NHIMG terms, this is where identity stops being a feature and becomes a lifecycle and governance discipline spanning human IAM, non-human access patterns, and platform operations.
Key questions
Q: Why do self-hosted identity systems become harder to manage at enterprise scale?
A: They accumulate upgrade effort, configuration drift, tenant isolation gaps, and support overhead that basic auth design does not remove. Once identity becomes a shared platform service, the cost of maintaining custom wiring and security review cycles often exceeds the value of keeping everything self-hosted.
Q: When should teams move from a self-hosted auth stack to a managed IAM platform?
A: Teams should revisit the choice when identity work starts pulling engineering time away from product delivery, when enterprise features require heavy custom code, or when support and scaling expectations exceed what the original stack was designed to absorb. The trigger is operational strain, not vendor fashion.
Q: What breaks when multi-tenancy is added on top of a basic auth library?
A: What breaks is usually the boundary model. Invitation flows, role assignment, admin separation, and tenant-scoped permissions often need custom logic that is easy to get wrong. Without a native tenant model, teams end up translating governance rules into application code, which increases the chance of privilege leakage and inconsistent enforcement.
A: They should test whether the platform can connect authentication, entitlement, and behaviour data across users, service accounts, tokens, and certificates. Coverage matters less than operational reach, so ask whether it can drive ownership, rotation, and response from one control plane instead of separate tools. That is the real indicator of programme maturity.
Technical breakdown
Why self-hosted identity stacks become operational debt
Self-hosted identity systems create their own maintenance layer because every change to login, SSO, claims, or schema has to be owned by the application team. That means the identity layer behaves less like a shared service and more like another product to run. The article’s point is not that self-hosting is wrong, but that it changes identity from a capability into a continuous engineering obligation, especially once scale, security review, and support expectations rise.
Practical implication: treat self-hosted auth as an operating commitment with explicit ownership, upgrade cadence, and support thresholds.
Why enterprise identity features matter at scale
Enterprise IAM requirements such as SSO, MFA, tenant isolation, and fine-grained authorization are not add-ons once an organisation serves multiple customer segments or business units. They shape how access is issued, separated, and reviewed. When those functions are missing or heavily custom-built, the result is usually more glue code, more configuration risk, and weaker consistency across environments. In practice, the identity architecture starts to reflect the limits of the original design assumptions rather than the needs of the business.
Practical implication: evaluate whether SSO, MFA, and tenant isolation are native controls or custom workarounds before the platform becomes embedded.
Why agent-ready identity changes the selection criteria
The article’s mention of AI agents and MCP-based ecosystems shows that identity is no longer only about human sign-in flows. Agent-ready access requires a model that can support both human users and non-human execution paths without stitching together separate tooling. That shifts the question from authentication only to identity orchestration across actors, sessions, and access boundaries. A platform that cannot represent those boundaries cleanly will be expensive to extend later.
Practical implication: assess whether the identity stack can govern human and non-human access paths with the same lifecycle controls.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Self-hosted identity creates lifecycle debt once scale exposes hidden control costs: The article shows that early flexibility can turn into persistent operational drag when upgrades, schema changes, and SSO wiring become routine work. That is not a tooling preference issue, it is a governance issue because identity controls now consume engineering capacity that should be reserved for product and risk management. The practitioner conclusion is to measure identity by lifecycle cost, not by initial deployment freedom.
Enterprise features stop being optional when identity is a platform service: Multi-tenancy, MFA, SSO, and fine-grained authorization are the controls that separate isolated customer or business-unit access from shared risk. When they are absent or heavily custom-built, the organisation inherits fragile access patterns and inconsistent policy enforcement. The practitioner conclusion is to test whether identity can support the business model without bespoke control stitching.
Agent-ready identity expands the scope of IAM beyond human authentication: The article’s agentic identity references matter because access is no longer confined to people and browsers. Human IAM assumptions break when applications also need governed access paths for agents and other non-human actors. The practitioner conclusion is that identity architecture now has to support multiple actor types without fragmenting governance.
Managed identity is becoming a scaling control, not just a convenience choice: The market signal in this article is that organisations are moving from build to buy when identity upkeep starts to compete with core engineering work. That does not eliminate governance responsibility, but it changes where teams expect policy enforcement, support, and scaling reliability to live. The practitioner conclusion is to decide early which parts of identity belong in-house and which should not.
Identity selection is now a business architecture decision: The article highlights that the best alternative is not simply the cheapest or most flexible option, but the one that matches tenant isolation, support, and cross-platform growth requirements. That means IAM leads, architects, and platform teams need a common decision frame instead of treating identity as a back-end implementation detail. The practitioner conclusion is to align identity choice with operating model and growth path.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
What this signals
Identity governance now competes with product engineering when auth is self-hosted: The hidden cost is not the software licence, it is the control work that never ends. Teams should expect identity to consume more of the programme budget as SSO, MFA, tenant separation, and support expectations multiply across environments.
Agent-ready identity is changing the buying criteria for IAM platforms: Once applications must authenticate both people and AI agents, the platform has to support multiple actor types without separate governance patterns. That pushes selection toward systems that can represent access boundaries cleanly instead of depending on bespoke integration work.
Enterprise IAM is becoming an operating model choice, not a feature checklist: The question is no longer which login methods a platform supports, but who owns upgrades, policy drift, and support when the identity layer scales. That makes the architecture decision a governance decision.
For practitioners
- Map identity cost to lifecycle ownership Track the engineering hours, upgrade frequency, and support burden tied to your current auth stack before deciding whether self-hosting remains viable.
- Test native enterprise controls early Verify that SSO, MFA, tenant isolation, and fine-grained authorization are built in rather than assembled through custom code or fragile integrations.
- Assess support for agent-ready access paths Check whether the platform can govern both human users and non-human actors without separate auth models or duplicated policy logic.
- Separate platform selection from implementation habit Review whether the current identity architecture still matches your deployment model, support expectations, and cross-platform growth plans.
Key takeaways
- Self-hosted identity can be flexible early on, but it often turns into recurring operational debt once enterprise requirements and scaling pressure increase.
- The article points to recurring pain in SSO, multi-tenancy, MFA, upgrades, and support, which are exactly the controls that make identity usable at scale.
- The practical response is to treat identity platform choice as a lifecycle and governance decision, not just a developer convenience decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article’s scaling and tenant isolation issues map to over-broad access patterns in identity design. |
| NHI-08 — Environment Isolation | Multi-tenancy and tenant separation are central to the article’s enterprise scaling concerns. | |
| Recommendation — Audit identity boundaries for over-broad access and remove assumptions that one auth model fits every tenant. Design tenant isolation as a first-class control rather than a custom layer on top of shared auth services. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article explicitly extends identity choice into agent-ready access and privilege boundaries. |
| Recommendation — Apply agent identity controls where human and non-human access paths share the same application environment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on how entitlements and authorization scale when identity becomes enterprise-wide. |
| GV.PO-01 — Policy and Strategy | Platform selection here is a governance decision tied to operating model and growth strategy. | |
| Recommendation — Review authorization design whenever identity moves from a simple login layer to a governed platform service. Set identity platform policy around lifecycle ownership, support, and scaling expectations before selecting a stack. | ||
Key terms
- Self-hosted identity infrastructure: Identity services that the organisation installs, upgrades, secures, and operates itself. In practice, this means the team owns availability, patching, integration maintenance, and policy drift, which can become a material operating burden as authentication requirements expand.
- Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
- Agent-ready identity: An identity model that can authenticate and govern AI agents as non-human actors alongside human users. It requires runtime access controls, delegation boundaries, and revocation paths that fit machine behaviour rather than assuming all access begins with a person’s login session.
- Identity Orchestration: Identity orchestration is the control layer that routes identity decisions across applications and environments instead of letting each system manage access independently. For agents, it is the mechanism that can centralise policy, auditing, and downscoping at runtime.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org