Should teams prioritise passwordless authentication before making access more complex for users?

Teams should usually prioritise passwordless options when the current password model is creating avoidable friction and weak user behaviour. The article’s point is that customers and employees lose patience quickly when authentication becomes burdensome, so security should improve without adding unnecessary steps. A practical approach is to move toward simpler, stronger authentication while preserving smooth access for legitimate users.

Why passwordless is usually the better first move

passwordless authentication is often the cleanest way to reduce user friction without weakening the security bar. The practical gain is not “less security”, it is fewer password-driven failure modes: reuse, phishing, help desk resets, and the temptation to choose shortcuts. For many teams, the right sequence is to improve the sign-in experience first, then tighten policy around the remaining high-risk access paths.

That is why phishing-resistant methods such as passkeys, security keys, and device-bound authenticators are usually a stronger answer than simply asking users to tolerate more prompts. When the user journey is simpler, people are less likely to route around controls, and that matters because authentication controls only work when users can complete them consistently.

For teams evaluating rollout options, the most useful reference point is the NIST SP 800-63 Digital Identity Guidelines, which helps distinguish stronger authenticators and phishing-resistant approaches from weaker ones.

Where making access “more complex” backfires

Access gets harder for users when organisations stack extra steps onto already-fragile password flows, such as repeated MFA prompts, reset-heavy support journeys, or inconsistent authentication across systems. That kind of complexity can create the illusion of stronger security while actually increasing password reuse, push fatigue, recovery bypasses, and support exceptions.

A better way to think about the trade-off is that complexity should be added only where it reduces real risk, not where it simply creates inconvenience. If the main control is still a password, then more friction often just shifts behaviour into weaker patterns, including weaker recovery methods and more frequent help desk intervention. The answer is stronger authentication with fewer opportunities for users to make avoidable mistakes.

This is also where a broader identity design matters. A good Workforce Identity Security Guide covers the surrounding controls that make passwordless work in practice, including SSO, federation, recovery, and session security.

One common failure pattern is that organisations modernise the front door but leave recovery, exception handling, and legacy apps unchanged. That creates a split experience where the new method is strong in theory but the weakest path is still available for determined users or attackers.

How to decide what to prioritise first

The best decision rule is to prioritise passwordless when passwords are the main source of friction or weakness, and to phase it in where the user population and applications can support it cleanly. Start with the highest-friction and highest-value populations, usually employees, administrators, and other users whose access is frequent enough that password fatigue becomes operationally meaningful.

For rollouts, prioritise the access paths where a stolen password would create the greatest exposure, then reduce dependency on recovery shortcuts. That is especially important for remote access, privileged access, and workflows where repeated authentication is common. If users still need passwords as a universal fallback, the transition is incomplete and the residual risk remains.

Internal guidance that maps well to this decision is NHIMG’s Passwordless and Passkeys Guide, which focuses on passkeys, FIDO2, rollout choices, and recovery design. For broader program design, the IAM and Identity Provider Buyer’s Guide is useful because it frames passwordless as part of the overall identity platform, not a standalone feature.

Risk and Threat Considerations

When teams keep adding friction without replacing the password model, the main risk is that users and attackers both adapt. Users choose weaker workarounds, while attackers target recovery, help desk resets, session theft, and phishing paths that bypass the original intent of the control.

Failure mechanism: Password-centric flows create predictable weak points, especially where MFA is fatigue-prone, recovery is under-controlled, or legacy access paths still accept old credentials.

Impact: The result is often more account takeover risk, more support exceptions, and less reliable security than a simpler phishing-resistant sign-in design would provide.

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 SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Phishing-resistant authenticators and AAL guidance directly inform passwordless choices.
Recommendation — Use phishing-resistant authenticators and align sign-in assurance to the required AAL.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Passwordless rollout for employees hinges on strong organizational-user authentication.
	IA-5 — Authenticator Management	Passwordless programs still depend on secure authenticator enrollment, rotation, and recovery.
Recommendation — Require stronger organizational-user authentication than passwords for routine access. Control authenticator lifecycle, recovery, and replacement to prevent fallback abuse.
OWASP ASVS	V6 — Authentication	Passwordless is an authentication design decision with verification requirements and fallback risks.
Recommendation — Verify authentication flows, recovery, and reauthentication rules under V6.
ISO/IEC 27001:2022	A.5.15 — Access control	Passwordless decisions change how access is granted and governed across systems.
Recommendation — Define access control rules that prefer stronger sign-in methods over passwords.

Practitioner Guidance

What to prioritise: Move first where password burden is already causing measurable friction, such as frequent sign-in, repeated resets, or heavy help desk volume. Those are the places where passwordless produces both security and usability gains.

What to verify: Before calling a rollout successful, check that recovery, device loss handling, and fallback access are stronger than the password flow you are replacing. A passwordless front end with a weak recovery path is not a real improvement.

Common mistake: Do not treat passwordless as a cosmetic UX project. The real decision is whether the organisation can replace brittle password behaviour with an authentication method users will actually complete and attackers cannot easily replay.

Practitioner takeaway: Prioritise passwordless when it removes friction from a fragile access model, but only if recovery, fallback, and legacy application paths are controlled tightly enough that the new experience is also the safer one.