Passkeys, Explained for Decision Makers

In the 2026 FIDO Passkey Index, passkey sign-ins succeeded 93% of the time. Passwords and traditional MFA, such as SMS codes and authenticator apps, succeeded 78% of the time. Passkeys were also 2.8 times faster, saving about 27 seconds per sign-in on average. (FIDO Passkey Index 2026)

Fifteen points of sign-in success is not a security statistic. It is a conversion statistic. Out of every 100 sign-ins, it is 15 more people who got where they were going.

Passkeys are the one change that improves security and experience at the same time. They are not a feature to add. They are the new default.

How a passkey works, in four sentences

When a user creates a passkey, their device generates a key pair. The private key stays on the device or in the user's password manager; your server stores only the public key. At sign-in, the device proves it holds the private key after the user unlocks it with a face, fingerprint, or PIN. The key is tied to your exact domain, so a lookalike phishing site cannot use it.

That last point is why passkeys are called phishing-resistant. There is no code to read out, no secret to type into a fake page, and nothing useful on your server for an attacker to steal.

For a decision maker, three consequences follow:

• A database breach does not leak sign-in secrets. Public keys are useless to an attacker without the matching private key.
• Credential stuffing stops working for passkey users. There is no shared secret to reuse across sites.
• The face or fingerprint never leaves the phone. Your brand never collects, stores, or processes biometric data. The device uses it locally to unlock the key.

That third point answers a question your legal team will ask, so put it in writing early.

Synced vs device-bound passkeys

There are two kinds of passkeys, and the difference matters for policy and compliance.

Type	Where it lives	NIST Rev 4 level	Best for
Synced passkey	Platform password manager (Apple, Google, Microsoft, or third-party), synced across the user's devices	Recognized as a single authenticator meeting AAL2 multi-factor assurance	Consumers and most workforce users
Device-bound passkey	One device or a hardware security key; private key cannot be exported	Required for AAL3	Admins, high-value accounts, regulated workflows

Sources: NIST SP 800-63B-4, Appendix B: Syncable Authenticators, Presencis on NIST 800-63-4, WWPass buyer's guide.

The NIST language is direct. Authentication at AAL2 (NIST's multi-factor assurance level) "may be supported" with synced passkeys, subject to conditions such as protecting the sync account itself with AAL2-level multi-factor sign-in. AAL3, the highest level, is off the table for synced keys, because "syncing violates the non-exportability requirements of AAL3." (NIST SP 800-63B-4, Appendix B)

For consumer brands, synced passkeys are the right default. One face scan replaces password plus SMS code and meets a higher assurance bar than either. Synced passkeys also follow the customer to a new phone, which removes the most common recovery scenario.

Device-bound passkeys belong where you need AAL3 or where policy forbids keys leaving a device: staff with admin rights, treasury functions, and some regulated workflows. If your workforce rollout raises that question, my post on when device-bound vs synced passkeys actually matter goes further.

Where adoption stands in late 2026

The October 2026 FIDO Passkey Index is built on data from 15 consumer services, up from 9 in 2025. Participants include Amazon, Google, Microsoft, PayPal, Shopify, TikTok, and WhatsApp. (FIDO Passkey Index 2026) The headline numbers:

• 36% of successful sign-ins now use a passkey, up from 26% in 2025
• 38% of accounts have a passkey enrolled
• 90% of active accounts are eligible for passkeys, and 42% of eligible accounts have one
• 93% sign-in success for passkeys vs 78% for passwords and traditional MFA such as SMS codes
• Sign-in 2.8x faster, saving about 27 seconds per sign-in on average (Start with Identity)
• All 8 participants that measure it report fewer successful phishing attacks since deploying passkeys
• 9 of 13 participants that answered plan to offer passwordless accounts in the next 12 months

FIDO notes that the year-over-year comparisons are directional, because the participant group changed between 2025 and 2026. Treat the trend as strong, and the exact deltas as approximate.

The platforms have moved too. Microsoft began making passkeys the default authentication experience in Entra ID on September 1, 2026. Microsoft-provided SMS and voice codes will be retired starting February 1, 2027. (Microsoft Learn, Cybernews) Microsoft also announced passkeys for Entra External ID, its customer identity product, aimed at customer-facing applications. (Biometric Update)

When the largest workforce identity provider stops sending its own SMS codes, the question for your board changes. It is no longer "should we try passkeys?" It is "why are we still paying for codes?"

The metric that matters: usage, not enrollment

In the 2026 Index, 8 of 10 participants still had a passkey sign-in share below their enrollment rate. Users had a passkey and were not routed to it at sign-in.

The gap is closing. In 2025, 34% of accounts had a passkey but only 26% of sign-ins used one, a gap of about 8 points. In 2026 it was 38% against 36%, a gap of about 2 points. (FIDO Passkey Index 2026)

The Index also shows why gaps persist. Two participants said their sign-in flow shows a password or one-time code before offering the passkey, even to users who have one. One estimated that offering the passkey first would roughly double its passkey sign-in share.

If your login page leads with a password form and hides the passkey option, you paid for the feature and kept the friction. Chapter 7 covers how to design around this. I wrote about the same pattern in the passkey success-rate vs enrollment gap.

Define the metrics precisely before launch, so nobody reports the flattering one:

Metric	Definition	Why it matters
Passkey enrollment rate	Share of active accounts with at least one passkey	Shows reach; easy to inflate with pushy prompts
Passkey share of sign-ins	Share of successful sign-ins completed with a passkey	The number that moves cost, success, and phishing exposure
Passkey sign-in success rate	Successful passkey sign-ins divided by passkey attempts	Catches platform bugs and confusing prompts
Enrollment-to-usage gap	Enrollment rate minus passkey share of sign-ins	Shows routing and design problems on the sign-in screen

Make passkey share of sign-ins the headline. Chapter 11 uses it as the gate between rollout phases.

The objections you will hear, and honest answers

"What happens when a customer loses their phone?" With synced passkeys, the passkey is already on their other devices or restores with their new phone. When every device is lost, the customer falls back to your recovery flow. That makes recovery the new front door, and Chapter 7 shows how to harden it.

"Our customers are not technical." They do not need to be. The experience is the same face or fingerprint unlock they already use many times a day. The 93% success rate comes from consumer services, not security teams.

"What about older devices?" Keep a fallback. Passkeys are added alongside existing methods, not forced. Chapter 5 compares the fallbacks and recommends a default stack.

"Are we locking customers into Apple or Google?" Users can store passkeys in third-party password managers too, as the synced row in the table above notes. Your server holds a standard public key either way.

"What does it cost?" Many identity platforms now include passkeys in standard plans, so check yours first. The bigger costs are design and support time. Offsets include fewer reset tickets and lower SMS spend. Chapters 9 and 10 cover vendors.

How to explain passkeys to your CEO

Use this script, or adapt it, in a two-minute slot.

"Passkeys replace the password with the face or fingerprint unlock customers already use on their phone. In the industry's 2026 data across 15 large consumer services, passkey sign-ins succeed 93% of the time versus 78% for passwords with codes, and take about 27 seconds less. They cannot be phished, and a breach of our database would not leak anything usable for sign-in. Microsoft has already made them the default for its workforce product. Our plan is to offer them first on the sign-in screen, measure the share of sign-ins that use them, and cut SMS spend and reset tickets as that share rises. The first milestone is in 60 days."

Then show one slide with three numbers: your current sign-in success rate, your monthly reset tickets, and your monthly SMS spend. Those are the numbers passkeys are supposed to move.

How to explain passkeys to customers

Customers do not need cryptography. They need to know it is faster, safer, and private. Keep the copy short and put it where the decision happens.

Enrollment prompt, after a successful sign-in:

Sign in faster next time

Use your face, fingerprint, or screen lock instead of a password. It takes about two seconds, and it can't be stolen by fake websites.

[Create a passkey] [Not now]

One-line tooltip next to the passkey button:

A passkey lets you sign in with your face, fingerprint, or screen lock. Your biometric stays on your device; we never see it.

Short help article answer to "What is a passkey?":

A passkey is a safer replacement for your password. It is saved on your phone or computer, and you unlock it the same way you unlock your device. Passkeys only work on our real website and app, so a fake site can't trick you into giving one away. If you get a new phone, your passkey usually comes with it through your Apple, Google, or password manager account. You can still use your other sign-in options at any time.

Common mistakes

• Reporting enrollment as success. High enrollment with low usage means the sign-in screen is routing people around the passkey.
• Hiding passkeys in account settings. Almost nobody visits settings. Offer creation right after sign-in and after password reset.
• Asking for a code after a passkey sign-in. The passkey already proved possession and the user's unlock. Stacking a code adds friction and no assurance.
• Forcing passkeys at first signup for consumers. Make it the obvious default instead. Chapter 7 covers the enrollment moments that convert.
• Launching without a recovery plan. Attackers shift to the weakest remaining path. If recovery is a chat agent who resets accounts on request, that is your new front door.

Key takeaways

• A passkey is a key pair bound to your domain. Nothing phishable is typed, and nothing usable is stored on your server.
• Synced passkeys meet NIST AAL2 and are the right consumer default. Device-bound passkeys are required for AAL3.
• The 2026 FIDO Passkey Index shows 36% of sign-ins on passkeys, 93% vs 78% sign-in success, and 27 seconds saved per sign-in.
• Usage beats enrollment. Make passkey share of sign-ins your headline metric, and put the passkey first on the sign-in screen.
• Prepare plain-language scripts for executives and customers before launch, and harden recovery at the same time.