Notifications
Clear all
Topic starter
06/07/2026 9:40 am
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.
NHIMG editorial — based on content published by Descope: The Top 7 Ory Kratos Alternatives
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map identity maintenance cost to business scale Count upgrade effort, SSO configuration time, schema change effort, and support overhead alongside direct platform costs.
- 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.
- 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.
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.
👉 Read Descope’s comparison of Ory Kratos alternatives for enterprise identity teams →
Ory Kratos alternatives: where self-hosted identity starts to strain?
Explore further
06/07/2026 9:55 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Ory Kratos alternatives highlight enterprise IAM’s scaling limits
