Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: Cryptographic origin binding: How passkeys make phishing structurally impossible
Questions worth separating out
Q: How should security teams implement passkeys without weakening phishing resistance?
A: Start with strict domain governance, enforce server-side verification of origin and rpIdHash, and keep challenge validation mandatory.
Q: Why do passkeys reduce phishing risk more effectively than passwords or MFA?
A: Passkeys are cryptographically tied to a specific relying party and browser origin, so the credential cannot be copied to another site and reused.
Q: What breaks when passkeys are synced without strong account recovery controls?
A: The cryptography still works, but the security model shifts to the cloud account that syncs the credential set.
Practitioner guidance
- Audit domain boundaries before passkey rollout Confirm that each relying party ID matches your intended registrable domain structure and that subdomain strategy will not orphan credentials later.
- Treat recovery as an authentication control Use strong out-of-band verification for lost-device recovery and avoid email or SMS fallback paths that reintroduce phishing-susceptible channels.
- Validate server-side origin and challenge checks Verify that the application checks clientDataJSON origin, challenge freshness, and authenticatorData rpIdHash on every assertion.
What's in the full article
WorkOS's full article covers the protocol mechanics this post intentionally leaves at a higher level:
- Browser-by-browser origin and rpId validation flow for WebAuthn ceremonies
- Wire-level breakdown of clientDataJSON, authData, and signature verification
- Cross-domain credential handling through Related Origin Requests and deployment limits
- Implementation considerations for AuthKit passkey enablement and progressive enrolment
👉 Read WorkOS's analysis of cryptographic origin binding for passkeys →
Passkey origin binding: are your phishing controls keeping up?
Explore further
06/06/2026 4:18 am
Cryptographic origin binding breaks the old assumption that authentication secrets are portable. Passwords and many second factors assume a credential can move from one context to another and still remain valid. Passkeys reject that premise by binding the credential to a relying party and an observed origin, so the credential itself cannot be replayed elsewhere. The implication is that phishing resistance is no longer a user-behaviour problem alone, it is a protocol property that IAM teams must preserve through implementation discipline.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What is the difference between phishing resistance and secure rollout for passkeys?
A: Phishing resistance is a protocol property created by origin binding and signature verification. Secure rollout is the operational layer that keeps that property intact through domain planning, backup registration, attestation choices, and recovery policy. You can have a strong protocol and still weaken the programme through bad lifecycle design.
👉 Read our full editorial: Passkey origin binding shows why phishing stops at the protocol layer
