Table of Contents
Phishing is the most successful attack method in cybersecurity. An estimated 3.4 billion phishing emails are sent every day, and even security-trained professionals occasionally fall for well-crafted attempts. Passkeys do not merely reduce the risk of phishing – they eliminate it at the protocol level. This is not marketing hyperbole. It is a structural property of the cryptographic design. This article, part of our passkeys and passwordless authentication resource, explains exactly how and why phishing cannot work against passkeys.
Why Passwords Are Inherently Phishable
To understand why passkeys resist phishing, you need to understand why passwords are vulnerable to it.
A password is a shared secret. You know it, and the website stores a version of it (a hash). When you log in, you type the password, and the website checks it. The critical weakness is in the middle of that process: you, the human, decide where to type the password.
A phishing attack exploits this by creating a convincing imitation of the real website at a different URL. If you cannot tell the difference between bank.com and bank-secure.com or bank.com.attacker.site, you type your password into the wrong place. The attacker captures it and uses it on the real site.
No amount of user training fully solves this. Phishing emails use urgency, authority, fear, and curiosity – psychological levers that override careful URL checking. Even researchers who study phishing have been caught by sophisticated campaigns. The fundamental problem is that password authentication relies on a human to verify the authenticity of the website, and humans are fallible.
How Passkeys Eliminate Phishing
Passkeys solve the phishing problem by removing the human from the verification loop. The device handles domain verification cryptographically, not the user visually.
Here is the mechanism, step by step:
Step 1: Passkey Creation Binds to a Domain
When you create a passkey for bank.com, the credential is cryptographically bound to that exact domain. The passkey’s metadata includes the “relying party ID” – in this case, bank.com. This binding is created during the registration process and cannot be changed after the fact.
Step 2: Authentication Challenge Includes Origin
When you visit a website and it requests passkey authentication, the browser includes the website’s actual origin (its domain) in the data sent to your device’s authenticator. This is not something the website can control or manipulate – it is determined by the browser based on the TLS certificate and the actual URL in the address bar.
Step 3: The Authenticator Checks the Domain
Your device’s authenticator (the Secure Enclave on Apple devices, TPM on Windows) receives the authentication challenge with the origin. Before responding, it checks: does this origin match the relying party ID that was registered when the passkey was created?
If you are on bank.com, the origin is bank.com, and the passkey for bank.com matches. Authentication proceeds.
If you are on bank-secure.com or bank.com.evil.site, the origin does not match bank.com. The authenticator has no matching passkey and does not respond. There is no prompt, no biometric check, no opportunity for the user to “approve” authentication to the wrong site.
Step 4: The Signature Is Origin-Bound
Even if an attacker somehow intercepted the authentication flow, the signed assertion includes the origin. The real bank.com server will reject an assertion that was signed for a different origin. The cryptographic signature is mathematically bound to the legitimate domain.
Why This Is Fundamentally Different from Passwords
With passwords, the security check is: “Does this look like the right website to me?”
With passkeys, the security check is: “Does the cryptographic origin match the registered domain?”
The first is a human judgment call that can be fooled. The second is a mathematical comparison that cannot.
This distinction is critical. Consider a phishing email that links to a perfect clone of your bank’s website. With a pixel-perfect copy at the wrong domain:
Password scenario: You might not notice the URL difference. You type your password. The attacker captures it. Attack succeeds.
Passkey scenario: You click the login button. Your device checks for a passkey matching this domain. It finds none (or finds that the domain does not match). Nothing happens. No passkey is offered. You cannot accidentally authenticate to the wrong site even if you wanted to.
The Technical Details
For those who want to understand the mechanism at a deeper level, here is how the anti-phishing protection works within the WebAuthn protocol:
Client Data JSON
During authentication, the browser constructs a clientDataJSON object that includes:
- type: “webauthn.get” (for authentication)
- challenge: The random challenge from the server
- origin: The actual origin of the requesting page (e.g., “https://bank.com”)
- crossOrigin: Whether the request came from a cross-origin iframe
This object is hashed and included in the data signed by the private key. The server verifies this hash as part of the authentication process. If the origin in the clientDataJSON does not match what the server expects, the authentication is rejected even if the signature is valid.
Authenticator Data
The authenticator also includes the RP ID (relying party ID) hash in the signed data. The RP ID is typically the domain name of the website. When the server verifies the assertion, it checks that the RP ID hash matches its own domain.
TLS Channel Binding
The WebAuthn specification recommends (and browsers implement) binding the authentication to the TLS channel. This means the assertion is tied to the specific HTTPS connection between the browser and the server. A man-in-the-middle who terminates the TLS connection and creates a new one to the real server would have a different channel, causing the verification to fail.
Real-World Scenarios
Let us walk through several phishing scenarios and how passkeys handle each:
Scenario 1: Classic Phishing Email
An attacker sends an email that says “Your bank account has been compromised. Click here to verify your identity.” The link goes to bank-verify.com, which looks identical to bank.com.
With passwords: You click the link, see the familiar login page, and enter your password. The attacker captures it.
With passkeys: You click the link and reach the fake site. The site cannot request a passkey challenge for bank.com because the browser will set the origin as bank-verify.com. No passkey matches. You see a standard login form with no passkey option, or an error. The attack fails.
Scenario 2: Homograph Attack
An attacker registers bаnk.com using a Cyrillic “a” character that looks identical to the Latin “a” in the browser’s address bar.
With passwords: The URL looks correct. You type your password. Attack succeeds.
With passkeys: The domain bаnk.com (Cyrillic a) is cryptographically different from bank.com (Latin a). The authenticator finds no matching passkey. Attack fails.
Scenario 3: Man-in-the-Middle Proxy
An attacker sets up a proxy that sits between you and the real website, intercepting all traffic. The proxy has a valid TLS certificate for its own domain.
With passwords: The proxy captures your password in transit (at the proxy, between decryption of your connection and re-encryption to the real server). Attack succeeds.
With passkeys: The browser includes the proxy’s domain (not the real site’s domain) in the clientDataJSON. The authenticator finds no matching passkey. Even if it did, the assertion would be signed for the proxy’s domain, and the real server would reject it. Attack fails.
Scenario 4: Real-Time Phishing Kit
An attacker uses a phishing kit that proxies requests to the real website in real-time, creating a seamless experience for the victim.
With passwords: This is one of the most effective phishing techniques. The user sees real content, types their password, and the attacker captures it before forwarding it to the real site. The user is logged in normally and may never realize they were phished.
With passkeys: The phishing kit’s domain does not match the real site’s domain. The WebAuthn origin check prevents any passkey from being offered or used. Even a sophisticated real-time proxy cannot bypass the domain binding. Attack fails.
Comparing to Other Anti-Phishing Measures
How does passkey phishing resistance compare to other anti-phishing approaches?
User Education
Training users to check URLs, look for HTTPS padlocks, and be suspicious of unexpected emails. Partially effective but fundamentally limited by human nature. Passkeys do not require user vigilance – the protection is automatic.
Email Filtering
Spam filters catch many phishing emails before they reach users. Effective at reducing volume but imperfect. Sophisticated, targeted phishing emails can bypass filters. Passkeys protect you even when phishing emails get through.
Browser Warnings
Browsers maintain lists of known phishing sites and display warnings. Useful but reactive – the site must be identified as malicious first. New phishing sites are not on the list immediately. Passkeys protect against both known and unknown phishing sites.
Hardware Security Keys
Hardware security keys (YubiKey, Google Titan) provide the same phishing resistance as passkeys because they use the same FIDO2 protocol with origin binding. The difference is convenience: passkeys are synced across devices and do not require carrying a physical key. For a comparison, see what are passkeys.
SMS or TOTP-Based MFA
Two-factor authentication using SMS codes or TOTP authenticator apps adds a second step but does not prevent phishing. An attacker with a real-time proxy can capture the MFA code along with the password and use both before they expire. Passkeys are strictly stronger than TOTP-based MFA against phishing.
Limitations to Be Aware Of
Passkey phishing resistance is genuine but bounded:
Only protects passkey-authenticated sessions. If a service supports both passkeys and passwords, and you use the password for a particular login (perhaps on a device without your passkeys), that login is still phishable. The phishing protection only applies when you actually use the passkey.
Does not protect against non-authentication phishing. If a phishing email asks you to wire money, provide your Social Security number, or take some other action that does not involve logging in, passkeys provide no protection. Passkeys protect authentication, not all forms of social engineering.
Account recovery may be phishable. If a service’s account recovery process involves email, phone, or security questions, those recovery channels may still be vulnerable to phishing or social engineering. See can passkeys be hacked? for a broader threat analysis.
Requires browser support. The origin verification depends on the browser correctly implementing the WebAuthn specification. All major browsers (Safari, Chrome, Firefox, Edge) do this correctly, but using an outdated or obscure browser could theoretically weaken the protection.
The Organizational Impact
For businesses evaluating authentication upgrades, the phishing resistance of passkeys has direct financial implications:
- Reduced breach risk: Phishing is the initial access vector in a large percentage of data breaches. Eliminating phishing risk for authentication significantly reduces overall breach exposure.
- Lower training costs: You can spend less on phishing awareness training (though some training remains valuable for non-authentication social engineering).
- Reduced helpdesk load: Fewer password resets from phishing-compromised accounts.
- Compliance benefits: Many regulatory frameworks reward or require phishing-resistant authentication methods.
The Bottom Line
Passkeys are not just “more secure” against phishing than passwords. They are immune to phishing by cryptographic design. The protection does not depend on user awareness, browser warnings, or email filtering. It is built into the mathematics of the protocol.
This single property – origin-bound, cryptographic domain verification – makes passkeys the most significant anti-phishing technology ever deployed at consumer scale. When 3.4 billion phishing emails are sent every day, a technology that makes phishing structurally impossible for authentication is not an incremental improvement. It is a paradigm shift.
If you are ready to start using passkeys, see our guides for setting up passkeys on Apple devices and which sites support passkeys in 2026.
