What are the signs that a passwordless approach is still vulnerable to phishing?

A passwordless approach is still weak when it depends on SMS codes, emailed magic links, or mobile app approvals that can be tricked out of users. If the method can be captured remotely and replayed, it is still phishable. Stronger signals include reliance on open standards, device-bound authentication, and hardware-backed second factors that resist remote interception.

Why Passwordless Can Still Be Phishable

Passwordless only improves phishing resistance when the factor being approved is bound to the real destination, the real device, and the real session. If the user can be induced to relay an OTP, approve an unexpected prompt, or click a link that works anywhere, the attacker is still exploiting the user as the trust boundary rather than breaking authentication itself.

The warning signs are usually structural, not cosmetic. SMS codes, emailed magic links, and generic push approvals all remain vulnerable when they can be captured remotely and replayed; they reduce friction, but they do not stop credential forwarding, prompt fatigue, or man-in-the-middle capture. By contrast, device-bound and hardware-backed methods make remote interception materially harder because the response is tied to a specific origin, key, or authenticator state.

Phishing resistance is therefore about whether the verifier and the authenticator are mutually constrained. If the user can complete login from a different device, in a different browser, or after being redirected through an attacker-controlled page, the process still has a phishable trust gap. Open standards help only when they are implemented with the right binding and verification properties, not merely because the login is “modern.”

One useful indicator is whether the method still admits “approve what I just sent you” behaviour. If the answer is yes, the design still depends on user judgment under pressure, which is exactly what phishing exploits.

What Weak Passwordless Implementations Reveal in Practice

Weak implementations usually show up as convenience-first flows: one-time codes delivered over channels that can be intercepted, recovery paths that bypass the stronger factor, or approval prompts that do not show enough context for the user to detect a fraudulent request. Those patterns are especially risky when a single stolen response can be replayed to another site or session.

Another sign is that the control protects only the initial login, not the whole session. If a user can be tricked into approving a login from a hostile page, but the resulting session token can then be reused freely, the attacker has still achieved the practical objective of account access. In other words, the weakness may live in the handoff between authentication and session establishment rather than in the authenticator itself.

For a concrete example of how token theft and phishing can converge, see CoPhish OAuth Token Theft via Copilot Studio. Social engineering can also expose adjacent secrets and access paths, as shown in MailChimp Breach. Where login or recovery design is weak, credential exposure can spread quickly, which is why NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is useful for understanding how exposed access material broadens attack surface.

Risk and Threat Considerations

The main risk is false confidence: teams assume “passwordless” means phishing-resistant, then keep fallback paths, recovery channels, or approval prompts that attackers can still abuse. That creates a weaker but more dangerous posture because users and operators stop treating the flow as a target.

Failure mechanism: the attacker captures or coaxes the user into producing a reusable proof, then replays it against the real service, or uses a proxied flow to relay the authentication ceremony in real time. SMS, email links, and broad push approvals are the most common weak points because they are easy to forward, intercept, or confuse.

Impact: the attacker can take over accounts, establish a valid session, and pivot into downstream access, especially where recovery and session controls are weaker than the primary login. The issue is not merely “bad UX”; it is an authentication design that still allows remote coercion to become access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	AAL3 — Authenticator Assurance Level 3	AAL3 covers phishing-resistant, verifier-coupled authentication for high assurance.
	FAL2 — Federation Assurance Level 2	FAL2 addresses phishing-resistant federation by binding assertions to the authenticated browser session.
Recommendation — Use AAL3-style phishing-resistant authenticators for sensitive access and avoid replayable out-of-band approvals. Require phishing-resistant federation bindings so assertions cannot be replayed from a different origin or session.
OWASP Non-Human Identity Top 10	NHI-06 — Authentication and Secret Handling	Passwordless fallback channels and replayable proofs can still expose access material and enable misuse.
Recommendation — Eliminate replayable login paths and harden recovery channels that can be abused to steal valid access.
CIS Controls v8	6.3 — Secure and Manage Authentication Credentials	This control directly supports replacing weak, replayable authentication paths with stronger credential handling.
Recommendation — Replace phishable login factors with stronger authenticators and remove weak fallback mechanisms.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Passwordless phishing resistance depends on authentication strength and access-control design.
Recommendation — Assess whether authentication methods and recovery paths are actually resistant to interception and replay.

Practitioner Guidance

What to verify: confirm whether the method is truly phishing-resistant by testing if it binds the assertion to the origin, device, and transaction context. If a user can approve a login that was initiated elsewhere, or if the same proof works on a different device without re-binding, treat it as phishable.

Decision rule: if the control relies on SMS, email-delivered links, or generic approve/deny prompts, assume the phishing problem is reduced, not removed. Reserve the “phishing-resistant” label for flows where the authenticator cannot be cleanly relayed or replayed by an attacker.

What good looks like: the login ceremony is device-bound, hardware-backed where possible, and gives the user enough context to distinguish the real request from a prompted attack. The safest designs make the attacker’s preferred move, remote capture and replay, technically non-viable rather than merely inconvenient.

Practitioner takeaway: passwordless is only an improvement when it removes reusable, remotely transferable proof; if the user can still be tricked into handing over a usable login response, the environment is still phishing-exposed.