Ory Kratos alternatives highlight enterprise IAM’s scaling limits

At a glance

What this is: This is Descope’s comparison of Ory Kratos alternatives, with the key finding that self-hosted identity becomes harder to maintain as enterprise auth requirements expand.

Why it matters: IAM teams should read this as a reminder that authentication architecture, tenancy design, and lifecycle controls need to scale together across human and non-human identities.

👉 Read Descope’s comparison of Ory Kratos alternatives for enterprise identity teams

Context

Ory Kratos alternatives become relevant when authentication stops being a build-time decision and becomes an operating model question. The article’s core point is that self-hosted identity can create upgrade, support, and scaling friction once enterprise features like SSO, multi-tenancy, and MFA are required.

For IAM and identity architecture teams, the deeper issue is not whether open source is viable. It is whether the chosen model can support enterprise governance across human users, service identities, and agent-ready access patterns without turning identity into a parallel engineering programme.

Key questions

Q: What should teams check before replacing a self-hosted identity platform?

A: Teams should test whether the replacement can handle SSO, MFA, tenant isolation, authorization, and lifecycle controls without heavy custom code. The key question is not feature count but whether policy can be enforced consistently as the organisation grows. If identity still requires frequent engineering intervention, operating cost will keep rising even if the licence cost drops.

Q: When does self-hosted identity become the wrong choice?

A: Self-hosted identity becomes risky when uptime, upgrades, and integration changes start competing with product delivery. That usually happens once enterprise customers, multiple tenants, or compliance requirements make auth a permanent operational service rather than a one-time implementation. If the team cannot keep pace with version changes and policy updates, the model has outgrown its original use case.

Q: How do security teams know if identity controls are drifting into custom code?

A: Look for repeated exceptions in claims mapping, manual SSO setup, role logic inside applications, and policy decisions scattered across services. Those patterns show that identity governance is no longer centralised. Once access rules live in too many places, audits become harder and recertification loses reliability.

Q: How should organisations think about AI agents in their identity model?

A: AI agents should be treated as non-human actors that need authenticated access, scope boundaries, and revocation paths just like other machine identities. If the platform only supports human login flows, teams will end up building separate controls for agent access and lose governance consistency across the programme.

Technical breakdown

Why self-hosted identity becomes expensive at scale

Self-hosted identity platforms shift the burden of uptime, upgrades, schema changes, and integration maintenance onto the product team. Once authentication is tightly coupled to application logic, every change in tenant model, IdP mapping, or login flow can become a release dependency. That creates a structural drag on delivery because identity is no longer a shared service with stable operating boundaries. In enterprise settings, the cost is rarely the licence itself. It is the engineering time consumed by keeping auth aligned with changing business and compliance requirements.

Practical implication: treat identity platform selection as an operating-cost decision, not just a feature checklist.

Enterprise SSO, RBAC, and multi-tenancy are not add-ons

The article highlights a common scaling failure: teams start with core authentication but later need tenant isolation, fine-grained authorization, SSO setup, and lifecycle features that were never native to the original design. Multi-tenancy is especially difficult because tenant boundaries affect every part of the identity stack, from claims mapping to policy enforcement. RBAC helps only when roles map cleanly to business boundaries, which is often not true in customer-facing or partner-facing applications. The result is custom code that grows faster than governance maturity.

Practical implication: validate tenant isolation, authorization depth, and lifecycle fit before identity becomes embedded in production workflows.

Agent-ready identity changes the auth requirement set

The article’s most forward-looking point is that identity is no longer only about human sign-in. Agentic workflows need authenticated runtime access, delegated permissions, and clear separation between human and machine actors. That means the identity layer must support both user journeys and non-human execution contexts without forcing teams to stitch together separate systems. In practice, agent-ready identity is an NHI governance problem as much as an application auth problem because access scope, delegation, and revocation all become cross-actor concerns.

Practical implication: design identity controls so human and machine access can be governed together, not as two disconnected stacks.

NHI Mgmt Group analysis

Self-hosted auth often fails because it turns identity into a hidden platform team. The article describes upgrade pain, manual SSO wiring, and scaling overhead as the main reasons teams move on from Ory Kratos. That pattern matters because identity governance loses visibility when engineering work is absorbed into bespoke auth maintenance instead of centralised controls. Practitioners should read this as an operating-model warning, not just a tooling preference.

Enterprise auth requirements expose the gap between authentication and governance. Support for SSO, MFA, tenant isolation, and lifecycle controls is not just about user convenience. It is about whether identity can express policy cleanly enough for audits, access reviews, and least-privilege enforcement. When those controls rely on custom code, the governance model becomes fragile and difficult to recertify at scale. The implication is that identity architecture and identity governance cannot be separated for long.

Agent-ready applications force identity teams to govern more than human sessions. The article’s mention of AI agents and MCP-based ecosystems shows where identity is heading. Once software actors can initiate actions, the old assumption that authentication ends at user login is no longer sufficient. NHI governance becomes the baseline, and human IAM must interoperate with it instead of sitting beside it. Practitioners should expect the auth layer to carry both user and machine accountability.

Runtime identity sprawl is the named concept this comparison exposes. The real problem is not that Ory Kratos lacks one feature, but that authentication requirements accumulate faster than teams can govern them. Runtime identity sprawl appears when login, tenancy, authorization, and delegation logic spread across application code and infrastructure. That makes policy drift more likely and recovery slower. Practitioners need an architecture that keeps identity state authoritative rather than scattered.

OWASP NHI Top 10 concerns are already visible in this migration pattern. The article repeatedly points to custom auth glue, unsupported enterprise features, and growing machine-access use cases. Those are the conditions where secret handling, workload identity, and access scope become harder to reason about. The governance lesson is that identity platforms should reduce the number of places where privileges are encoded. Teams should treat sprawl as a risk signal, not a growing pains story.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That makes OWASP Agentic Applications Top 10 the right next step for teams formalising agent access governance.

What this signals

Runtime identity sprawl is now the practical risk hidden inside modern auth migrations. As teams add tenants, workflows, and agent-facing access paths, they should expect identity logic to spread unless it is deliberately centralised. The result is not only operational friction but a weaker governance surface that is harder to audit, review, and revoke cleanly.

The most important programme signal is that identity is becoming a cross-actor control plane, not a user login layer. That means human IAM, NHI governance, and agent-ready access models need to converge around the same policy and review discipline. Teams that keep these stacks separate will struggle to explain accountability when access spans people, services, and software actors.

As AI adoption rises, the governance bar shifts from proving authentication works to proving that access can be bounded, observed, and retired across every actor type. The practical next move is to align platform choices with lifecycle control, not just developer convenience.

For practitioners

• Map identity maintenance cost to business scale Count upgrade effort, SSO configuration time, schema change effort, and support overhead alongside direct platform costs. Compare that burden against the team’s expected growth in tenants, integrations, and compliance demands before committing to a self-hosted model.
• Test enterprise features against real governance cases Validate whether the platform can handle tenant isolation, SSO setup, MFA policy, and access review requirements without custom glue code. Use one representative customer, partner, and internal user flow to see where policy enforcement breaks down.
• Separate human auth from machine access requirements Document where users, service accounts, and AI agents share the same identity plane and where they need distinct controls. If the platform cannot represent non-human access cleanly, add governance boundaries before agentic or workload use expands.
• Audit where identity logic lives today List every place claims mapping, tenant routing, role assignment, and MFA logic are implemented. If policy is embedded across application code and infrastructure, the programme is already carrying avoidable runtime identity sprawl.

Key takeaways

• Ory Kratos alternatives are primarily a governance story, because scaling identity means scaling maintenance, policy enforcement, and supportability together.
• Enterprise needs such as SSO, multi-tenancy, MFA, and agent-ready access expose whether authentication is still a product feature or has become critical infrastructure.
• The strongest programmes will centralise identity logic and treat machine access as part of the same governance model as human authentication.

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: The separation of identity data, policies, and access boundaries between customer or business tenants. Strong tenant isolation prevents one tenant’s configuration or credentials from affecting another, and it is a core requirement for B2B and multi-tenant SaaS governance.
• 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.
• Runtime identity sprawl: The growth of identity logic across code, services, and infrastructure instead of keeping it under a single governed control plane. This makes access harder to audit, reviews harder to trust, and revocation harder to prove, especially when humans, services, and agents share the same environment.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• Side-by-side feature breakdown of each Ory Kratos alternative across SSO, MFA, and tenant management.
• Practical product-fit guidance for teams choosing between managed and self-hosted identity models.
• Developer-oriented implementation details for auth workflows, SDK coverage, and integration setup.
• Platform-specific notes on how each option supports multi-tenant SaaS and emerging agent-ready use cases.

👉 Descope’s full post includes the feature-by-feature comparison, deployment trade-offs, and implementation context behind each alternative.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.