Why does passwordless authentication still create risk if devices or inboxes are not secured?

Why passwordless authentication still depends on the security of the factor source

Passwordless reduces password guessing, reuse, and phishing against a typed secret, but it does not remove the need to trust the device, inbox, push channel, or enrolled biometric. If that source is compromised, reset, or silently approved, the attacker can still complete the login flow. The security question shifts from “Can they learn the password?” to “Can they control the factor path?”

That is why phishing-resistant methods are only as strong as the enrollment, recovery, and device-bound trust model behind them. A passkey on a trusted device is very different from a passkey that syncs into a weakly protected account, and a push prompt is only useful if the approval path resists fatigue, interception, and unauthorized re-enrolment.

The practical risk is not limited to one authenticator type. Email-based passwordless, SMS codes, authenticator apps, recovery links, and biometrics all rely on some upstream account, device, or channel whose compromise can re-create the same access outcome that a stolen password once provided. For implementation guidance on phish-resistant sign-in and recovery design, see the Passwordless and Passkeys Guide.

How attackers bypass passwordless by targeting the mailbox, phone, or enrolled device

Attackers usually do not need to defeat the passwordless protocol itself. They look for the weakest linked control: a compromised inbox that can receive reset links, a stolen phone that can approve prompts, a cloud-synced credential store, a vulnerable device enrollment process, or a help desk workflow that can reissue access too easily. In other words, passwordless can remove one class of credential theft while leaving account takeover paths intact.

Where organizations rely on shared or centrally managed identity platforms, the blast radius can grow quickly. If the factor source is the same device or account used for email, collaboration, recovery, or SSO, compromise of that source can become a single-step path to many services. That is why workforce sign-in architecture must consider the entire trust chain, not only the front-door authenticator; the Workforce Identity Security Guide covers the common failure points in that chain.

Real-world compromises often exploit this exact pattern of indirect trust. A stolen session token, a fatigued approval, or a hijacked recovery path can all defeat a passwordless rollout without ever recovering a password. For examples of how these paths play out in practice, the CitrixBleed exploitation 2023 case shows how session theft can bypass normal login checks, and the Twilio 0ktapus breach 2022 shows how a separate channel can still be abused to gain access.

What security teams should verify before treating passwordless as a control

Passwordless should be evaluated as a system of trust, not as a single authentication method. The most important question is whether the factor source is resistant to takeover, whether recovery is equally strong, and whether the enrolled device or inbox can be reassigned without strong re-verification. A design that is strong at the prompt but weak at recovery is still exploitable.

What to verify: Confirm that enrollment is bound to a trustworthy device or account, that recovery cannot be completed through weak email-only or SMS-only steps, and that push approval cannot be granted from an unattended or shared device. Also confirm that lost-device handling, account reset, and help desk workflows are protected at the same level as initial sign-in.

Decision rule: If the factor source can be accessed independently of the user’s intended control point, treat the environment as at risk for account takeover even if passwords have been removed. If the factor source is a mailbox, phone, or synced account, protect that source first or do not count the deployment as phishing-resistant.

NIST SP 800-63 Digital Identity Guidelines is the most relevant external baseline here because it ties assurance to authenticator strength, phishing resistance, and recovery design rather than to password removal alone.

Risk and Threat Considerations

Passwordless reduces one attack surface, but it can also concentrate risk into a smaller set of higher-value targets: the device, inbox, push channel, recovery flow, or biometric enrollment. When those sources are weak, an attacker can use them to satisfy the login challenge, reset the account, or replay the trust relationship at scale.

Failure mechanism: The attacker compromises or socially engineers the factor source, then uses that source to approve login, receive recovery messages, or re-enrol a new authenticator. The login succeeds because the system trusts the factor source more than it trusts the passwordless promise.

Impact: Account takeover remains possible, often with better persistence than password theft because the attacker may inherit the user’s device, mailbox, session, or recovery path. In larger environments, that can turn one weak channel into repeated unauthorized access across SSO-connected services.

Practitioner Guidance

What to prioritize: Treat device security, mailbox security, and recovery hardening as part of the passwordless rollout itself. If those controls are not already mature, the deployment is not yet delivering its intended risk reduction.

What good looks like: The factor source is protected by strong device posture, recovery is at least as strong as initial enrollment, and administrative override is rare, logged, and independently reviewed. Passkeys or similar authenticators should be paired with clear rules for lost devices, re-enrollment, and exception handling.

Common mistake: Teams often celebrate the removal of passwords while leaving email reset, push fatigue, and device re-enrollment untouched. That creates a false sense of safety because the adversary simply moves to the weakest remaining control.

Practitioner takeaway: Passwordless is strongest when it removes password abuse and equally strong when it prevents the factor source from becoming the new weak link.

Related resources from NHI Mgmt Group

• Why does passwordless authentication still create offboarding risk?
• Why do ephemeral credentials still leave risk in machine access models?
• When does passwordless authentication create more risk than it reduces?
• When does passwordless authentication create more risk than it removes?