Passwordless authentication is still constrained by IAM sprawl

At a glance

What this is: This is a vendor-cited analysis of passwordless authentication adoption, with the central finding that IAM sprawl still limits how far password elimination can go in practice.

Why it matters: It matters because identity teams cannot treat passwordless as a standalone control; they have to align it with federation, policy consistency, and lifecycle governance across multiple IAM estates.

By the numbers:

• 70% of respondents have 3 or more IAM ecosystems in use.

Context

Passwordless authentication removes passwords from the login step, but it does not remove the underlying identity architecture that issues, brokers, and governs access. When organisations run several IAM ecosystems at once, the authentication problem becomes a federation and governance problem as well as a user-experience problem.

This article is really about the gap between a modern authentication goal and a fragmented identity operating model. For IAM and IGA teams, the practical question is whether passwordless can be deployed without creating another isolated control plane that adds complexity instead of reducing it.

Key questions

Q: How should security teams roll out passwordless authentication in fragmented IAM environments?

A: Start with a mapped view of directories, federation paths, and application exceptions, then choose the user populations where passwordless can be enforced consistently. The key is to align policy, device trust, and session handling across every IAM ecosystem in scope. If those controls differ materially, the rollout will create uneven assurance and more operational exceptions.

Q: Why does passwordless authentication still fail when IAM sprawl is high?

A: Because removing passwords does not remove the operational complexity behind them. Multiple IAM ecosystems create inconsistent enrollment, recovery, and policy enforcement, so the authentication experience becomes uneven. The risk is not just user friction, but assurance drift across applications that still depend on different trust assumptions.

Q: What are the biggest governance mistakes in passwordless programmes?

A: The common mistake is treating passwordless as a front-end change rather than an identity governance change. Teams often overlook alternate login paths, exception handling, and ownership across multiple identity systems. That leaves weak recovery flows and inconsistent policies in place even after passwords are removed.

Q: What is the difference between passwordless login and zero trust?

A: Passwordless login is an authentication method that removes passwords from the front door. Zero trust is a broader security model that continuously verifies identity, device posture, and access context across the session. A passwordless system can still fail zero trust expectations if it does not re-check risk after login or limit privilege tightly.

Technical breakdown

Why IAM sprawl constrains passwordless rollout

Passwordless depends on coherent identity plumbing: a reliable IdP, consistent policy enforcement, and predictable lifecycle handling for accounts and authenticators. When organisations have multiple IAM ecosystems, each environment may handle enrollment, recovery, session assurance, and device trust differently. That fragmentation makes it harder to standardise assurance levels across applications, especially where federation or step-up authentication is still required. The result is not a failure of passwordless itself, but a mismatch between the control and the estate it has to sit inside.

Practical implication: Map which applications can share a single assurance model before expanding passwordless beyond a pilot domain.

How phishing resistance changes the authentication design

Phishing resistance is one of the main reasons organisations pursue passwordless. The security gain comes from moving away from reusable secrets and toward cryptographic authenticators tied to the device or platform, which reduces credential replay risk. But that benefit only holds if account recovery, alternate login paths, and fallback authentication do not reintroduce weaker methods. In other words, the attack surface shifts from password capture to process gaps around enrollment, recovery, and exception handling.

Practical implication: Review recovery and fallback flows with the same scrutiny as primary authentication, because those paths often become the weakest link.

Zero Trust still depends on identity consistency

Passwordless is often positioned as a foundation for Zero Trust because it can strengthen authentication assurance, but Zero Trust also requires continuous evaluation of identity, device, and session context. If authentication is modernised in one part of the estate while policy enforcement remains inconsistent elsewhere, trust decisions become uneven. That creates a split model where some access paths are strongly verified and others remain governed by legacy assumptions. Passwordless improves the front door, but Zero Trust only works when the rest of the identity fabric is equally disciplined.

Practical implication: Align passwordless deployment with policy consistency across applications, devices, and federation boundaries.

NHI Mgmt Group analysis

Passwordless does not eliminate identity sprawl, it exposes it. The real constraint is not user adoption but architectural coherence across multiple IAM ecosystems. When authentication is distributed across IdPs, directories, and legacy application trust chains, passwordless becomes an overlay rather than a reset. Practitioners should treat the rollout as an estate integration programme, not a feature toggle.

Phishing resistance is only durable when fallback paths are equally strong. The value of cryptographic authentication is eroded when recovery, enrollment, or exception handling still depends on weaker verification. That is where modern authentication programmes often leak assurance. The control question is whether every alternate path preserves the same trust level, not whether the primary method is passwordless.

Zero Trust and passwordless are related, but not interchangeable. Passwordless can improve initial assurance, yet Zero Trust also needs continuous policy evaluation and session-level context. If organisations modernise login without harmonising authorization and lifecycle controls, they create an uneven trust fabric. The implication is that passwordless should be governed as part of the broader identity operating model, not as a standalone authentication upgrade.

IAM sprawl is now a programme design problem, not just a tool problem. Multiple identity ecosystems force security teams to decide where the authoritative authentication path lives, how policy is synchronised, and which exceptions are acceptable. That is a governance issue as much as a technical one. The market signal is that passwordless adoption will increasingly depend on consolidation, federation discipline, and cleaner identity boundaries.

Ephemeral trust debt: passwordless reduces secret reuse, but organisations still carry trust debt in recovery, exception, and federation layers. That debt accumulates whenever modern authentication is layered onto legacy IAM without reworking the surrounding control model. Practitioners need to measure how much residual trust still depends on old paths.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
• Read next: Passwordless and Passkeys Guide

What this signals

IAM sprawl is the limiter: passwordless only creates real security value when the surrounding identity fabric can enforce the same assurance across directories, applications, and recovery paths. In mixed estates, the control boundary shifts from the login screen to federation and lifecycle governance.

Passwordless programmes should be judged by how much legacy authentication debt they remove, not by whether they support a modern sign-in flow. If fallback paths still depend on weaker verification, the programme has modernised the interface without fixing the trust model.

For practitioners

• Audit IAM ecosystem fragmentation Inventory every directory, IdP, and application trust boundary that participates in authentication. Identify where passwordless can be enforced end to end and where legacy fallback paths would undermine assurance.
• Harden recovery and fallback flows Review enrollment reset, account recovery, and break-glass processes so they do not reintroduce password-based or weakly verified access paths.
• Standardise assurance policies across apps Define the assurance level required for each application tier and align federation, device trust, and session policy accordingly.
• Use passwordless as part of consolidation planning Treat passwordless adoption as a forcing function to rationalise duplicate IAM control planes and remove unnecessary identity silos.

Key takeaways

• Passwordless authentication reduces reliance on reusable secrets, but fragmented IAM estates still determine how secure and consistent the outcome will be.
• The article’s key evidence is that 70% of respondents operate three or more IAM ecosystems, which explains why integration matters more than the login method alone.
• Teams should evaluate recovery paths, federation consistency, and policy alignment before scaling passwordless beyond isolated use cases.

Key terms

• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
• IAM sprawl: IAM sprawl is the uncontrolled growth of identities, roles, permissions, and access paths across systems. It happens when accounts, entitlements, policies, and exceptions multiply faster than they are governed. In practice, it creates hidden privilege, weak accountability, and difficult audits because no single team can reliably see or manage the full access landscape.
• Phishing Resistance: Phishing resistance is the ability of a user and an authentication process to withstand impersonation attempts and malicious requests. It depends on stronger verification habits, safer authenticators, and workflows that make it harder to accept fraudulent prompts.
• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.

Deepen your knowledge

NHI governance, IAM, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity programme, it is worth exploring.