What breaks when a passwordless login still relies on fallback secrets?

Where passwordless login really fails

Passwordless authentication only delivers its promise when the primary path and the recovery path are both free of weak reusable secrets. If a user can still fall back to a password, SMS code, OTP, or magic link, then the system still depends on a replayable or guessable secret somewhere in the chain. The real control objective is not “remove the password field”, it is “remove the secret class that attackers can reuse.”

That distinction matters because fallback paths often become the easiest place to attack. A strong sign-in front end can coexist with weak account recovery, and the recovery path is where phishing, replay, SIM swap, inbox compromise, and help desk abuse tend to concentrate. The NIST SP 800-63 Digital Identity Guidelines are useful here because they treat authenticator strength and recovery assurance as part of the same trust decision.

For teams rolling out passkeys or other phishing-resistant methods, the architectural question is whether the fallback preserves the same assurance level. If the fallback can be triggered by knowledge factors or weak possession factors, the deployment is only partially passwordless. That is why passwordless programmes usually need parallel changes to recovery, reset, and help desk verification, not just a new login flow.

What attackers target after the primary login is removed

When the obvious credential disappears, attackers shift to the weakest surviving secret, and that is often the recovery channel. A bot may not be able to defeat a passkey prompt, but it may still replay an OTP, intercept a magic link, socially engineer support, or exploit a recovery workflow that trusts an email inbox too much. The attack surface does not vanish, it relocates.

This is why passwordless systems still need to be analysed as an authentication chain, not a single control. OWASP Non-Human Identity Top 10 is relevant because secret leakage, overprivilege, long-lived secrets, and insecure authentication patterns are the same failure modes that make fallback paths exploitable. The question is not whether the first factor is modern, but whether any remaining factor can be abused at scale.

Recovery flows also invite automation. OTP relay, link interception, and code stuffing are attractive because they are cheap to test and easy to industrialise. If a fallback can be replayed, guessed, or socially induced, it becomes the practical primary credential even if the UX still calls the system passwordless.

How to tell whether the control is genuine or just rebranded

A genuine passwordless design should let you answer three questions cleanly: what authenticates the user, what restores access after loss, and what evidence proves the recovery path is at least as strong as the sign-in path. If those answers are different in strength, the weaker one governs the risk posture. The OWASP Cheat Sheet Series is a useful implementation reference for aligning authentication, session handling, and recovery discipline.

Practitioners should also distinguish user convenience from assurance. A magic link can be convenient, but convenience is not proof that the path is resistant to replay or account takeover. Passkeys, FIDO2 security keys, and other phishing-resistant methods work best when recovery requires comparable rigor, such as device binding, step-up verification, or tightly governed support intervention rather than a broadly reusable secret.

The practical test is simple: if an attacker who lacks the main authenticator can still take over the account by abusing fallback steps, then the account is not truly passwordless from a security perspective. The label may describe the primary login experience, but the risk is defined by the weakest remaining path.

Practitioner Guidance

What to verify: Check the entire recovery chain, including reset, re-enrollment, support overrides, and fallback factor issuance. If any step can be completed with a reusable secret that a bot, phisher, or inbox thief can replay, treat the design as incomplete.

Decision rule: If the fallback path is weaker than the primary passkey path, raise the bar on recovery before calling the programme passwordless. If you cannot make recovery equally resistant to replay and social engineering, constrain who can use it and add stronger step-up verification.

What good looks like: The primary authenticator and the recovery process both rely on strong possession or cryptographic proof, with short-lived, tightly scoped recovery events and clear auditability. The support desk should not be able to reset access on the basis of easily harvested knowledge factors alone.

Practitioner takeaway: Passwordless succeeds only when the fallback path is not a softer version of the old password problem. If recovery still depends on reusable secrets, the control has been renamed, not removed.

Related resources from NHI Mgmt Group

• What breaks when account recovery still relies on security questions after passwordless login is deployed?
• What breaks when machine-to-machine access still relies on shared secrets?
• What breaks when passwordless is deployed but fallback authentication still exists?
• What breaks when a product still relies on standing secrets under the CRA?