Notifications
Clear all
Topic starter
22/06/2026 5:04 pm
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.
NHIMG editorial — based on content published by Scramble ID: Phishing-Resistant Web Authentication
Questions worth separating out
Q: How should security teams implement phishing-resistant authentication for workforce apps?
A: Start by making the primary login path origin-bound with WebAuthn or passkeys, then apply the same standard to step-up authentication for sensitive actions.
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 breaks when QR login is not session bound?
A: Without session binding, a QR becomes a transferable proof that can be scanned, forwarded, or replayed outside the initiating login context.
Practitioner guidance
- Classify each login path by relay resistance Map primary authentication, step-up, recovery, and shared-device flows separately.
- Require origin-bound authentication for high-risk access Use WebAuthn or passkeys for workforce access to sensitive applications, and enforce user verification where the action risk justifies it.
- Bind cross-device login to the initiating session If you use QR-based login, make the QR signed, short-lived, single-use, and tied to the browser session that initiated it.
What's in the full article
Scramble ID's full article covers the implementation detail this post intentionally leaves for the source:
- Exact WebAuthn and QR(DID) ceremony mechanics for same-device and cross-device login.
- The signed payload and session-binding structure used to keep QR approvals tied to the initiating browser.
- Deployment checklist details for retries, lockouts, expiry handling, and IdP integration through SAML or OIDC.
- Reference material on phishing-resistant MFA from CISA and WebAuthn from W3C.
👉 Read Scramble ID's guide to phishing-resistant web authentication and session binding →
Phishing-resistant web authentication: are your controls truly relay-proof?
Explore further
22/06/2026 5:19 pm
Phishing resistance is a ceremony property, not an MFA label. Many programmes still classify OTP, push, and password plus second factor as equivalent controls, but they are not equivalent under relay attack. The critical question is whether the proof is origin-bound or session-bound, because that is what stops adversary-in-the-middle abuse. Practitioners should stop treating MFA as a binary and start evaluating the authentication ceremony itself.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that remediation lag often outlives exposure windows.
A question worth separating out:
Q: Which authentication paths should keep the strongest phishing resistance requirements?
A: Keep the strongest requirements on admin access, financial approvals, sensitive customer data, and any workflow where token theft would create broad downstream impact. Those paths should use authenticators and ceremonies that resist relay, not just methods that are easy for users to approve.
👉 Read our full editorial: Phishing-resistant web authentication and why MFA is not enough
