A phishing page can reproduce a login screen with near-perfect visual fidelity. It can copy logos, spacing, prompts, and even the sequence of an identity provider’s screens. With a password, visual imitation can be enough: the secret typed into the counterfeit page is still a valid secret at the real service.
WebAuthn changes that exchange by making site identity part of the cryptographic operation. An authenticator does not merely produce a reusable answer after a person approves a prompt. It signs data associated with the relying party and with a browser-mediated ceremony. A credential registered for one relying party is not a general credential that another site can present unchanged.
That property is central to the phishing resistance associated with FIDO2 security keys and passkeys. It does not make deceptive interfaces disappear, and it does not remove every route to account compromise. It narrows a particularly productive attack path: collecting an authentication secret on one origin and replaying it against another.
The browser carries security context into the ceremony
WebAuthn sits between web applications and authenticators. A relying party asks the browser to create a credential or obtain an assertion. The browser supplies context that application JavaScript cannot arbitrarily redefine, including the current origin. The authenticator receives a relying-party identifier as part of the operation and associates credentials with that identifier.
During registration, the authenticator creates a key pair for the relying party. The private key remains under authenticator control, subject to the authenticator’s storage and protection model. The relying party receives the public key and credential metadata needed to verify later assertions.
Authentication uses the private key without disclosing it. The relying party sends a fresh challenge, the browser constructs client data that includes the challenge and origin, and the authenticator signs over authenticator data together with a hash of that client data. The authenticator data includes a hash of the relying-party identifier.
The server therefore verifies more than possession of a private key. It checks a fresh challenge, expected origin, expected relying-party context, signature validity, and other ceremony details required by its policy. A valid assertion is tied to a specific authentication exchange rather than being a static bearer secret.
This division of responsibility matters. A web page controls its own application logic, but it does not get unrestricted authority to claim that it is another origin. Browser enforcement supplies a boundary that a counterfeit page on an unrelated domain cannot reproduce simply by copying HTML and CSS.
Relying-party scope blocks the obvious relay
Consider an attacker operating a convincing page at login-example.net while targeting an account at example.com. A password entered into the attacker’s page can be forwarded to example.com immediately. A one-time code can also be relayed while it remains valid. The attacker acts as an interactive intermediary rather than waiting to reuse the credential later.
A WebAuthn credential scoped to example.com behaves differently. The counterfeit origin cannot request an assertion as though it were the target site. The browser applies WebAuthn’s relying-party and origin rules, and the server validates the resulting ceremony against its expected values. An assertion produced in the wrong web context is not interchangeable with one produced for the legitimate service.
The relying-party identifier is related to domain scope rather than an arbitrary application string. Deployments can use an appropriate registrable-domain scope so that selected subdomains participate in the same relying-party boundary, subject to WebAuthn’s rules. That flexibility is useful for organizations with several login surfaces, but it also turns domain architecture into part of authentication design.
A service should not treat the relying-party identifier as cosmetic configuration. Moving authentication between domains, consolidating brands, or changing the domain hierarchy can affect which credentials remain usable. The security benefit comes from binding credentials to a namespace; operational teams inherit the need to manage that namespace carefully.
Phishing resistance is not session resistance
Strong origin binding can stop credential relay and still leave an account exposed through other channels. Authentication is one boundary in a longer session lifecycle.
If malware controls the endpoint after authentication, it may act through the user’s active session without extracting the WebAuthn private key. If an application has a cross-site scripting flaw, injected code executes within the legitimate origin and can abuse whatever authority the application exposes there. If a session cookie is stolen through another weakness, the attacker may not need to perform WebAuthn at all until the session expires or the service demands fresh authentication.
Account recovery can also undercut the primary mechanism. A service that protects normal sign-in with WebAuthn but permits recovery through a weak email-only path has created a second route to the same account. Attackers tend to follow the path with the lowest effective assurance, not the path highlighted on the login page.
Administrative support flows deserve the same scrutiny. Manual resets, help-desk overrides, device replacement, and identity proofing can become practical bypasses when their controls are weaker than routine authentication. Phishing-resistant sign-in raises the value of those alternate routes as targets.
The useful security claim is therefore precise: WebAuthn can provide strong resistance to phishing attacks that depend on obtaining or relaying authentication credentials across web origins. It is not a blanket guarantee against endpoint compromise, session theft, application vulnerabilities, recovery abuse, or malicious actions performed after a legitimate session is established.
Passkeys change custody without changing the core binding
Passkeys use WebAuthn credentials while allowing credential management models that can differ from traditional hardware security keys. Some credentials are device-bound. Others can be synchronized across a user’s devices through a platform ecosystem. Cross-device authentication can also allow a nearby device to participate in a sign-in ceremony.
Those models alter custody, recovery, and availability considerations, but they do not turn the credential into a password-like string. The relying-party binding and WebAuthn ceremony remain fundamental to the authentication proof.
Synchronization introduces a broader trust surface around the credential provider’s account security and device ecosystem. That can be a reasonable trade for consumer services, where loss recovery and multi-device availability strongly affect adoption. A hardware-backed, device-bound credential may suit environments that place a higher premium on controlled key custody and can support the operational burden of issuing and replacing authenticators.
The distinction should be made in policy rather than hidden behind the single word “passkey.” Organizations may care about authenticator properties, user verification, attestation, device management, or whether credentials are eligible for backup. WebAuthn exposes signals and options that can support policy, but deployment choices need to match the actual assurance target.
Attestation is a notable example. It can provide information about an authenticator at registration, depending on authenticator support, browser behavior, relying-party requests, and organizational policy. It is not required for the basic phishing-resistant property, and aggressive attestation requirements can create privacy, compatibility, and lifecycle costs. Consumer services often have different needs from tightly managed enterprise fleets.
User verification and user presence answer different questions
Authenticators can indicate that a person was present for an operation and, separately, that local user verification occurred. Touching a security key may establish user presence. A PIN, biometric check, or comparable authenticator mechanism can satisfy user verification when the authenticator and ceremony support it.
These signals are not interchangeable. Presence is useful against silent remote use of an authenticator, but a simple touch does not by itself establish which person touched it. User verification adds a local check intended to establish that the person operating the authenticator is authorized to use that credential.
A relying party decides what level it requires for a given operation. Routine access and a high-impact administrative action may justify different requirements. The server must enforce the result rather than assuming that any successful WebAuthn signature represents the same assurance level.
This becomes important when WebAuthn is used for more than initial login. Reauthentication before changing recovery factors, adding a new credential, exporting sensitive data, or altering payment details can reduce the value of an already-open session to an attacker. The authentication mechanism is strongest when the application places it at boundaries that correspond to actual risk.
Credential lifecycle becomes part of account security
Passwords are operationally simple in one narrow sense: a service stores a verifier and users can replace the secret. Public-key credentials distribute state differently. An account may accumulate credentials across phones, laptops, hardware keys, and replacement devices. Each credential needs an identity in the account model, along with enough metadata to support safe management.
A credential-management screen should make additions and removals auditable and understandable without exposing unnecessary technical detail. Registering a new authenticator is itself a security-sensitive event because it creates a durable new route into the account. Removing the final usable credential can create an availability problem that pushes users toward recovery.
Services also need a coherent policy for lost devices. Deleting a credential server-side prevents future assertions from that credential from being accepted, even if the private key still exists on the lost authenticator. Synchronized credentials complicate the human model because removing one device from an ecosystem is not necessarily the same event as revoking the relying party’s credential record.
Authentication logs gain additional value in this model. Recording credential identifiers in an appropriate privacy-preserving form, ceremony outcomes, factor-management events, and recovery actions can help distinguish normal device churn from suspicious account changes. Logs should support incident response without turning authentication metadata into an unnecessary tracking system.
Domain control becomes credential infrastructure
Origin binding moves part of the authentication boundary into domain governance. DNS changes, hosting transitions, subdomain delegation, reverse proxies, and identity-provider integrations can all affect the environment in which authentication ceremonies occur.
A forgotten subdomain or unsafe delegation is already a security concern, but strong authentication makes disciplined domain ownership even more consequential. An organization should know which origins are permitted to initiate authentication, which relying-party identifier is authoritative, and which systems are allowed to serve content inside that namespace.
Related-origin mechanisms can support some multi-domain deployments, but they should not be treated as a shortcut around deliberate domain design. Every additional accepted origin expands the set of web properties that participate in the authentication trust boundary.
The result is a useful shift in security architecture. With passwords, the central question is often whether a secret remains secret. With WebAuthn, the proof also carries context about where the ceremony occurred and which relying party the credential belongs to. That makes convincing imitation far less useful to an attacker, while placing new weight on browser guarantees, domain control, credential lifecycle, and the alternate account paths surrounding sign-in.