Topic starter
06/06/2026 2:34 am
TL;DR: Passkeys built on FIDO2/WebAuthn use cryptographic origin binding to make credentials domain-specific, so a passkey created for one site cannot authenticate to another. WorkOS explains that this breaks credential phishing and AiTM replay at the protocol layer, while still leaving recovery, sync, and deployment choices as governance decisions.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Cryptographic origin binding: How passkeys make phishing structurally impossible”.
Key questions
Q: What breaks when passkeys are used without proper domain binding?
A: Without domain binding, passkeys lose the property that makes them phishing resistant.
Q: When should organisations prioritise passkeys over legacy second-factor methods?
A: Organisations should prioritise passkeys when the main problem is user friction, phishing exposure, or the operational burden of issuing and replacing physical authenticators.
Q: How do teams know whether a passkey rollout is actually reducing phishing risk?
A: A rollout is working when sign-in success no longer depends on reusable secrets and when authentication failures are cleanly tied to domain, challenge, or origin mismatches.
Practitioner guidance
- Adopt passkeys for phishing-prone sign-in flows Prioritise employee, admin, and customer journeys where credential replay and lookalike login pages create the highest risk.
- Treat domain changes as credential lifecycle events If you move login traffic to a new custom domain, plan for passkey re-enrollment because credentials are bound to the original relying party ID.
- Design recovery without portable fallback secrets Use a second registered passkey or a strong out-of-band recovery process rather than email or SMS fallback.
Bottom line: Passkeys change phishing from a user-behaviour problem into a protocol enforcement problem by binding credentials to the original domain.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 10 hours ago by NHI Mgmt Group
06/06/2026 4:18 am
Passkey origin binding turns phishing resistance into a protocol property, not a user habit. Password-based controls assume the human can recognise the real login surface and resist a lookalike page. Origin binding removes that dependency by making the credential itself domain-specific, which is a different security model entirely. For IAM teams, that means the control boundary shifts from user judgment to ceremony integrity.
A few things that frame the scale:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
A question worth separating out:
Q: What is the difference between origin binding and traditional MFA?
A: Traditional MFA can still be relayed in real time if the attacker captures the second factor or session cookie. Origin binding changes the unit of trust: the passkey is cryptographically tied to the site that created it, so a phishing domain cannot reuse it on the real site. That is why the control is protocol-level, not just stronger authentication.
👉 Read our full editorial: Passkey origin binding shows why phishing stops at the protocol layer
This post was modified 10 hours ago by NHI Mgmt Group