TL;DR: Password-based authentication problems are stopping 60% of US workers from doing their jobs, while just under 60% have contacted IT after being locked out, according to Axiad’s survey of 2,000 office workers. Passwordless only works when the user journey is simpler than the old one, not when it adds another layer of friction.
At a glance
What this is: This is an analysis of how password-based authentication is failing employees and why passwordless programmes only succeed when they reduce friction across the full login experience.
Why it matters: It matters because identity teams cannot treat authentication UX as separate from security, especially when human access, machine access, and zero-trust goals depend on adoption and supportability.
By the numbers:
- 60% of US workers we surveyed said problems with passwords have stopped them from doing their jobs!
- just under 60% also said they had to contact the IT department at their workplace because they were locked out of their computer
- Axiad conducted a survey with 2,000 US office workers last fall
👉 Read Axiad's analysis of passwordless authentication and employee productivity
Context
Passwordless authentication is not just a user experience project. It is an identity control decision that changes how people prove who they are, how often they fall back to weaker methods, and how much support overhead the authentication stack creates. In practice, the challenge is not eliminating passwords in isolation, but replacing them with a flow employees can actually complete without bypassing policy.
Axiad’s survey points to a familiar IAM failure mode: when authentication is too cumbersome, users work around it, delay adoption, or create extra helpdesk load. That behaviour undermines both security and productivity. For identity teams, the real question is whether passwordless design reduces risk while remaining operationally usable across the enterprise.
The article’s starting point is typical, not unusual. Most organisations that struggle with passwordless adoption are dealing with the same trade-off between assurance, ease of use, and supportability.
Key questions
Q: How should organisations roll out passwordless authentication without increasing lockouts?
A: Start by mapping enrolment, recovery, and fallback paths before broad rollout. If users cannot recover access quickly, they will create workarounds or call the helpdesk, which weakens both security and adoption. The most effective programmes standardise policy, simplify the user journey, and monitor lockout rates as a control signal, not just a support metric.
Q: Why do passwordless programmes fail even when the technology is secure?
A: They fail when the user journey is fragmented. Strong authentication is not enough if employees must manage multiple apps, device states, and recovery methods. In that situation, users delay adoption, bypass the intended control, or fall back to weaker methods, which turns a security upgrade into an operational burden.
Q: What do security teams get wrong about multi-factor authentication?
A: They often treat more MFA options as automatically better governance. In reality, too many factors and recovery paths create confusion, inconsistent support, and exception handling. The result is not stronger identity assurance, but more opportunities for users to avoid the intended process and more load on IT.
Q: What should IAM teams do if passwordless adoption increases helpdesk demand?
A: Treat that as a design issue, not a user problem. Review device readiness, recovery steps, and enrolment clarity, then remove the points where employees get stuck. If helpdesk demand rises, the programme has not achieved usable assurance, and the operational friction is undermining the security case.
Technical breakdown
Why passwordless authentication fails when the user journey is fragmented
Passwordless authentication replaces shared or memorised secrets with stronger factors such as phishing-resistant credentials, device-based trust, or PKI-backed login. The technical problem is not the cryptography. It is the experience layer around device setup, recovery, fallback, and support. If employees must remember where to go for each MFA app, device error, or recovery path, the control becomes operationally brittle. Users then revert to older methods or ask IT to rescue them, which creates inconsistency and weakens the intended control.
Practical implication: map every recovery and fallback path before scaling passwordless so users do not reintroduce passwords through exception handling.
How multiple MFA methods create governance drift
When organisations run several MFA products at once, the identity stack can become fragmented even if each tool is individually secure. Different apps, device requirements, and recovery rules create confusion, and confusion drives shadow workarounds. This is an IAM governance issue because the control objective is not just authentication strength, but consistent policy enforcement. A passwordless programme that cannot present one coherent user journey will struggle to sustain adoption, especially for remote workers and employees with varying device maturity.
Practical implication: standardise authentication policy and user support paths before expanding factor diversity across business units.
Passwordless and zero trust depend on adoption, not just capability
Zero trust assumes continuous verification, but that model only works when users can complete authentication reliably without resorting to insecure alternatives. Passwordless can strengthen assurance because it reduces phishing exposure and secret reuse, yet it also shifts dependence onto device trust, provisioning, and lifecycle management. In other words, the security value comes from consistent deployment, not the label on the login method. Where implementation is inconsistent, the programme ends up with stronger controls on paper and weaker behaviour in practice.
Practical implication: measure successful authentication, fallback rate, and helpdesk volume together, because adoption failures are security failures.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Passwordless failure is often an adoption failure, not a cryptographic failure. The article shows that employees bypass controls when the new login path is harder than the old one. That means the real security problem is not whether the method is phishing-resistant, but whether the identity experience is stable enough to survive normal work pressures. Practitioners should treat user friction as a governance signal, not a soft usability concern.
Authentication sprawl creates a user-friction attack surface. Multiple MFA tools, device-specific recovery steps, and inconsistent support routes make it easier for users to delay adoption or ask IT for exceptions. That is a control-plane problem because the policy exists, but the operational path is fragmented. The implication is that programme owners need one coherent authentication journey, not just another factor to deploy.
Human identity controls still fail when rollout design ignores behaviour. Passwordless is a human IAM programme first and a security mechanism second. If remote workers cannot recover access quickly or understand which app to use, the result is shadow fallback, lockout, and productivity loss. Identity teams should judge rollout quality by real user completion rates, not by the presence of the feature itself.
Phishing-resistant authentication only delivers value when lifecycle and support are aligned. Credential strength alone does not solve account lockout, device loss, or recovery complexity. Those are lifecycle and access-management issues that decide whether the stronger method is actually used. The field lesson is straightforward: authentication assurance, onboarding, and recovery have to be governed together, or the programme degrades into partial adoption.
User-centric passwordless design is the named concept that matters here. The article’s core lesson is that stronger authentication must be designed around how employees actually work, not around how IAM teams prefer to administer controls. That shifts the evaluation from feature strength to operational fit. Practitioners should frame passwordless as a user-centric identity governance model, not a standalone login upgrade.
From our research:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
- From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs , Key Challenges and Risks.
- From our research: For the broader governance model behind passwordless and machine access, see 52 NHI Breaches Analysis for root-cause patterns across identity failure modes.
What this signals
User-centric authentication is becoming a governance requirement, not a UX preference. When 60% of workers say password problems stop them doing their jobs, the programme risk is no longer theoretical. Identity leaders should expect pressure to prove that stronger authentication also reduces lockouts, support demand, and exception use.
Passwordless programmes will be judged by operational resilience as much as assurance strength. If users cannot complete the new flow consistently, they will find their own path around it, and that path is often weaker than the one being replaced.
The broader signal for identity teams is that authentication modernisation must be measured end to end. Device readiness, enrolment clarity, recovery design, and helpdesk volume all belong in the same control discussion because they determine whether passwordless actually changes behaviour.
For practitioners
- Map all fallback and recovery paths Document every route users can take when biometric, device, or authenticator-based login fails, then remove any path that silently reintroduces passwords as the default recovery method.
- Consolidate MFA policy and support workflows Reduce confusion by aligning device enrolment, authenticator support, and reset procedures across teams so employees do not need to choose between multiple login systems.
- Measure adoption with operational signals Track successful authentication rates, lockout volume, helpdesk contacts, and fallback frequency together so you can distinguish real security gains from simply shifting the burden to IT.
- Align passwordless rollout with zero-trust governance Treat passwordless as part of broader zero trust design by making sure assurance, recovery, and lifecycle ownership are all defined before broad deployment.
Key takeaways
- Passwordless authentication fails when the user journey is harder than the password it replaces.
- Authentication friction shows up as lockouts, helpdesk load, and shadow workarounds, not just poor user sentiment.
- Identity teams should govern passwordless as a full lifecycle control spanning enrolment, recovery, and support.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Passwordless authentication aligns with digital identity assurance and authenticator choice. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Passwordless supports continuous verification, but only if the user journey is operationally workable. |
| NIST CSF 2.0 | PR.AC-7 | Authentication mechanisms must be usable enough to be deployed consistently across the enterprise. |
Assess authentication controls for usability, adoption, and exception handling as part of access governance.
Key terms
- Passwordless Authentication: A login method that verifies a user without relying on a memorised password as the primary secret. It typically uses phishing-resistant factors such as device-bound credentials, biometrics, or cryptographic keys. In practice, the control only improves security when enrolment, recovery, and fallback are designed to avoid reintroducing weaker methods.
- Authentication Friction: The operational difficulty users experience when completing login and recovery steps. Friction matters because people bypass controls, delay adoption, or contact support when authentication is confusing or slow. In an identity programme, friction is a measurable governance signal, not just a usability complaint.
- Phishing-Resistant Authentication: An authentication approach that is designed to prevent credential replay, interception, or phishing-driven capture. It shifts trust away from shared secrets and toward device-bound or cryptographic proof. The control still depends on lifecycle management, recovery design, and consistent rollout if it is to hold up in real use.
Deepen your knowledge
Passwordless authentication and human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning login flows for remote workers or mixed identity estates, it is worth exploring.
This post draws on content published by Axiad: Say Goodbye to Passwords for Good, Your Employees Will Thank You. Read the original.
Published by the NHIMG editorial team on 2025-09-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org