Passkey origin binding shows why phishing stops at the protocol layer

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Passkey origin binding ties authentication to a specific domain and blocks credential phishing at the protocol layer.

Why it matters: For IAM teams, it shows why passkeys change phishing from a user-behaviour problem into a protocol and governance problem that still leaves recovery and rollout choices to manage.

Context

Passwords are portable secrets, which is why phishing and adversary-in-the-middle attacks can reuse them across sites. Passkeys change that model by binding the credential to a relying party and browser origin, so authentication succeeds only for the domain that registered it.

For identity programmes, the important shift is that phishing resistance moves below the application layer. That makes passkeys a human IAM control with NHI-style protocol properties: the assurance comes from cryptographic binding, while recovery, sync, and domain design remain governance decisions.

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. A credential can then be replayed or mis-scoped across sites, which reopens the same portability problem that passwords and weak MFA already have. The key failure is not the key pair itself but the missing enforcement that ties it to one relying party and origin.

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. Passkeys are most valuable when the business needs stronger authentication without the deployability pain that comes with tokens or the password reset overhead that traditional login systems create.

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. Teams should also watch for fallback use, because email or SMS recovery can reintroduce phishing risk even if the primary ceremony is sound.

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.

Technical breakdown

How relying party ID binds a passkey to one domain

WebAuthn scopes each credential to a relying party ID, usually a registrable domain such as example.com. During registration, the authenticator stores the SHA-256 hash of that RP ID in authData as rpIdHash, and the browser captures the full origin in clientDataJSON. Both values are signed, so a phishing page cannot alter the domain after the ceremony begins. If the RP ID does not match the current origin, registration or authentication fails before the credential can be used.

Practical implication: align each production domain with a deliberate passkey registration boundary and treat domain changes as credential lifecycle events.

Why origin binding defeats phishing and adversary-in-the-middle attacks

A password can be replayed anywhere, but a passkey signature is only valid for the origin that was present when the ceremony ran. The browser writes that origin into clientDataJSON, the authenticator signs it together with authData, and the server verifies the signature, challenge, origin, and rpIdHash together. Adversary-in-the-middle kits can relay pages and cookies, but they cannot make a passkey issued for one domain sign for another without breaking verification.

Practical implication: prioritise passkeys for high-value sign-in paths where phishing and session relay are the main authentication threats.

What recovery and sync choices change in a passkey programme

Origin binding solves credential portability, not account recovery. If passkeys are synced through a cloud account, the security boundary expands to include that account and its recovery path. If a device is lost, the user may need a second registered passkey or a strong out-of-band recovery flow. The protocol stays phishing-resistant, but the programme can still reintroduce weak links through fallback methods such as email or SMS.

Practical implication: design recovery and backup registration so they do not undo the phishing resistance that passkeys provide.

Threat narrative

Attacker objective: The attacker wants a reusable sign-in artifact or session that can be replayed against the real service.

1. Entry occurs when an attacker presents a convincing replica domain or reverse-proxy login page to capture a credential.
2. Credential harvesting fails at the protocol layer because the passkey is scoped to the original relying party ID and browser origin.
3. Impact is prevented because the authenticator will not produce a valid assertion for a different domain, blocking replay and session theft.

Breaches seen in the wild

• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Cryptographic origin binding is the named concept that matters here. It is the combination of browser-captured origin, relying party ID, and signed authenticator data that makes cross-site reuse fail. This is more than stronger MFA. It breaks the portability assumption that phishing attacks rely on, and that assumption has shaped too many authentication programmes for too long.

Passkey adoption improves human authentication but does not eliminate governance risk. Recovery paths, cloud sync, and custom domain decisions can still create weaker fallback channels around an otherwise strong protocol. The identity programme problem therefore moves from preventing credential theft to preventing policy-driven reintroduction of portable secrets.

Passkeys also expose where identity governance and web security overlap. The authenticator enforces domain scope, but the enterprise still owns enrollment strategy, backup registration, and domain management. That makes passkeys a rare control where protocol design is doing the heavy lifting, while governance decisions determine whether the deployment preserves that assurance.

FIDO2/WebAuthn should be read as a structural correction to shared-secret identity. Shared secrets made identity portable, replayable, and phishable by design. Origin binding replaces that premise with cryptographic non-portability, so the real question for practitioners is whether their surrounding controls are aligned to the new assumption set.

From our research library:

• Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.

What this signals

Passkey origin binding is the cleanest example of a control that removes the phishing decision from the user and places it in the protocol. That matters because many identity programmes still rely on people spotting deception in time. With passkeys, the governance task shifts to preserving the ceremony boundary, the domain boundary, and the recovery boundary.

Recovery design becomes the weak point once the primary sign-in path is phishing-resistant. If a programme keeps email or SMS as a universal fallback, it preserves a portable secret path around the stronger control. Teams should treat recovery as part of the authentication architecture, not as a convenience layer.

Origin binding also shows why human IAM and protocol assurance are converging. The user still approves the sign-in, but the browser and authenticator now carry the security burden. That makes passkey governance a useful bridge topic for IAM, PAM, and identity architecture teams.

For practitioners

• 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. Use passkeys where you want the protocol to remove dependence on user recognition of the correct domain.
• 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. Build the change into migration runbooks instead of discovering it after users are locked out.
• 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. If recovery recreates a phishing-susceptible path, the programme has reintroduced the problem passkeys were meant to remove.
• Validate origin checks in every authentication flow Confirm that the browser origin, challenge, and rpIdHash are all verified server-side and that no custom login flow bypasses the standard WebAuthn ceremony. The control only works when every verification step remains intact.

Key takeaways

• Passkeys change phishing from a user-behaviour problem into a protocol enforcement problem by binding credentials to the original domain.
• The strongest part of the model is also its weakness: recovery, sync, and custom domain changes can reintroduce portability if they are not governed.
• For IAM teams, the practical test is whether the surrounding journey preserves origin binding or quietly restores the same reusable-secret risk passkeys were meant to remove.

Key terms

• Cryptographic Origin Binding: A control property that ties an authentication credential to a specific domain or origin so it cannot be reused elsewhere. In passkeys, the browser and authenticator both commit to the relying party and observed origin, which prevents straightforward credential replay and makes phishing ineffective against the signed credential itself.
• Relying Party: A relying party is the application or service that consumes an authentication assertion or token and grants access based on the identity proof it receives. In federation designs, its configuration quality directly affects whether trust decisions remain consistent and secure.
• Adversary-in-the-middle Attack: An adversary-in-the-middle attack intercepts and relays authentication in real time between the user and the legitimate service. It is especially dangerous for OTPs because the attacker can capture the code while it is still valid and immediately use it to complete login.
• Passkey Recovery Path: The backup process a user relies on when a passkey is lost, replaced, or inaccessible. From a governance perspective, the recovery path matters as much as the passkey itself, because a weak fallback such as email or SMS can reintroduce the very phishing exposure the passkey removed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.