Passwordless authentication at scale exposes the real IAM rollout gap

At a glance

What this is: RSA’s case study explains how passwordless authentication at scale depends on removing password dependencies, designing recovery and redundancy, and managing employee adoption as an identity programme, not just a technology rollout.

Why it matters: For IAM teams, it shows that passwordless succeeds or fails on lifecycle design, fallback methods, and user behaviour, which directly affects human identity programmes and the controls that surround them.

👉 Read RSA Security's case study on deploying FIDO and passwordless at scale

Context

Passwordless authentication is not just a replacement for passwords. It is an identity architecture change that removes password dependencies from enrollment, recovery, policy enforcement, and day-to-day access flows. If those dependencies remain in place, passkeys become an extra method rather than the operating model.

That distinction matters for human IAM programmes because rollout success depends on how authenticator choice, recovery, and fallback are engineered across the full access lifecycle. RSA’s experience is useful because it shows the practical friction points enterprises meet when they move from pilot to broad deployment.

The case study is typical of large enterprise passwordless journeys: the technology is only part of the problem, while behaviour change, help desk processes, and backup access paths determine whether adoption reaches scale.

Key questions

Q: How should security teams roll out passwordless authentication without causing lockouts?

A: Start by removing password dependencies from enrollment, recovery, and policy exceptions, then require at least two independent authentication methods for users who cannot tolerate downtime. Pilot the new flow in lower-risk applications first, validate help desk procedures, and only then expand to higher-stakes systems. Passwordless succeeds when fallback is governed, not improvised.

Q: Why do passwordless programmes fail even when passkey technology works?

A: They fail when the surrounding identity architecture still depends on passwords or shared secrets, especially in recovery and help desk verification. A passkey can be strong, but if users can bypass the design through weak fallback paths, the programme has not changed the trust model. Adoption also stalls when change management and user education are neglected.

Q: What do IAM teams get wrong about passwordless adoption?

A: They often treat passwordless as a technical launch instead of a governed transition. That leads to weak recovery design, poor sequencing, and user confusion that slows adoption. Teams also underestimate how much behaviour change matters, so they fail to build the training, champions, and deadlines needed to make the new model stick.

Q: How do you know if passwordless authentication is actually working?

A: Look for sustained usage, low fallback-to-password rates, and successful recovery events that do not reintroduce shared secrets. Registration alone is not enough. If employees keep avoiding the primary method or the help desk keeps handling exceptions manually, the programme has not matured beyond pilot behaviour.

Technical breakdown

Why platform architecture has to come before authenticator rollout

Passwordless deployment fails when the organisation treats authenticators as a front-end swap. The deeper issue is whether enrollment, recovery, policy checks, and fallback access still depend on passwords or shared secrets. If they do, the organisation has only added a new credential type without removing the old trust dependency. Device-bound passkeys help because they bind authentication to the device and reduce phishing exposure, but they still need a surrounding architecture that supports recovery, redundancy, and policy enforcement without falling back to weak verification.

Practical implication: remove password dependencies from recovery and policy paths before making passwordless the primary method.

How redundancy and fallback methods prevent lockout

Passwordless systems must assume devices are lost, methods fail, or users cannot complete a single authentication path. The right design uses multiple registered methods, ideally across device types, so access can continue without reintroducing passwords or help desk exceptions. RSA’s example of software-based and hardware-based device-bound passkeys illustrates the broader principle: resilience is not optional in identity, because availability is part of assurance. Without deliberate redundancy, passwordless adoption stalls whenever users fear lockout more than they trust the new method.

Practical implication: require at least two independent authentication methods for each user group where business continuity matters.

Why rollout mechanics matter as much as authentication strength

Enterprise passwordless adoption is shaped by behaviour, not only cryptography. Sequencing lower-stakes use cases before high-stakes systems, using existing mobile footholds, and combining social proof with deadlines all change adoption speed. A strong authenticator does not create compliance by itself. The organisation still has to move users through habit change, education, and friction reduction. In practice, passwordless programmes succeed when they are managed like change programmes with security outcomes, rather than like a one-time technical deployment.

Practical implication: plan passwordless rollout stages around user readiness and business risk, not around infrastructure convenience.

NHI Mgmt Group analysis

Passwordless is an identity architecture problem before it is an authentication problem. The vendor’s case study shows that removing the password from the login screen is not enough if enrollment, recovery, and policy enforcement still depend on password-era assumptions. The important question is whether the organisation has removed the weak links from the identity chain or simply moved them elsewhere. Practitioners should treat passwordless as a programme design issue, not a point solution.

Fallback design is the real control surface in enterprise passwordless. The case study’s emphasis on multiple methods and multiple devices reflects a basic governance truth: authentication resilience has to be engineered before the rollout reaches scale. If one method failure means business disruption, users will resist the new model and help desk exceptions will reintroduce the very shared secrets passwordless was meant to remove. The control gap is not the absence of a passkey, but the absence of a governed recovery path.

Behaviour change is part of IAM assurance, not a separate communications task. RSA’s account of social proof, deadlines, and training shows that adoption curves are driven by programme mechanics as much as by technology quality. That matters because access controls that users do not understand or use consistently are not durable controls. Identity teams should treat communications, onboarding, and champion networks as part of the control environment, not as optional rollout decoration.

Device-bound passkeys sharpen control, but they do not eliminate identity lifecycle obligations. Device binding improves control over where authentication happens, yet organisations still have to manage registration, replacement, revocation, and recovery as lifecycle events. That means IAM, help desk, and endpoint teams need a shared model for what happens when devices are replaced or users change roles. The practitioner conclusion is simple: passwordless maturity is measured by lifecycle governance, not by authenticator novelty.

From our research:

• From our research: 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For the adjacent lifecycle view, see Ultimate Guide to NHIs , Why NHI Security Matters Now for the governance pressure behind identity modernisation.

What this signals

Passwordless adoption will increasingly be judged as a lifecycle control, not an authentication feature. The practical test is whether organisations can register, recover, replace, and revoke authenticators without falling back to passwords or help desk exceptions. That makes the rollout a governance programme that should be measured by operational continuity and exception volume, not just deployment coverage.

The broader signal is that identity teams are moving toward method diversity and controlled fallback as default design principles. Organisations that still treat passwordless as a simple MFA replacement will keep rediscovering the same lockout, recovery, and adoption problems under a new label.

The same programme discipline also matters where non-human identities are involved, because strong access control fails if lifecycle ownership is weak. For teams modernising identity architecture, this is where human IAM and machine identity governance start to converge in practice.

For practitioners

• Remove password dependencies from recovery paths Review enrollment, help desk verification, policy exceptions, and account recovery to ensure no shared-secret step remains as the default fallback. If passwordless still relies on passwords at the edges, the programme has not actually removed the risk.
• Require multiple registered authenticators Set a policy that users should have at least two usable authentication methods where operational continuity matters, and test what happens when one device is lost or one method is unavailable.
• Sequence rollout by user readiness Start with lower-stakes applications and existing mobile authentication footholds before mandating passwordless for high-value systems. Use pilot groups to learn where users get stuck and where documentation needs to change.
• Treat adoption as a control objective Track actual usage, not just registration, and pair training with a clear deadline so adoption does not plateau. Behavioural uptake is part of the control outcome because unused authentication paths do not reduce risk.

Key takeaways

• Passwordless only works at scale when organisations remove password dependencies from the full identity journey, not just the login screen.
• The strongest control in the case study is not the passkey itself but the combination of redundancy, rollout sequencing, and adoption management.
• IAM teams should measure passwordless maturity by recovery resilience, fallback design, and sustained usage rather than by registration counts alone.

Key terms

• Passwordless Authentication: An authentication approach that removes passwords from the primary sign-in flow and replaces them with stronger methods such as passkeys or device-bound authenticators. In practice, the control is only as strong as its recovery, fallback, and lifecycle processes, which must not silently reintroduce shared secrets.
• Device-bound Passkey: A passkey that remains tied to a specific device rather than being freely synced across devices. This improves control over where authentication occurs and reduces phishing exposure, but it also creates lifecycle obligations for registration, replacement, and recovery when devices change or are lost.
• Fallback Authentication Path: A backup method used when the primary authentication route fails, a device is unavailable, or a user cannot complete sign-in. In mature programmes, fallback is deliberately governed so it does not undermine security by defaulting back to passwords or weak verification steps.

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.

This post draws on content published by RSA Security: Deploying FIDO and Passwordless Solutions at Scale. Read the original.