What are the signs that a passwordless programme is too weak to trust?

What makes a passwordless programme untrustworthy?

A passwordless programme becomes hard to trust when the control boundary is unclear. If a user can be enrolled, recovered, or stepped up through a weak identity proofing path, the programme can still be beaten with social engineering, account recovery abuse, or token theft even though no password is present. The question is whether the first-factor replacement is stronger than the password it removed.

Weak enrolment is usually the first sign

The biggest clue is an enrolment flow that accepts low-assurance signals as proof of identity. If support staff can bind a new authenticator after a casual call, if email alone can bootstrap access, or if the process varies by region or user group, the programme is only as strong as its weakest proofing path. That is a trust problem, not just a usability problem.

Passwordless systems also fail when they treat registration and authentication as separate assurance levels. A strong sign of weakness is a design that uses modern sign-in methods, but still allows legacy or manual exceptions to create the account binding. In practice, the attacker does not need to defeat the authenticator if they can compromise the enrolment or recovery workflow.

Recovery and fallback paths reveal the real assurance level

Another warning sign is heavy dependence on fallback channels such as SMS, email reset links, help desk overrides, or shared recovery procedures. These paths often become the easiest way to reintroduce the very impersonation risk passwordless was meant to remove. If recovery is easier to abuse than login is to resist, the programme is not earning trust.

Consistency matters too. A sound programme applies the same proofing strength, device binding, and recovery discipline across all user populations that matter. When executives, contractors, and customers are handled differently without a clear reason, or when some users can bypass stronger controls through exception handling, the organisation has created uneven assurance and a larger attack surface.

Risk and Threat Considerations

Passwordless schemes are attractive to attackers because they often shift the target from password guessing to enrolment abuse, help desk social engineering, and recovery takeover. If the binding step is weak, the attacker can impersonate the user before any strong authenticator is ever in play, which turns a supposed phishing-resistant design into a pre-authentication compromise path.

Failure mechanism: The assurance chain breaks when identity proofing, device registration, and recovery are not held to the same bar as the sign-in method itself. An attacker then targets the seam between systems, not the authenticator, and uses inconsistency or exception handling to register a trusted device or reset access.

Impact: Once an attacker binds their own authenticator or hijacks recovery, they can establish durable access without knowing a password, often with less noise than a traditional credential attack. The result is account takeover that is harder to spot because the login events may appear valid.

Practitioner Guidance

What to verify: Check whether enrolment, recovery, and step-up authentication all require the same identity assurance standard, not just the same user interface. If those paths differ materially, treat the weaker path as the programme's true security baseline.

Decision rule: If a user can obtain or replace a passwordless authenticator through help desk verification, one-time email control, or other low-friction recovery, require tighter proofing or restrict the programme to lower-risk use cases until the gap is closed.

Practitioner takeaway: Passwordless is trustworthy only when the binding and recovery lifecycle is as strong as the authenticator itself; otherwise, the attacker simply moves to the easiest path into account ownership.

Related resources from NHI Mgmt Group

• What are the signs that a privacy-enhancing technology programme is too weak to trust?
• What are the signs that a passwordless programme is too dependent on weak fallback methods?
• What are the signs that a prompt injection benchmark is too weak to trust?
• What are the signs that age verification is too weak for APAC trust and safety requirements?