Passkey vs Password: Which Is Actually More Secure?

In short: Passkeys beat passwords on the two things that cause most account takeovers — phishing and credential reuse — because no shared secret is transmitted and the server doesn't need to protect what it stores, according to Apple's security documentation. Passwords remain easier to recover if you lose a device, which is why security teams still pair a password manager with two-factor authentication for services that don't yet support passkeys.

Passwords have run internet logins for decades, and they fail in the same two ways every time: people reuse them, and attackers trick people into typing them into fake sites. Passkeys were built specifically to close both holes. The question for an ordinary user isn't whether passkeys are newer — it's whether they're actually safer in the situations that matter, and what you give up by switching.

What's the difference between a passkey and a password?

A password is a secret you choose and type; a passkey is a pair of cryptographic keys generated by your device. Apple explains the mechanism plainly: "One of these keys is public, and is stored on the server. This public key is not a secret. The other key is private, and is what is needed to actually sign in. The server never learns what the private key is," according to Apple's passkey security page.

That split is the whole point. A password has to be sent to, and checked against, a server somewhere — which means it has to exist as a shared secret both sides know. A passkey's private half never leaves your device or your synced keychain. Microsoft's identity documentation frames it the same way for its own platform, describing passkeys as "FIDO2-based credentials that provide strong, phishing-resistant authentication," per Microsoft Entra ID's passkey guide. For the full mechanics of how the keys get created and matched to a site, see our explainer on how passkeys work.

Why can't passkeys be phished like passwords?

A password can be typed into any page that looks right, including a fake one. A passkey can't be copied, written down, or handed to someone else the way a password can, so there's no way for a victim to hand it over to a lookalike phishing site. Google's account help page puts it in plain terms: "Unlike passwords, passkeys can't be shared, copied, written down, or accidentally given to someone else. This makes them more secure against phishing," according to Google's passkey sign-in page.

Apple makes the same claim from the server side: "No shared secret is transmitted, and the server does not need to protect the public key. This makes passkeys very strong, easy to use credentials that are highly phishing-resistant," per Apple's support documentation. That's the core anti-phishing mechanic — not biometrics, not device possession, but the fact that there's no shared secret for a victim to type or hand over in the first place.

The scale of the problem passkeys target is large. The FIDO Alliance, citing the threat landscape behind NIST's updated guidance, notes that "87% of hacking-related breaches are caused by weak or stolen passwords and where there has been a 967% rise in credential phishing since 2022," according to FIDO Alliance's writeup of NIST's guidance update. FIDO's writeup describes NIST's supplemental guidance as moving to confirm that synced passkeys can satisfy Authentication Assurance Level 2 (AAL2), and adds that "synced passkeys can be AAL2 and device-bound passkeys can be AAL3" — the higher tier reserved for hardware-bound keys that never sync anywhere.

Breach exposure follows the same logic. If a company's server is hacked, a stolen password database can be cracked offline given enough time and weak hashing. A stolen passkey database is just public keys — mathematically useless without the matching private key that never left your device. That asymmetry is why a server breach that used to mean millions of exposed passwords means nothing to an attacker if the service only stored passkey public keys.

Credential stuffing — where attackers take a password leaked from one breached site and try it on dozens of others — depends entirely on password reuse. Passkeys are generated separately for every site, so there is no equivalent credential to stuff. A weak, guessable password can also simply be brute-forced; a passkey's private key is not something a human chooses or can guess, so brute-forcing it isn't a meaningful attack surface the same way.

What happens if I lose my device with a passkey?

This is where passkeys carry real risk that passwords don't. A forgotten password can usually be reset through an email link. A lost device holding your only passkey can lock you out unless you've set up recovery in advance.

Apple's system leans on iCloud Keychain, which syncs passkeys across devices and is "end-to-end encrypted with strong cryptographic keys not known to Apple and rate limited to help prevent brute-force attacks even from a privileged position on the cloud backend, and are recoverable even if the user loses all their devices," according to Apple's documentation. If you lose every device, recovery goes through "iCloud keychain escrow, which is also protected against brute-force attacks, even by Apple."

But that protection has teeth that cut both ways. Apple caps recovery attempts, stating on its support page: "iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts." Fail enough times and the escrow record is destroyed outright. Apple's own suggested safety net, per the same page, is that "a user can set up an account recovery contact to make sure that they always have access to their account, even if they forget their Apple Account password or device passcode" — a step most people never take until it's too late.

Google's model is similarly tied to your device ecosystem: biometric unlock data "stays on your device and is never shared with Google," per Google's help page, which limits what a Google-side breach could expose but also means losing the device matters more than losing a memorized password ever did. Microsoft's documentation distinguishes device-bound passkeys — where "the private key is created and stored on a single physical device and never leaves it" — from synced passkeys that sync an encrypted copy to the cloud, per Microsoft Entra ID's guide. Device-bound passkeys are more resistant to certain attacks but carry the sharpest lockout risk if that one device is lost or destroyed.

Do I still need passwords alongside passkeys?

For now, yes, almost everywhere. Google is explicit that adding a passkey "doesn't change or remove any authentication or recovery factors currently on your account" — your password keeps working as a fallback, per Google's passkey page. It adds: "By default, when you create a passkey, you opt in to a passkey-first, password-less sign-in experience. However, you still have the option to use your password to sign in to your account."

That coexistence is convenient, but it's also the root of a known weakness: a site that offers both a passkey and a password creates an opening for an attacker to steer a victim toward the phishable password entry screen instead of the passkey prompt, since the strong option isn't the only option. Phishing resistance only protects the login attempt that actually uses the passkey.

Cross-device support has improved but still depends on current software. Google lists minimum requirements including "a computer that runs at least Windows 10, macOS Ventura, ChromeOS 109, or up," per its support page. Microsoft's own compatibility table shows synced passkeys from Apple Passwords (iCloud Keychain), Google Password Manager, and third-party managers each need specific minimum OS versions — "Natively built in. macOS 13+" for Apple, for instance — according to Microsoft's Entra ID documentation. Older phones, laptops, or browsers simply can't participate yet, which keeps passwords in circulation as the common denominator.

Is a password manager plus 2FA as secure as a passkey?

Not quite, but it's still the right tool for a lot of real situations. Passkeys win decisively on phishing resistance and eliminate credential reuse entirely — a unique password manager entry still has to be typed or autofilled somewhere a phishing page can intercept it, and two-factor codes sent by text can be intercepted or socially engineered (our guide on why 2FA has limits too covers that gap).

But a password manager plus 2FA remains the practical choice whenever a service hasn't rolled out passkey support, when a workplace or regulation mandates a specific authentication method, or when you need a credential type that transfers easily across an old device that can't run a current OS. Microsoft itself instructs, on its Entra ID documentation: "Treat synced passkeys as phishing-resistant credentials but with the same security posture as other unattested authenticators" — meaning they're strong, but not a magic replacement for an organization's existing risk controls. FIDO Alliance's own summary of NIST's guidance acknowledges this nuance too: organizations with specific regulatory needs "can choose whether to accept a synced passkey as the primary authentication method, a second factor, pair it with a risk engine, or require a device-bound key," per FIDO Alliance. If a password does leak despite all this, our guide on what to do if your password was leaked walks through the cleanup.

The trade-offs, side by side

Factor	Passkey	Password (+ 2FA)
Phishing resistance	Domain-bound; can't be entered on a fake site, per Apple	Can be typed into any page, including phishing sites
Breach exposure	Server stores only a public key, useless alone	Server stores a hash that can be cracked offline
Credential stuffing	Unique per site by design	Reused passwords enable stuffing across sites
Device loss recovery	Can lock you out; Apple allows 10 authentication attempts before you must call Apple Support for more	Usually resettable via email or recovery contact
Cross-device sync	Works via iCloud Keychain, Google Password Manager, or Microsoft-compatible providers, but needs current OS versions	Works anywhere a password field exists
Current real-world support	Growing but partial; most sites still offer a password fallback	Universal

Passkeys are the stronger choice wherever a service supports them, because they remove phishing and reuse as attack paths rather than just mitigating them. The trade is recovery risk: losing every device tied to your passkeys is a harder problem to solve than forgetting a password, and the convenience of password-plus-2FA fallback is also what keeps the older, weaker path alive on most accounts today.