Passkeys Explained: Replace Your Passwords This Year

She clicked the link in what looked like a Google security alert. The page was convincing — Google’s font, Google’s colors, the familiar “Sign in to your Google Account” header. She typed her password. Then the site asked for her two-factor authentication code. She typed that too. The page spun, then redirected her to the real Google homepage as if nothing had happened.

Forty seconds later, her Google account was gone.

The attackers had her password and her 2FA code. They logged in immediately, changed the recovery email and phone number, and locked her out before she could react. Everything tied to that account — her Gmail, Google Drive, Google Photos, the YouTube channel she’d spent three years building — was gone in under a minute.

Here’s what makes this particular kind of attack so effective: it works perfectly even against people who know about phishing. The page looks real. The sense of urgency is real. The 2FA code she entered was valid and real. She did everything she thought she was supposed to do. The problem wasn’t her behavior. The problem was the technology. Passwords and one-time codes are both secrets that can be intercepted. If an attacker can get you to type them, anywhere, those secrets belong to the attacker.

Passkeys break that chain entirely. They don’t make the secret harder to steal. They eliminate the shared secret altogether.

The short answer: A passkey replaces your password with a cryptographic key pair. Your device keeps the private key and never lets it leave; the website stores only the matching public key. Logging in means your device signs a challenge, so no secret is ever typed or transmitted. That makes passkeys unphishable and useless to a breached server. You set them up through Google, Apple, or Microsoft in about two minutes, and you keep your password manager for the sites that don’t support passkeys yet.

Jump to:

What a passkey actually is

A passkey is a cryptographic key pair. Two mathematically related keys are generated: a private key and a public key. Your device — your phone, your laptop, your tablet — holds the private key and never lets it leave. The website holds the public key.

When you log in, the website sends your device a challenge: a random piece of data. Your device uses the private key to sign that challenge, producing a signature. The website verifies the signature using the public key. If the signature checks out, you’re in. No password was typed. No secret was transmitted over the network. The private key itself never moved.

This is called asymmetric cryptography, and it’s the same mathematical foundation used to secure HTTPS connections, cryptocurrency wallets, and secure shell (SSH) access to servers. It isn’t new technology. What’s new is that it’s been standardized and packaged in a way that works for ordinary login flows — on your phone, in your browser, across every major operating system.

The standard behind passkeys is called WebAuthn, part of the broader FIDO2 specification developed by the FIDO Alliance and ratified by the World Wide Web Consortium (W3C). The FIDO Alliance members include Google, Apple, Microsoft, Amazon, PayPal, Samsung, and hundreds of other companies. That coalition is why passkeys work across different ecosystems. The same passkey you create on an iPhone can authenticate you in Chrome on a Windows machine, via a QR code scan.

Why passkeys can’t be phished

This is the critical property, and it’s worth being precise about.

When you log in with a password, you type a string of characters. Those characters are the secret. It doesn’t matter where you type them — a real site, a fake site, a form in a PDF, a “customer support” chat window. Whatever receives that string now has your credential.

Passkeys don’t work this way. The private key never leaves your device, full stop. It is stored in a secure enclave — a hardware-isolated portion of your device’s chip that is separate from the main operating system. On an iPhone, that’s the Secure Enclave. On Android devices with a Titan chip, it’s the Titan security chip. On Windows Hello, it’s the Trusted Platform Module (TPM). The private key cannot be extracted, cannot be copied out, and cannot be sent anywhere.

More importantly: the private key is bound to a specific domain. When you create a passkey for google.com, the cryptographic binding includes the exact origin — the domain and protocol — of the site you registered with. When you try to use that passkey, your browser and device verify that the site requesting authentication matches the domain the passkey was created for.

This is what makes phishing impossible. The fake Google login page — the one that looked perfect, with the right fonts and the right logo — is hosted at a different domain. Maybe it’s g00gle-security-alert.com, or accounts.google.com.phishing-domain.net. The domain doesn’t match the one your passkey was issued for. Your device simply won’t produce a valid signature for it. There is nothing for the attacker to intercept, because nothing was transmitted.

The attacker can’t trick you into giving up your passkey the way they tricked that YouTube creator into giving up her password and 2FA code. The key never comes out of the device. The device won’t respond to the wrong domain. The attack has no surface to target.

Why they can’t be leaked in a breach

With passwords, a server breach is a catastrophe. The server stores something that represents your password — often a hash, sometimes (still) plaintext — and that stored value is what gets stolen. If an attacker steals hashed passwords, they can crack weaker ones offline, then use the recovered passwords elsewhere. If they steal plaintext passwords, the work is already done for them.

This is credential stuffing, and it has been running as an industrial-scale attack for years. The RockYou2024 combolist, compiled from thousands of historical breaches and published in 2024, contained nearly 10 billion credential pairs. That’s what attackers test against your Gmail, your bank, your Amazon account — automatically, at thousands of attempts per second, while they sleep. If you’ve reused a password anywhere, you’re in that pipeline.

With passkeys, the server stores only the public key. That’s it. Public keys are designed to be public. They’re mathematically useless without the corresponding private key, which only your device holds. If the server is breached and the attacker walks away with your public key, they have nothing. They cannot log in as you. They cannot derive your private key from the public key — that’s the core guarantee of asymmetric cryptography, and breaking it would require computing power that doesn’t exist on Earth.

A breach of a passkey-enabled service is fundamentally different from a breach of a password-enabled service. The attacker gets a list of public keys and usernames. That list cannot be used to log in anywhere. It cannot be used to attack other services. The credential stuffing attack that locked people out of millions of accounts across thousands of platforms becomes irrelevant the moment you switch.

Synced passkeys vs. device-bound passkeys

When you create a passkey on an iPhone, Apple syncs it across your other Apple devices via iCloud Keychain — encrypted end-to-end, with Apple holding no key. Create it on an Android phone, and Google Password Manager syncs it across your Android devices and Chrome. Create it on Windows with a Microsoft account, and it’s available across your Windows machines.

These are synced passkeys. They’re designed for usability: you get a new iPhone, your passkeys are already there when you sign in to iCloud. You lose your phone, your passkeys survive on your other devices.

Device-bound passkeys are different. They live only on one physical device — typically a hardware security key like a YubiKey — and cannot be exported or synced. They’re used in high-security environments where the additional binding to a physical object is worth the loss of convenience. If you lose the key, you lose the passkey. Most people don’t need device-bound passkeys. For most threat models, synced passkeys through Apple, Google, or Microsoft are the right choice.

The security difference between the two comes down to what you’re protecting against. Synced passkeys rely on your iCloud or Google account being secure — if someone takes over your Apple account, they can potentially access your synced passkeys. That’s a real consideration. But for the vast majority of people, the threat of phishing and credential stuffing is far more immediate than the threat of a sophisticated iCloud takeover. Synced passkeys eliminate the first category of threat entirely.

How widely are passkeys actually adopted?

More widely than most people realize, and the growth has accelerated sharply.

Google announced passkey support in May 2023 and reported over 1 billion passkey authentications across its services by late 2024. Apple shipped passkey support in iOS 16 and macOS Ventura, both released in September 2022. It was announced at WWDC 2022 alongside the cross-platform WebAuthn commitment made jointly with Google and Microsoft. Microsoft integrated passkeys into Windows Hello beginning in 2023 and added passkey support to Microsoft accounts in 2024. On World Passkey Day in May 2026, the FIDO Alliance estimated around 5 billion passkeys were in use worldwide. Its survey found roughly three-quarters of people had enabled a passkey on at least one account.

On the service side, the list of major platforms supporting passkey login now includes PayPal, Amazon, GitHub, Best Buy, Walmart, Instacart, Adobe, Coinbase, eBay, Kayak, LinkedIn, Nvidia, PlayStation Network, Shopify, Target, and Yahoo. The FIDO Alliance maintains a current directory at passkeys.directory. As of mid-2026, community trackers count roughly 300 services with passkey login, including about half of the top 100 websites, and the list keeps growing.

GitHub’s adoption is particularly significant. In 2023, GitHub required two-factor authentication for all code contributors. In 2024, they expanded passkey support and began encouraging users to upgrade from 2FA to passkeys. For developers — a group that is both high-value and frequently targeted — GitHub passkeys eliminate a major attack vector.

How to set up a passkey on Google

Setting up your first passkey takes about two minutes.

Go to myaccount.google.com and sign in.
Click Security in the left sidebar.
Scroll to How you sign in to Google and click Passkeys and security keys.
Click Create a passkey.
Follow the prompt on your device — on a phone, this will ask for Face ID, fingerprint, or your device PIN. On a Mac, it uses Touch ID or your Apple account password.
The passkey is created and synced. Done.

Next time you sign in to Google, you’ll be offered the option to use your passkey instead of your password. The sign-in takes one biometric confirmation, no password typed, no 2FA code to receive.

How to set up a passkey for your Apple ID

On your iPhone, open Settings and tap your name at the top.
Tap Sign-In & Security.
If your Apple ID is managed through Apple, you may see an option to use Apple’s own passkey system — on newer devices running iOS 17 or later, Apple ID itself is increasingly passkey-backed by default. Check here to confirm the status.
For iCloud Keychain specifically: passkeys you create on other supported sites (Google, GitHub, PayPal, etc.) are stored here automatically when you choose “Save to iCloud Keychain” during the passkey creation flow.
You can review all saved passkeys in Settings → Passwords — they appear alongside your saved passwords, labeled with a key icon.

When you get a new iPhone and sign in to iCloud, every passkey synced to iCloud Keychain restores automatically. You don’t need to re-register with each service.

What happens on Android with Google Password Manager

The flow on Android mirrors the Apple experience. When you create a passkey on a supported site using Chrome on Android, your device prompts you to save it to Google Password Manager. It syncs to any device where you’re signed in with the same Google account and using Chrome or Android’s built-in credential system.

You can review your passkeys at passwords.google.com — they’re listed separately from your saved passwords, with the passkey icon making them easy to identify.

For cross-device logins — say, signing in on your laptop using a passkey stored on your phone — the browser shows a QR code. You scan it with your phone’s camera. Your phone authenticates with biometrics, confirms the request, and your laptop session is approved. The private key still never leaves your phone. The QR code and Bluetooth proximity are used only to establish that the phone and laptop are physically close together, preventing remote attacks.

How to add a passkey on GitHub

Sign in to GitHub and go to Settings (click your profile photo, then Settings).
In the left sidebar, click Password and authentication.
Scroll to Passkeys and click Add a passkey.
Follow the device prompt — Touch ID, Face ID, Windows Hello, or your device PIN.
Give the passkey a name (optional but useful if you have multiple devices).
Click Save.

GitHub also allows passkeys as a 2FA method, so if you’re not ready to replace your password entirely, you can add a passkey as a second factor. The security improvement is still significant even in that configuration.

The remaining weaknesses

Passkeys are not a perfect, complete solution. Being clear about their limitations is important.

Account recovery is the hard problem. You might lose access to every device that holds your passkeys: the phone destroyed, the laptop stolen, the backup device lost. In that case, getting back into accounts requires fallback recovery mechanisms. Google, Apple, and Microsoft all have account recovery processes, but those processes typically rely on backup codes, trusted contacts, or support verification. They are the weakest link in a passkey setup. Store your backup codes somewhere safe: a printed copy in a secure location, or a password manager that you access from a device separate from your primary passkeys. This is the one place where old-school physical security still matters.

Your device account security still matters. Synced passkeys live in your iCloud or Google account. Someone could take over your Apple ID through a phishing attack on Apple itself, or a SIM swap against your recovery phone number. If they do, they gain access to your synced passkeys. This is a real threat vector, though it requires significantly more effort than credential stuffing or phishing for a single-service password. Securing the root account (your Apple ID or Google account) is a prerequisite for trusting passkey sync.

Not every site supports them yet. Your bank, your insurance company, your utility provider — many of these still live in password-world. Password managers remain essential for the accounts that haven’t made the switch. The good news is that FIDO Alliance membership continues to grow, and enterprise adoption is accelerating as companies recognize the liability reduction of eliminating phishable credentials.

Passkeys don’t protect you from a compromised device. Say an attacker has malware on your device with operating-system-level access. They can potentially intercept authentication requests at the point of use. They do this not by extracting the private key, but by approving requests made through the legitimate credential. Full device compromise is a separate threat model that passkeys don’t address.

What to do this week

Security decisions work best when they’re prioritized. Not everything is equally important. Here is the order that makes sense.

First: your primary email account. Email is the master key. Whoever controls your email can reset every other account linked to it. If you do nothing else, add a passkey to your Google, Apple, or Microsoft email account this week. The setup takes two minutes. The risk reduction is immediate and substantial.

Second: your bank and financial accounts. Check whether your bank supports passkeys. Most of the major US banks, including Bank of America, Wells Fargo, and Chase, have added passkey support or are rolling it out. PayPal has supported passkeys since 2023, and so has Coinbase. Add passkeys to every financial account that offers them. Passkeys are also the strongest defence against the account takeover fraud that empties bank accounts.

Third: your social media accounts. These are high-value targets both for personal embarrassment and for impersonation scams targeting your contacts. Apple ID, Google Account, LinkedIn, and others support passkeys or FIDO-based authentication. Enable them.

Fourth: everything else. Work through your password manager’s list of saved accounts. Most password managers now flag which sites support passkeys — 1Password, Bitwarden, and Dashlane all surface this information directly in the app. Set up passkeys wherever you see the option.

Keep your password manager. Passkeys don’t replace password managers yet; they complement them. For accounts that still require passwords, a password manager with unique, random passwords remains your best defense. Where a site offers no passkey, strong two-factor authentication is the next best thing. Think of passkeys as the upgrade path: every account you move to a passkey is one fewer password to worry about.

Set up account recovery. Before you rely on passkeys, generate and store backup codes for your primary accounts. Google, Apple, and Microsoft all offer backup codes specifically for account recovery. Print them or store them somewhere you can access independently of your primary device. Don’t skip this step.

The shift from passwords to passkeys is the most meaningful security improvement available to ordinary people right now. It doesn’t require technical expertise to set up. It doesn’t require you to remember anything. And it eliminates entire categories of attack that have been draining accounts for twenty years — phishing, credential stuffing, and brute force, all in one architectural change.

The YouTube creator who lost her channel to a fake login page? A passkey would have made that attack technically impossible. Not harder, impossible. Her device would have refused to authenticate to the wrong domain, silently, with no action required on her part.

That’s not a marginal improvement. That’s a different kind of security entirely.

Even with passkeys, credentials you set up years ago may already be circulating from old breaches. KnytX Vigil is built to watch breach databases for your exposed logins and flag them so you know which accounts to upgrade first. Vigil isn’t live yet; join the waitlist to turn it on at launch.