TL;DR: Phishing-resistant web authentication depends on cryptographic binding to the real origin or session, not on prompts or one-time codes that attackers can relay through adversary-in-the-middle phishing, according to Scramble ID and CISA guidance. The practical shift is from assuming MFA equals resistance to treating relay-proof ceremony design as the control boundary.
Editorial analysis by NHI Mgmt Group, based on content published by Scramble ID: “Phishing-Resistant Web Authentication: Passkeys, QR Login, and the Patterns That Actually Work”.
Key questions
A: Use WebAuthn with hardware backed authenticators and avoid relying on passwords as the primary control.
Q: Why do OTP and push approvals fail against adversary-in-the-middle attacks?
A: They fail because they prove user participation, not site authenticity.
Q: What are the signs that a phishing-resistant login design is failing?
A: If users can still complete high-risk login through email links, one-time codes, or an approval that lacks clear origin or session context, the design is not truly phishing-resistant.
Practitioner guidance
- Enforce origin-bound login for high-risk applications Require WebAuthn or another cryptographically bound method where the authenticator validates the relying party before releasing a proof, especially for privileged or sensitive web apps.
- Bind cross-device approvals to one browser session For QR-based authentication, require a signed, short-lived code that can only complete the login in the initiating browser session and expires after a single use.
- Remove weak fallback paths from step-up flows Disable OTP, email links, and other relayable fallbacks for applications where phishing resistance is a requirement, rather than leaving them as convenient escapes.
Bottom line: Phishing-resistant authentication is defined by cryptographic binding to the right origin or session, not by the mere presence of multi-factor checks.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
MFA is not the control boundary when the ceremony itself can be proxied. The relevant question is whether authentication proof is bound to the origin or merely relayed through a site that looks legitimate to the user. When the proof is transferable, phishing resistance does not exist, even if the login flow contains multiple factors. The practitioner conclusion is that ceremony design, not factor count, defines resistance.
A few things that frame the scale:
- The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.
A question worth separating out:
Q: What is the difference between origin binding and session binding in web authentication?
A: Origin binding ties the proof to the legitimate website or relying party, so a fake domain cannot replay it. Session binding ties the approval to the exact browser session that initiated the request, which is useful when the login or approval happens on a different device and still must not be relayable.
👉 Read our full editorial: Phishing-resistant web authentication and why MFA is not enough