An estimated 7 billion passkeys are now in use worldwide, according to the FIDO Alliance’s report of October 15, 2026, up from the roughly 5 billion that both its May 2026 global report and Google’s own May 2026 report had counted. Google’s setup requirements add one practical detail worth knowing before you start: the device creating the passkey must already have a screen lock, a PIN, fingerprint, or face unlock, configured, or the process will not proceed (Google began requiring a screen lock to create Ads passkeys in March 2026). The FIDO survey, more than 11,000 consumers published in May 2026, put overall awareness of passkeys at 90%, with 75% of respondents saying they have enabled one on at least one account. The prompt to “skip password, use a passkey instead” now shows up on Google, Apple, Microsoft, GitHub, Amazon, and PayPal sign-in screens. If you have been dismissing that prompt because you were not sure what it actually does, this walkthrough fixes that in about 90 minutes.
This tutorial covers the full setup: checking device compatibility, enrolling passkeys on every major account type, storing them in a password manager, testing sign-in from a second device, and building a working WebAuthn demo if you write code for a living. Along the way we cover the mistakes that lock people out of their own accounts, ten troubleshooting scenarios pulled from real support docs, and what the security data actually says about whether passkeys hold up against phishing.
The primary keyword driving this guide, how to set up passkeys, gets roughly 1,000 monthly searches in the US alone, which tells you a lot of people are stuck at the exact same step you might be stuck on right now. Let’s get through it.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is a Passkey, and How Is It Different From a Password?
A passkey is a digital credential built on the WebAuthn standard and the FIDO2 protocol suite. Instead of a word or phrase you type and a server stores (or mis-stores), a passkey is a pair of cryptographic keys. The private key never leaves your device, your phone’s secure enclave, your laptop’s TPM chip, or a hardware security key. The public key sits on the website’s server, where it is useless to an attacker on its own.
When you sign in, the site sends a challenge. Your device signs that challenge with the private key and sends back the signature. The server checks it against the public key it already has. Nothing you type gets transmitted, because nothing gets typed. There is no password to phish, guess, or leak in a breach, and there is no six-digit code to intercept over SMS.
Passkeys are also bound to the origin domain that created them. A passkey generated for accounts.google.com will not work on a lookalike phishing page at accounts-google-secure.com, even if the fake page is pixel-perfect. That origin check happens inside the browser and operating system, not in something a user can be tricked into ignoring.
Passkeys vs. Passwords vs. One-Time Codes
A password proves you know a secret. An authenticator app or SMS code adds a second factor, but both still depend on a shared secret or a code that can be relayed to an attacker in real time through a phishing proxy. A passkey proves you possess a specific device and, usually, that you unlocked it with a fingerprint, face scan, or PIN. That combination is why the FIDO Alliance and NIST’s digital identity guidelines (SP 800-63B) both classify WebAuthn-based authenticators as phishing-resistant, a tier above app-based one-time codes.
Why Switch to Passkeys Now? The Security Case in Numbers
Password-related failures remain one of the most consistent themes in breach research. Our own coverage of the 2026 Verizon Data Breach Investigations Report found that exploited vulnerabilities have overtaken stolen credentials as the top breach vector at 31%, but credential abuse is still close behind, and the record-setting 24-billion-credential dump reported earlier this year shows how much reused, phishable password data is already circulating.
The FIDO Alliance’s own consumer research puts a number on the everyday cost of passwords: 48% of people say they have abandoned an online purchase because they forgot a password, and 36% say they have had at least one account compromised because of a password. Those are not enterprise statistics. They describe ordinary checkout flows and ordinary email accounts.
Adoption has moved fast in the other direction. FIDO’s own World Passkey Day research already had consumer awareness at 74% back in May 2025, and by that October, the FIDO Passkey Index, built from deployment data at Amazon, Google, Microsoft, PayPal, Target, TikTok, and several other member companies, found that 93% of accounts were already eligible for a passkey, 36% had at least one enrolled, and 26% of all sign-ins used a passkey instead of a password. Momentum has only continued since: 49% of people now say they use a passkey whenever the option is available, and the FIDO Alliance’s May 2026 country-level data shows just how far ahead some markets have pulled, with 65% of Singapore residents reporting they had enabled a passkey and 38% using one on a regular basis, well above the global averages.
On the enterprise side, the FIDO Alliance’s May 2026 global report, based on more than 11,000 respondents, puts the number at 68% of organizations now deploying, piloting, or actively rolling out passkeys for employee sign-in, a figure that sits alongside the 87% of US and UK firms that told a narrower February 2025 FIDO Alliance enterprise survey they had already deployed passkeys in some form. That same May 2026 report found 30% of organizations have gone a step further and made passkeys their primary authentication method rather than just one option among several. The top reason cited, at 39%, is protection against phishing and MFA fatigue attacks, the kind where an attacker floods a user with push notifications until one gets approved by accident. That single statistic is probably the best argument for why security teams stopped treating passkeys as optional in 2026.
What the Passkey Index Says About Everyday Sign-Ins
The October 15, 2026 edition of the Passkey Index describes passkeys as having moved from “deployment to adoption”, a shift from measuring broad availability to measuring routine usage. It draws on 15 consumer services, compared with nine in the prior year: Abanca, Amazon, Banesco, JPMorgan Chase, CVS, Google, KDDI, LY Corporation, Mercari, Microsoft, NTT DOCOMO, PayPal, Shopify, TikTok, and WhatsApp.
The performance figures show why that matters to an individual user. Passkey sign-ins had a reported 93% success rate, versus 78% for traditional MFA, and were reported as nearly three times faster than sign-ins without passkeys, saving an average of 27 seconds per sign-in. Whether the setup time in this guide is worth it comes down to those everyday sign-ins, where the gain repeats on every login rather than only after a breach.
The security and cost findings point the same way. Every participating service that measured phishing reported fewer successful attacks after deploying passkeys, and every participant providing savings data reported lower SMS one-time-password costs. That is a practical reason to follow Step 12 and retire SMS-based fallbacks once your passkeys work from two devices. FIDO also said the Passkey Rubric would be introduced at Authenticate 2026 and described it as soon to be available on Passkey Central, so treat it as forthcoming rather than released, and check there before you build a rollout scorecard of your own.
How Passkeys Fit Into Zero Trust and Enterprise Identity Security
Passkeys did not appear in isolation. They are the practical, ship-it version of a broader shift security teams have been building toward for years: verifying identity continuously and cryptographically instead of trusting a network perimeter or a memorized secret. That shift shows up across our wider cybersecurity coverage as Zero Trust architecture, and passkeys are usually the first concrete control an organization deploys under that model, because they replace the weakest link, the password, without asking every employee to carry a new physical token.
NIST’s SP 800-63B guidance ties directly into this. The standard defines authenticator assurance levels, and a properly implemented WebAuthn credential can satisfy AAL2 or, with device-bound hardware, AAL3, the tiers federal agencies and regulated industries are increasingly required to hit. A password paired with an SMS code typically cannot clear the same bar, since SMS itself is not considered a phishing-resistant channel.
That regulatory pressure is part of why 68% of organizations now report deploying, piloting, or rolling out passkeys for employees rather than treating the feature as consumer-only, a trend corroborated by identity vendor Descope, which found in its own May 2026 research that 45% of organizations had deployed passkeys in at least one application. IT and security teams get a second benefit beyond compliance: passkeys collapse help-desk password-reset tickets, historically one of the highest-volume, lowest-value tasks a support team handles. When the credential cannot be forgotten the way a string of characters can, most of those reset requests simply stop coming in.
The rollout is rarely instant. Most security teams stage it in phases, starting with IT and engineering accounts, where phishing resistance matters most and technical staff can troubleshoot their own enrollment, then expanding to the broader workforce once the support playbook is proven. Step 6 above, which walks through the Microsoft Entra admin flow, is usually the first concrete task on that rollout plan for organizations standardized on Microsoft identity.
Track adoption the same way FIDO Alliance member companies do: the percentage of eligible accounts with a passkey enrolled, the percentage of sign-ins actually using one, and the average time it takes a new hire to enroll. Those three numbers tell you whether a rollout is working far better than a simple “is the feature turned on” checkbox, and they mirror the exact metrics behind the 93% eligibility, 36% enrollment, and 26% sign-in figures cited earlier in this guide.
Prerequisites: Devices, Accounts, and Software Versions You Need
You do not need new hardware for most of this tutorial. Passkeys work on phones, laptops, and desktops that are only a few years old. What matters is your OS and browser version, since older WebAuthn implementations were incomplete. The table below reflects the practical baseline most vendors converged on for reliable passkey creation and sign-in as of 2026, and it matches Google’s own setup guide, last updated in October 2026, which lists Android 9 or later, iOS 16 or later, and Windows 10 or later as the minimum versions it supports for passkeys, gathered from current platform compatibility guidance rather than a single source, so treat it as a floor rather than an exact cutoff.
| Platform | Minimum version for reliable passkeys | Notes |
|---|---|---|
| iOS / iPadOS | 16 or later | Older versions support security keys but not full synced passkeys |
| macOS | 13 (Ventura) or later | Needed for iCloud Keychain passkey sync in Safari and Chrome |
| Android | 9 or later | Google Play Services must also be current |
| Windows 10 | Version 1903 or later | Browser-based sign-in only, no native Windows Hello passkey creation |
| Windows 11 | 22H2 or later recommended | Required for native Microsoft Authenticator passkey flows |
| Chrome / Edge | 108 or later | Chromium browsers track closely together |
| Safari | 16.1 or later on macOS, 16.0+ on iOS | All iOS browsers use WebKit, so behavior mirrors Safari |
| Firefox | 122 or later | Platform authenticator support, not just security keys |
You will also want at least two devices signed into the same Apple ID, Google Account, or Microsoft account before you start, so you can confirm a passkey actually syncs rather than just assuming it did. If you plan to work through the developer section later in this guide, install Node.js 20 or a newer LTS release, plus a code editor and a terminal. WebAuthn requires either HTTPS or localhost, so a plain HTTP test server will not work for the coding project.
How Passkey Storage and Sync Actually Works
There are two flavors of passkey, and mixing them up is the source of most setup confusion. A device-bound passkey lives only on the hardware that created it, typically a physical security key or a device with no cloud sync enabled. A synced passkey is encrypted and copied across every device signed into the same account, through iCloud Keychain, Google Password Manager, or a third-party vault. Microsoft’s own documentation for enterprise administrators draws this line explicitly: “Choose the type of authenticator you want to use: Device-bound passkey or Synced passkey,” according to Microsoft’s Entra identity documentation.
For most people, synced passkeys are the right default, because losing one phone should not mean losing access to every account. The tradeoff is that synced passkeys depend on your cloud account staying secure and your OS vendor’s sync infrastructure staying reliable. Device-bound passkeys, usually stored on a hardware key like a YubiKey, trade convenience for a credential that genuinely cannot be extracted or copied, which is why our YubiKey setup guide is worth pairing with this one if you manage high-value accounts.
Where a passkey gets stored depends on which “passkey provider” is set as default in your OS or browser at the moment you create it. On an iPhone, that is usually iCloud Keychain. On a Windows PC signed into a Google-managed Chrome profile, it might default to Google Password Manager instead of Windows Hello. On Android, Google’s own developer documentation, updated in October 2026, notes that full platform-level support for third-party passkey providers only arrives on Android 14 or later, so phones running older Android releases generally default to Google Password Manager regardless of which manager app you would rather use. If you use 1Password, Bitwarden, or Dashlane, all three now support storing and syncing passkeys directly in the vault, which is often the cleanest option if you already split your accounts across Apple and Google devices. 1Password pushed that further in August 2026 with a beta browser extension that can create, save, and sign in with passkeys entirely on its own, without routing through the OS-level passkey provider at all. Dashlane’s own October 2025 figures show how quickly that habit is spreading: the manager logged 1.3 million passkey authentications a month, more than double its 2024 volume, and 40% of its users now keep at least one passkey in their vault, roughly double the share who did a year earlier.
Step 1-2: Confirm Compatibility and Choose Where Your Passkeys Live
Step 1 is simply checking your OS and browser against the table above. Go to Settings on your phone and computer, confirm the version, and update anything that falls short before continuing. Skipping this step is the single most common reason people report “passkey option doesn’t appear.”
Step 2 is a five-minute decision that saves a lot of cleanup later: pick your primary passkey provider now. If your household or team is mostly on Apple hardware, let iCloud Keychain be the default and treat Google Password Manager as a backup. If you are split across Android, Windows, and iPhone, a cross-platform manager like 1Password or Bitwarden avoids the sync gaps between ecosystems entirely. Set that default in your browser’s settings before you create your first passkey, because changing providers after the fact means re-enrolling everything.
Step 3: Create Your First Passkey on Your Google Account
Google was one of the earliest major platforms to let consumers create a passkey directly in account settings, and it remains the simplest starting point.
- Go to your Google Account passkey settings and sign in normally one last time.
- Select “Create a passkey” and confirm when prompted.
- Your device will ask for a fingerprint, face scan, or screen-lock PIN. This step is what binds the passkey to you, not just to the device.
- Repeat on a second device, or confirm the same passkey now appears there automatically if Google Password Manager sync is on.
Google will keep your password active in the background unless you remove it separately, which is intentional and worth leaving alone until you complete Step 12 later in this guide.
Step 4-5: Set Up Passkeys for Apple ID on iPhone, iPad, and Mac
Step 4: On iPhone or iPad
Open Settings, tap your name at the top, then Sign-In & Security, then Passkeys. If you do not see this option, your iOS version is below the 16.0 threshold from the compatibility table. Follow Apple’s official passkeys guide to finish enrollment, which mainly involves confirming Face ID or Touch ID. According to Apple’s current documentation, the passkey is stored in the Passwords app and syncs through iCloud Keychain, so it becomes available on every Apple device signed into the same Apple ID within a few minutes, and Google’s own setup guide, updated in October 2026, echoes the same requirement for anyone creating a Google passkey on an Apple device: iCloud Keychain has to be switched on first, or the passkey will not sync at all.
Step 5: On Mac
On macOS 13 or later, open System Settings, then your Apple ID, then Password & Security, and confirm iCloud Keychain is switched on. From there, passkeys created on your iPhone simply appear in Safari’s autofill when you visit a site that supports them. You can also create new ones directly from Safari the first time a site offers the option.
Step 6: Turn On Passkeys for Your Microsoft Account and Windows Hello
For a personal Microsoft account, Microsoft’s own security guidance frames the flow simply: “Set your credentials to use passwordless sign-in, then create a passkey.” In practice, that means going to your Microsoft account security settings, choosing “Add a new way to sign in,” and selecting the passkey option, which will trigger Windows Hello, a phone camera scan, or a security key depending on what is available.
Work and school accounts are a different flow, run through Microsoft Entra rather than the consumer account portal, and this is where IT teams control whether the option even appears. Microsoft moved passkeys out of preview for this audience in late May 2026, when Entra External ID passkey support reached general availability alongside general availability for device-bound passkeys on Windows itself, so organizations no longer need to run pilot-only configurations to offer either option. Since June 2026, Entra has required Authenticator passkeys to run on iOS 17 or Android 14+, and in September 2026 it made passkeys its default authentication method. If you are the administrator rolling this out for a team rather than yourself, Microsoft’s Entra documentation lays out the sequence: “To enable passkeys for your organization, complete these steps in order: 1. Enable passkey profiles, Opt in to passkey profiles in the Microsoft Entra admin center.” After that, an admin has to explicitly turn on self-service enrollment, described in the same documentation as setting “Allow self-service set up to Yes” on the Configure tab, then choosing “Passkey (FIDO2)” as an allowed authentication method. Skip any one of those three steps and employees will not see a passkey option at all, which is the single most common reason a corporate rollout stalls before it starts.
Step 7-8: Add Passkeys to GitHub, Amazon, and Other Everyday Accounts
Step 7: GitHub
For developers, GitHub is often the highest-value account to protect, since a compromised GitHub session can lead straight to source code, CI/CD secrets, and package registries. Go to Settings, then Password and Authentication, then “Add a passkey,” and follow the GitHub passkey documentation. GitHub supports registering multiple passkeys per account, so add both a synced passkey for daily use and a hardware security key as a backup if you administer any organizations.
Step 8: Amazon, PayPal, and similar accounts
Amazon and PayPal both added consumer passkey support during the 2023-2024 rollout wave, and the flow on each is nearly identical: open account security settings, look for “passkey” or “passwordless sign-in,” and confirm with your device’s biometric prompt. That same push has since reached deeper into business software: Oracle’s NetSuite 2026.2 release, dated July 2026, opened up passkey-based passwordless login to 100% of NetSuite users, a sign that passkeys are no longer just a consumer or big-tech feature but are showing up in the back-office ERP systems companies run finance and operations on. Financial accounts are exactly where passkeys earn their keep, since these are the accounts phishing kits target hardest, and a phishing page simply cannot request a valid signature for a domain it does not own.
Step 9: Store and Sync Passkeys With a Password Manager
If you would rather not depend on Apple or Google’s sync ecosystem alone, a dedicated password manager can hold your passkeys instead. This is also the more practical route for teams, since manager-based vaults are usually easier to audit and revoke centrally than personal iCloud or Google accounts, and the price of doing so has come down: our own Tech Insider pricing survey in June 2026 found passkey implementation running anywhere from $0 to $16 per user per month depending on the provider and tier, so even budget-constrained teams have a workable entry point.
| Platform / manager | Passkey creation available | Rough rollout window | Primary storage |
|---|---|---|---|
| Google Account | Yes | Since 2023 | Google Password Manager |
| Apple ID | Yes | Since 2022 | iCloud Keychain |
| Microsoft Account | Yes | Since 2022-2023 | Windows Hello / Microsoft Authenticator |
| GitHub | Yes | Since 2023 | OS/browser platform authenticator or security key |
| Amazon | Yes | Since 2023 | OS/browser platform authenticator |
| PayPal | Yes | Since 2023-2024 | OS/browser platform authenticator |
| 1Password | Yes (vault storage) | Mature support in 2025-2026 | Cross-platform 1Password vault |
| Bitwarden | Yes (vault storage) | Mature support in 2025-2026 | Cross-platform Bitwarden vault |
| Dashlane | Yes (vault storage) | Mature support in 2025-2026 | Cross-platform Dashlane vault |
To switch your default provider, open your browser’s settings, find the “passkeys” or “autofill” section, and change the save location before your next enrollment. If you already self-host a vault with Vaultwarden, check its current release notes for WebAuthn credential support, since self-hosted implementations vary in how completely they support passkey storage compared to the hosted commercial managers.
Step 10: Sign In With a Passkey End to End
Do not assume enrollment worked. Sign all the way out and test it, ideally from a second device you have not touched yet during setup. The flow should look roughly like this on a typical account:
1. Visit the sign-in page and enter only your username or email
2. Browser prompt: "Sign in with a passkey?"
3. Choose device: "This device" or "Use a phone or tablet"
4. If using another device: scan the QR code shown on screen
5. Approve on your phone with Face ID, Touch ID, or fingerprint
6. Session opens - no password field ever appearedIf you selected “use a phone or tablet,” your computer and phone communicate over a local Bluetooth handshake as a proximity check, even though the actual credential never leaves the phone. Google’s own cross-device sign-in instructions, updated in October 2026, state plainly that Bluetooth has to be turned on for this handshake to complete, which is why cross-device sign-in fails when Bluetooth is off, a detail we come back to in the troubleshooting section below.
Step 11-12: Set Up Backup Recovery and Retire Old Passwords
Step 11 matters more than it sounds like it should: generate and print or securely store account recovery codes before you rely on passkeys exclusively. With the FIDO Alliance estimating 7 billion passkeys in use worldwide in its October 15, 2026 report, backup and recovery planning has become one of the industry’s biggest focus areas, precisely because losing your only enrolled device is the most common way people get locked out at this scale. Every major platform in the table above offers a backup method, whether that is recovery codes, a secondary email, or a registered phone number. Do this before, not after, you remove your password, since recovery flows are usually harder to trigger once passwordless sign-in is your only path in.
Step 12 is the cleanup step, and it is optional but recommended once you have confirmed a passkey works from at least two devices. Go back into each account’s security settings and either delete the password outright, where the platform allows it, or at minimum turn off SMS-based two-factor authentication, which is the weakest fallback still commonly left enabled. Leaving an easily phished fallback path active defeats much of the point of switching, a gap security teams call a “downgrade attack” surface.
Step 13: Build Your Own Passkey Flow, a Working WebAuthn Project
If you build software rather than just use it, the fastest way to understand passkeys is to implement one. Below is a minimal but complete registration-and-login flow using SimpleWebAuthn, an open source library that wraps the WebAuthn API on both the server and browser sides. Use the latest published version of the library rather than pinning to a specific number, since the WebAuthn spec and browser implementations both continue to evolve.
Project setup
mkdir passkey-demo && cd passkey-demo
npm init -y
npm install express @simplewebauthn/server @simplewebauthn/browser
mkdir publicRemember that WebAuthn refuses to run over plain HTTP except on localhost, so for local testing you can use http://localhost directly. For anything else, you need valid HTTPS, which usually means a reverse proxy or a tunnel like ngrok during development.
Server-side registration
// server.js - registration options
import express from "express";
import { generateRegistrationOptions, verifyRegistrationResponse } from "@simplewebauthn/server";
const app = express();
app.use(express.json());
app.use(express.static("public"));
const rpID = "localhost";
const rpName = "Passkey Demo";
const users = new Map(); // demo only - use a real database
app.post("/register/options", async (req, res) => {
const { username } = req.body;
const options = await generateRegistrationOptions({
rpName,
rpID,
userName: username,
attestationType: "none",
authenticatorSelection: {
residentKey: "required",
userVerification: "preferred",
},
});
users.set(username, { ...options, credentials: [] });
req.session = { challenge: options.challenge, username };
res.json(options);
});The residentKey: "required" setting is what makes this a true passkey rather than a plain security key credential, since it forces the authenticator to store enough information to let a user sign in with just a username, or even no username at all.
Client-side registration
// public/register.js
import { startRegistration } from "@simplewebauthn/browser";
async function registerPasskey(username) {
const optionsRes = await fetch("/register/options", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ username }),
});
const options = await optionsRes.json();
const registrationResponse = await startRegistration({ optionsJSON: options });
const verifyRes = await fetch("/register/verify", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ username, registrationResponse }),
});
const { verified } = await verifyRes.json();
console.log("Passkey registered:", verified);
}startRegistration is what actually triggers the browser’s native “create a passkey” prompt. Everything before it is just preparing the challenge the browser needs.
Verification and login
// server.js continued - verify + login
app.post("/register/verify", async (req, res) => {
const { username, registrationResponse } = req.body;
const user = users.get(username);
const verification = await verifyRegistrationResponse({
response: registrationResponse,
expectedChallenge: req.session.challenge,
expectedOrigin: "http://localhost:3000",
expectedRPID: rpID,
});
if (verification.verified) {
user.credentials.push(verification.registrationInfo.credential);
}
res.json({ verified: verification.verified });
});Notice that expectedOrigin and expectedRPID are both checked server-side, not just inside the browser. That server-side origin check is the actual mechanism that makes passkeys phishing-resistant. A cloned login page hosted on a different domain will produce a signature the server rejects immediately, before any session is ever created.
Example output
{
"verified": true,
"registrationInfo": {
"credentialID": "AXk9k3f...",
"credentialType": "public-key",
"attestationObject": "o2NmbXR...",
"credentialDeviceType": "multiDevice",
"credentialBackedUp": true
}
}The credentialDeviceType: "multiDevice" field is how your server can tell whether the credential it just received is a synced passkey or a device-bound one, which matters if you ever want to enforce a stricter policy for admin accounts.
Passkeys vs. Passwords vs. Authenticator Apps vs. Security Keys
Not every authentication method solves the same problem, and the right answer depends on what you are protecting. Here is how the four most common options actually compare, based on FIDO Alliance research and NIST’s phishing-resistance classification.
| Method | Phishing-resistant | Works without a smartphone | Consumer belief it’s “more secure” | Typical setup time |
|---|---|---|---|---|
| Password alone | No | Yes | Baseline | Instant |
| Password + SMS code | No | Yes | Higher than password alone | 2-3 minutes |
| Password + authenticator app | Partial | No | Higher than SMS | 3-5 minutes |
| Synced passkey | Yes | No | 53% say more secure (FIDO, 2025) | 1-2 minutes |
| Device-bound passkey / hardware key | Yes | Yes | Highest assurance tier | 3-5 minutes |
The practical takeaway is that synced passkeys cover the everyday case well, while a hardware key like a YubiKey remains the stronger choice for admin accounts, cryptocurrency exchanges, or anything where a stolen or cloned phone would otherwise be catastrophic. The 54% of FIDO’s survey respondents who called passkeys “more convenient” than passwords were mostly describing the synced experience, not the hardware-key one, which trades a little convenience for a credential that physically cannot leave the device.
Common Pitfalls When Setting Up Passkeys
Most passkey setup failures trace back to one of these six mistakes, gathered from the same troubleshooting patterns platform support teams see repeatedly.
- Deleting your password immediately. Removing every fallback before you have confirmed cross-device sign-in works is the fastest way to lock yourself out. Wait until Step 10 succeeds on a second device first.
- Assuming sync is on by default. A passkey created while signed out of iCloud or a Google account stays trapped on that single device. Check the account status before you enroll, not after something goes wrong.
- Confusing device-bound and synced passkeys. A device-bound passkey on a hardware key will never show up on your phone, by design. That is not a bug to troubleshoot.
- Never testing from a second device. A passkey that only works on the device that created it has not actually been verified. Treat Step 10 as mandatory, not optional.
- Mixing up passkeys with generic 2FA. Not every site that supports an authenticator app also supports WebAuthn passkeys. Check each account’s own settings page rather than assuming.
- Leaving legacy authentication paths open on enterprise accounts. Enabling passkeys without disabling older, weaker sign-in methods gives attackers a downgrade path straight around the new protection.
Troubleshooting: 10 Passkey Problems, Solved
| Symptom | Likely cause | Fix |
|---|---|---|
| Passkey option never appears at sign-in | OS or browser below the minimum version | Update using the version table in the prerequisites section |
| “Create a passkey” button is greyed out | Not signed into iCloud or Google at the OS level | Sign into the account in system settings, not just the browser |
| QR code scan for cross-device sign-in times out | Bluetooth disabled on the phone | Enable Bluetooth. The handshake is a proximity check |
| Passkey created on phone does not appear on laptop | Different account signed in, or sync toggle off | Confirm both devices use the same Apple ID or Google Account |
| “This passkey is no longer valid” after a device reset | Secure enclave holding the private key was wiped | Re-enroll a new passkey. The old one cannot be recovered |
| Can’t sign in on a borrowed or public computer | Expected behavior by design | Use the cross-device QR flow instead of typing anything |
| Passkey saved to the wrong manager | Default passkey provider was not set before enrollment | Change the default in browser settings, then re-create the passkey |
| Locked out after losing the only enrolled device | No backup method was configured | Use the account recovery flow from Step 11. Prevent this next time by enrolling two devices |
| Corporate account has no passkey option, personal account does | IT admin has not enabled the passkey authentication method | Confirm the Entra passkey profile and self-service policy are both turned on |
| Passkey sign-in fails only on a work VPN | Network or conditional access policy blocking the WebAuthn origin check | Ask IT to allowlist the identity provider domain for FIDO2 traffic |
Advanced Tips: Hardening Your Passkey Rollout
Once basic setup works, a few extra steps push your passkey rollout from “convenient” to genuinely hard to compromise.
- Pair a hardware key with your most sensitive accounts. A device-bound key gives you an authenticator that cannot be extracted even if your phone or laptop is fully compromised, which is a meaningfully different threat model than a synced passkey.
- Audit registered passkeys regularly. Google, Apple, and Microsoft all show a list of every device with a registered passkey under account security settings. Revoke anything tied to a phone or laptop you no longer own.
- For IT teams, require phishing-resistant methods for admin roles specifically. The UK National Cyber Security Centre’s password guidance recommends prioritizing your highest-risk accounts first rather than attempting an all-at-once rollout.
- Watch for the Credential Exchange Protocol. FIDO Alliance member companies have been working on a standard way to move passkeys between providers, for example from Apple’s ecosystem to a password manager, without re-enrolling every account. Support is still uneven across vendors, so do not build a migration plan that depends on it working everywhere yet.
- Validate attestation server-side if you build authentication yourself. The code project above uses
attestationType: "none"for simplicity, which is fine for most consumer apps, but regulated industries often need to verify the authenticator model itself, not just the signature.
Frequently Asked Questions
Are passkeys actually safer than passwords?
Yes, in the specific sense that matters most: they cannot be phished the way a typed password or a relayed one-time code can. The private key never leaves your device and a fake login page cannot extract a valid signature for a domain it does not control.
What happens if I lose my phone?
If your passkeys were synced through iCloud Keychain, Google Password Manager, or a manager like 1Password or Bitwarden, you sign into a new device with that same account and your passkeys reappear. If they were device-bound to that specific phone with no backup enrolled, you need the account recovery method you set up in Step 11.
Can I use passkeys without a smartphone?
Yes. A physical hardware security key, like a YubiKey, creates and stores device-bound passkeys with no phone involved at all. It is arguably the more secure route, just less convenient for everyday sign-ins.
Do passkeys replace two-factor authentication entirely?
Largely, yes. A passkey already combines something you have (the device) with something you are or know (biometric or PIN unlock), which is the same principle 2FA was trying to achieve with a separate password and code. Most platforms treat a passkey as satisfying MFA requirements on its own.
Can someone steal my passkey the way they’d steal a password?
Not remotely, which is the whole point. The private key is generated and stored inside hardware designed to prevent extraction. An attacker would need physical access to an unlocked, synced device or your cloud account credentials, a much narrower attack surface than a password sitting in a breached database.
What is the difference between a passkey and a security key like a YubiKey?
A YubiKey is hardware that can generate and hold a passkey. “Passkey” describes the credential itself, which can live on a phone, a laptop’s secure enclave, or a dedicated key. Our YubiKey setup guide covers the hardware side in more depth.
Do passkeys work across Windows, Mac, iPhone, and Android?
Within one ecosystem, sync just works. Across ecosystems, for example from an iPhone to a Windows laptop, you generally need a cross-platform password manager or the QR-code cross-device sign-in flow described in Step 10, since Apple and Google do not yet sync passkeys directly with each other.
Is a passkey the same thing as biometric login?
No, though they are easy to confuse. Face ID or a fingerprint scan is just the local step that unlocks your device and authorizes it to sign the WebAuthn challenge. Your biometric data never gets sent to the website. It stays on your device and only unlocks the private key stored there.
