Ping Identity migration pressure shows IAM leader claims are eroding

At a glance

What this is: Ory argues that customer migration away from Ping Identity is being driven by cost, scaling, usability, and complexity concerns in IAM programmes.

Why it matters: IAM teams should treat this as a signal to test whether their identity platform is creating friction in authentication, federation, and access control operations.

👉 Read Ory's analysis of why customers are leaving Ping Identity

Context

Identity and access management platforms fail when they create more operational friction than control value. In this article, the underlying issue is not a feature checklist but whether the IAM stack can support modern application, partner, and workforce access without increasing cost and administrative overhead.

For practitioners, that question reaches CIAM, B2B federation, and access governance at the same time. When a platform becomes hard to scale or hard to use, teams often absorb the complexity in custom workarounds, which then weakens consistency across authentication, authorisation, and lifecycle management.

Key questions

Q: When does an IAM platform become too complex to keep operating effectively?

A: An IAM platform becomes too complex when routine changes depend on custom code, repeated exceptions, or scarce specialists to keep core access flows stable. That is usually the point where the cost of maintenance starts to undermine consistency, upgrade velocity, and governance. Complexity is not just a technology issue. It becomes a control risk when teams cannot operate the platform predictably.

Q: Why does poor IAM user experience matter to security teams?

A: Poor IAM user experience matters because people and developers route around friction. If login, recovery, federation, or step-up flows are cumbersome, organisations see more support load, more workaround behaviour, and weaker adherence to intended controls. In IAM, usability is part of enforcement. If the journey is painful, adoption drops and the policy design loses effect.

Q: How should teams decide whether to keep custom IAM or move to a platform model?

A: Teams should keep custom IAM only where the identity model is tightly bounded, well understood, and not expected to support broad reuse across applications or actor types. If identity must feed security, analytics, compliance, and automation, a platform model usually creates less drift and more governable consistency than bespoke code.

Q: What is the difference between a technically secure IAM system and a usable one?

A: A technically secure IAM system may enforce good policy, but a usable one can do so without creating friction that drives workarounds or inconsistent adoption. Security teams need both. If users, developers, or administrators avoid the intended path because it is too difficult, the effective control weakens even though the design looks sound on paper.

Technical breakdown

Why IAM platform complexity becomes an operating risk

IAM complexity is not only a delivery problem. It becomes an operating risk when policy, federation, and application integration require repeated manual exceptions, bespoke maintenance, or specialist knowledge to keep core flows working. At that point, the platform is no longer just enforcing access decisions, it is shaping how much technical debt the identity programme accumulates. In practice, complexity also increases the chance that teams defer upgrades, avoid standard features, or build fragile custom paths around the platform rather than through it.

Practical implication: measure how much IAM change depends on custom code, manual configuration, or specialist intervention before platform sprawl becomes permanent.

Scaling identity services across applications and regions

IAM scaling is about more than throughput. It includes how reliably a platform handles growth in users, tenants, protocols, and regional deployments without forcing redesigns in authentication, session management, or policy enforcement. Where scaling is weak, organisations often experience inconsistent user journeys, slower rollout cycles, and uneven control maturity across business units. That matters because identity becomes a shared dependency for every application that touches customer or workforce access.

Practical implication: test whether the platform can support new business units or regions without adding separate operational patterns or duplicated identity estates.

User experience as an IAM control factor

User experience is often treated as a convenience issue, but in IAM it directly affects adoption, support burden, and workarounds. If sign-in, step-up checks, federation, or recovery flows are cumbersome, users and developers look for shortcuts that bypass intended controls. Poor usability therefore reduces the practical effectiveness of otherwise sound IAM design. A platform that is technically secure but operationally awkward can still produce weaker security outcomes because people route around it.

Practical implication: evaluate the identity journey from the user and developer perspective, not just from the policy designer's view.

NHI Mgmt Group analysis

Complexity becomes the decisive migration trigger when IAM stops fitting the operating model. The article’s core signal is not simply that customers dislike a product, but that the cost of keeping it aligned with modern access patterns is becoming too high. In identity programmes, operational complexity often matters more than feature breadth because complexity creates delays, exceptions, and workarounds that outlive any single deployment decision. Practitioners should read this as a governance stress test, not a vendor story.

Identity friction is a programme risk, not a user-interface complaint. When authentication, federation, and access administration become difficult to run at scale, teams pay for it in support load, inconsistent controls, and slower change velocity. That undermines the credibility of the IAM platform across CIAM, workforce access, and partner identity. The practical conclusion is that usability and maintainability are control characteristics, not cosmetic qualities.

Platform sprawl: when an IAM stack requires too many adjacent tools, custom exceptions, or specialist skills to operate, the identity architecture itself becomes the source of governance drift. This is the kind of fragmentation that makes policy consistency harder to maintain across applications and business units. Once the operating model depends on exceptions, the platform is no longer standardising access, it is multiplying it. Practitioners should treat sprawl as a lifecycle and governance issue, not a procurement preference.

Modern IAM buying decisions are shifting from brand trust to operational proof. Teams are increasingly evaluating whether platforms can support scale, migration, and developer adoption without creating hidden integration debt. That change matters because identity is now part of delivery speed as much as security assurance. The organisations that win here are the ones that can prove low-friction control at runtime, not just in presentations.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• This points to a broader governance problem documented in the Ultimate Guide to NHIs: control design fails when operational discipline does not keep pace.

What this signals

Platform sprawl: IAM programmes that accumulate custom integrations and exception paths tend to hide complexity until change velocity slows. The practical signal is not only support tickets, but also longer release cycles and more frequent identity-related workarounds that create policy drift.

Identity teams should treat migration pressure as a governance indicator. When users, developers, and administrators all feel friction, the platform is likely absorbing business complexity instead of reducing it, which is exactly where IAM programmes start to lose control consistency.

For practitioners

• Audit identity-related operational debt Map where the current IAM stack depends on custom flows, manual exception handling, or specialist knowledge to keep core authentication and federation paths working.
• Measure scaling pressure across access journeys Test onboarding, application integration, and regional expansion scenarios to see where the platform needs redesign, duplicated configuration, or extra support effort.
• Review user and developer friction Track where login, recovery, federation, or step-up flows push users and developers toward workarounds that weaken intended controls.
• Reassess platform fit against the operating model Compare the identity stack with current delivery patterns, cloud adoption, and governance expectations to decide whether complexity is being absorbed as permanent overhead.

Key takeaways

• The article points to a familiar IAM failure pattern: complexity, cost, and poor usability eventually outweigh platform familiarity.
• For practitioners, the important signal is not vendor preference but whether the identity stack can scale without customisation debt and control drift.
• IAM decisions should now be judged by operational fit, because friction in authentication and federation directly affects security outcomes.

Key terms

• Identity Platform Sprawl: Identity platform sprawl is the condition where an IAM environment accumulates overlapping tools, custom flows, and exception paths that make governance harder rather than easier. It usually shows up as duplicated configuration, inconsistent enforcement, and higher operational cost across teams and applications.
• Federation Friction Debt: Federation friction debt is the accumulated operational and governance burden created by fragmented login redirects, inconsistent account linking, and duplicated recovery paths. It often appears harmless until teams try to improve conversion or modernise identity flows and discover the underlying controls are brittle.
• Identity operating model: The set of processes, controls, and ownership rules used to manage access across human, non-human, and autonomous actors. In agentic environments, it must connect identity, policy, audit, and revocation so governance does not fragment across platforms.

What's in the full article

Ory's full article covers the migration pressure and product comparison detail this post intentionally leaves for the source:

• Customer-facing reasons teams cite for moving away from Ping Identity, including cost and complexity trade-offs.
• The specific product and deployment considerations behind migration decisions rather than the high-level governance view.
• How organisations compare authentication, scale, and user experience when evaluating alternatives.
• The full context behind the article's alternatives framing and what it suggests about buyer expectations.

👉 The full Ory article covers the migration drivers, alternative choices, and operating trade-offs in more detail.

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.