“Passkey” is a marketing-friendly word for a particular kind of credential defined by WebAuthn/FIDO2 standards. In standards terms, most passkeys are WebAuthn/FIDO2 discoverable credentials (historically called “resident keys”) stored by a device authenticator—think Apple’s Secure Enclave or a PC’s TPM—and unlocked with local user verification such as a biometric scan or PIN. Ars Technica described this design as elegant, but also warned that elegance doesn’t automatically translate to usability at scale—especially when users lose devices and need to get back in.

A passkey matters because it changes what a “secret” looks like. Passwords are reusable strings. Anyone who sees the string can replay it. Passkeys use a private key that never leaves your device, combined with a protocol that proves you have that key without revealing it. No one can shoulder-surf your “secret.” Nothing meaningful appears in a text field.

MDN’s passkeys guidance emphasizes the reason security people like them: origin binding. WebAuthn credentials are tied to a specific site identity (the origin/RP ID). A look‑alike phishing domain can mimic the design of your bank, but it can’t convince your device to use the bank’s credential on the attacker’s domain.

That isn’t a small improvement. Origin binding directly targets the most common consumer attack pattern: trick the user into authenticating to the wrong place and reuse what they typed. With passkeys, there’s no reusable secret to harvest, and the wrong site can’t call the right credential.

People searching “can passkeys be phished” often mean two different things, and the distinction matters.

Generally, no—not in the classic “enter your password on a fake site” sense. The private key isn’t displayed, typed, or transmitted as a reusable secret. MDN points out that WebAuthn’s origin binding blocks a credential registered for one domain from being used on another. That alone eliminates the highest-volume credential-phishing playbook.

Yes, because accounts aren’t only protected by the primary login method. They’re protected by the weakest path that still leads to access, including:

- SMS or email one-time codes (OTPs)
- Recovery codes
- Account recovery workflows run through support or automated prompts
- Other alternate sign-in options that bypass passkeys

Ars Technica’s reporting puts the consumer reality bluntly: even when platforms market “passwordless,” most still maintain multiple fallbacks—SMS, email, device-based recovery, trusted contacts—because people lose phones and forget PINs. Those fallbacks become the attacker’s favorite entrance, precisely because the passkey itself is doing its job.

So the phrase “passkeys can still be phished” usually means something more specific: attackers can downgrade you. If they can’t get the passkey, they try to route you into a path that accepts something phishable—like a code you can be talked into reading aloud.

Passkey security collides with an unavoidable human problem: loss. People drop phones into oceans. Laptops get stolen. Biometrics fail after an injury. A login system that works only when everything goes right is not a system people can live with.

Platforms respond with recovery channels designed for availability. Common options include:

- A registered phone number
- A registered email
- Recovery codes printed or stored somewhere
- Trusted contacts or social recovery
- Support-driven account restoration

Those are not inherently reckless choices. They’re attempts to answer a brutal question: how do you prove you’re you when you’ve lost the very device that proves it?

Security guidance increasingly treats those channels as the primary risk. NIST’s Digital Identity Guidelines (SP 800-63B, 2024 draft update) treat PSTN/SMS out-of-band methods in a restricted way and explicitly call out risks including SIM change/number porting and malware that reads SMS secrets. Translation: SMS is not merely “less secure.” It has known, repeatable failure modes that attackers understand.

The FIDO Alliance, in a 2025 paper on the journey to preventing phishing, warns about social engineering that “downgrade[s] account security level.” The point isn’t theoretical. If an attacker can’t beat the strongest door, they look for a side entrance labeled “Forgot your phone?”

Downgrade is not a single exploit. It’s a strategy: persuade the user—or the platform—to stop using the phishing-resistant flow and switch to one that can be intercepted, replayed, or socially engineered.

A typical phishing script is almost boring in its simplicity. An attacker impersonates a service (“Your account has suspicious activity”). The victim clicks a link. The fake site prompts for a sign-in. When the victim expects a passkey prompt, the attacker steers them to “Try another way.”

The “another way” often means an OTP. The attacker can request a real OTP from the real service, then persuade the victim to share it. The passkey remains secure; the account session becomes compromised.

When platforms support recovery through phone numbers, an attacker has more options:

- Social engineering: persuade someone to disclose codes.
- SIM swap / number port-out: take control of the phone number.
- On-device malware: read inbound SMS codes (a risk NIST explicitly highlights).

The uncomfortable reality is that recovery paths are often designed to be forgiving. Forgiveness is good customer experience. It’s also a security liability. A process meant to save legitimate users from lockout can become a playbook for adversaries.

A fair assessment has to acknowledge why companies keep these paths. A system that locks out users when they lose devices creates enormous support cost and brand damage. Ars Technica’s critique lands here: passkeys are elegant, but the ecosystem still struggles with the messy edges—especially recovery—where usability requirements collide with security ideals.

Apple has been one of the loudest proponents of passkeys, and its consumer materials frame them as phishing-resistant. The cryptographic design deserves that confidence. The complication is what happens when you lose access to your Apple devices and need to recover the vault that holds your credentials.

Apple’s security documentation for Secure iCloud Keychain recovery describes a process that relies on “secondary authentication” and requires users to register a phone number. The recovery flow involves receiving an SMS and replying to it for recovery to proceed. Apple’s consumer passkey explainer also references SMS to a registered phone number as part of the recovery design.

No one should pretend that Apple is alone here. This is a common industry trade: recovery that a normal person can complete often involves channels a determined attacker can target. The key point is structural, not brand-specific:

- Passkeys live inside ecosystems (iCloud Keychain, password managers, device sync).
- Ecosystem recovery becomes, functionally, passkey recovery.
- If recovery leans on phone numbers, the system inherits SMS risks.

That doesn’t mean “don’t use passkeys.” It means the security story can’t stop at the passkey prompt. If an attacker can’t authenticate as you, they may try to recover as you.

The most useful documents in this debate aren’t the glossy product pages; they’re the materials that acknowledge how authentication works across an account’s entire lifespan.

MDN’s documentation underlines what WebAuthn gets right: origin binding and the elimination of reusable shared secrets. That’s the core phishing resistance users should demand.

The FIDO Alliance goes further by addressing what happens around the core: the “journey.” In its 2025 paper on preventing phishing, FIDO explicitly calls out the risk of attackers using social engineering to downgrade account security level. That language matters because it reframes the problem. The threat isn’t that passkeys are secretly weak. The threat is that many deployments treat passkeys as an add-on while leaving older, weaker methods active.

NIST’s guidance, meanwhile, gives the blunt rationale for skepticism about SMS-based recovery. NIST doesn’t need a dramatic headline to make the point; it simply enumerates the known risks: number porting, SIM changes, and malware reading SMS. Those are not edge cases. They’re recurring incidents in consumer account takeovers.

Put together, the message is consistent: phishing resistance must cover login, fallback, and recovery—the full set of paths that lead to account access.

Most people can’t redesign platform authentication. You can, however, make it harder for attackers to downgrade you—and you can recognize the moments when the danger is highest.

- Prefer passkey-only where available. If a service lets you remove passwords or disable SMS-based login, do it. Fewer fallbacks usually means fewer downgrade paths.
- Treat recovery codes like keys, not paperwork. Store them offline in a secure place. A recovery code is often a master key.
- Harden your phone number. If a critical account uses SMS recovery, assume your phone number is part of your security perimeter. NIST’s concerns—SIM swap/port-out and malware—are exactly why.
- Be suspicious of “Try another way” prompts. Attackers love pushing victims into alternate flows. If you expected a passkey prompt and got an OTP request, pause and verify the domain and the context.
- Reduce account sprawl. The more accounts tied to a single email/number, the more valuable that recovery channel becomes.

Companies love to advertise passkeys as an endpoint—“passwordless.” In practice, many deployments are “passwordless… unless.” Unless you’re on a new device. Unless your biometrics fail. Unless you’re traveling. Unless the risk engine flags your login.

Passkeys can’t deliver on their public promise if the weak paths remain widely enabled and easy to trigger. FIDO’s own warning about downgrade attacks should be read as an implementation critique: phishing resistance is not a feature you bolt onto one screen. It’s a property of the system’s entire set of authentication options.

A fair counterpoint deserves airtime: removing fallbacks can lock out legitimate users and create accessibility problems. The challenge is to design recovery that is both humane and hard to abuse—without quietly reintroducing the very phishable secrets passkeys were meant to retire.

Passkeys represent a rare thing in consumer security: an approach that meaningfully shifts advantage away from attackers. WebAuthn’s origin binding and device-held keys remove the most lucrative target in credential phishing: reusable secrets.

The fine print is that accounts are not defended by one mechanism. They’re defended by a collection of mechanisms, built over years, often kept for good reasons, and rarely evaluated as a single attack surface. Ars Technica’s reporting captures the tension: elegant cryptography meets messy human reality.

The next phase of “passwordless” won’t be won by better face scans or slicker prompts. It will be won in the unglamorous work of recovery: eliminating downgrade paths, making high-assurance recovery usable, and resisting the temptation to keep SMS as the universal skeleton key.

Passkeys don’t need hype. They need follow-through.