Passwordless Authentication Selection Matrix: Choosing a Method in 2026

Most passwordless projects stall on the same question: which method, for which users, at what cost. The short answer for 2026: synced passkeys are the default for consumer and general workforce login, and device-bound FIDO2 security keys are the answer for admins and high-value accounts. Push approval is the pragmatic bridge for a managed mobile fleet. Magic links belong only where a compromised mailbox is an acceptable worst case. Most organisations end up deploying two of these, not one.

This page is the selection matrix: how the five realistic methods compare on security, user experience, cost, and rollout effort, plus a decision framework for picking a primary and a backup. Once you have chosen, the sequenced rollout lives in the companion passwordless authentication implementation checklist. This page answers "which one"; that page answers "how do we ship it".

Last verified: September 2026. Checked against NIST SP 800-63B-4 (final, July 2025) and W3C WebAuthn Level 3, a Recommendation since 25 August 2026. Also against the FIDO Alliance State of Passkeys 2026 report and Passkey Index, and price lists published by Yubico, Google, Amazon Web Services, and Auth0.

What changed since this matrix was first written

Three things moved the ground under every passwordless comparison written before 2025.

• Passkeys stopped being a niche. The FIDO Alliance's State of Passkeys 2026 report puts roughly 5 billion passkeys in use, 75% of surveyed consumers with a passkey on at least one account, and 68% of surveyed organisations deploying or already deployed for employee sign-in. A 2024-era matrix that lists "biometrics" as a category and never says "passkey" is describing the wrong thing.
• NIST finalised its guidance. SP 800-63B-4 was published in final form in July 2025 and folded the April 2024 syncable-authenticator supplement into normative text. It pushes phishing-resistant authentication and states that syncable authenticators are not acceptable at AAL3, because the private key is exportable by design. That single sentence is the reason your admins need hardware keys even after everyone else gets passkeys.
• Hardware prices went up, not down. Security key list prices on Yubico's own store now start at $29 for the Security Key Series, $58 for the YubiKey 5 Series, and $98 for the Bio Series. Any budget built on "$25 a key" is short.
• The API stopped moving. WebAuthn Level 3 became a W3C Recommendation on 25 August 2026, the first full Recommendation since Level 2, with new features deferred to Level 4. Procurement questions about specification stability now have a clean answer. What it changes in practice is covered in WebAuthn Level 3, what is new in the passkey standard.

Quick decision guide

Read the row for your situation, then read the column that scores best. Legend: Yes = strong fit, Maybe = workable with caveats, No = do not lead with this.

Scenario	Synced passkeys	Device-bound FIDO2 keys	Push approval	Magic links	Email or SMS OTP
Consumer app, millions of users	Yes	No	Maybe	Maybe	Maybe
Small business, under 100 staff	Yes	Maybe	Yes	Maybe	No
Mid-market, 100 to 1,000 staff	Yes	Maybe	Yes	No	No
Enterprise, 1,000+ staff	Yes	Yes	Maybe	No	No
Administrators and privileged accounts	No	Yes	No	No	No
Regulated, AAL3 or equivalent required	No	Yes	No	No	No
Fully remote workforce	Yes	Maybe	Yes	Maybe	No
Shared or kiosk devices	No	Yes	Maybe	Maybe	Maybe
Frontline staff with no company phone	Maybe	Yes	No	No	No
Tight budget, no hardware line item	Yes	No	Yes	Yes	Yes
B2B SaaS with enterprise buyers	Yes	Maybe	Maybe	No	No

The five methods in detail

1. Synced passkeys (platform biometrics)

A WebAuthn credential created on the user's device, unlocked by Face ID, Touch ID, Windows Hello, or a device PIN, and backed up to the user's Apple, Google, or password-manager account so it survives a lost phone. This is the method most people mean when they say "passwordless" in 2026.

Best for: consumer login at scale, general workforce sign-in, any product where enrolment friction decides adoption, and any team that cannot ship hardware to users.

Advantages: phishing resistant by construction, because the credential is bound to the origin and the private key never leaves secure hardware. No shared secret exists on your server to steal. Login is typically one biometric gesture. Recovery is handled by the platform account rather than your support desk. No hardware cost.

Disadvantages: the private key is exportable to the sync fabric, which is exactly why NIST SP 800-63B-4 rules synced authenticators out at AAL3. Your security now partly depends on the strength of the user's Apple or Google account. Cross-ecosystem sharing (an Android passkey used on a Mac) still leans on QR-code hybrid transport, which users find confusing. You inherit whatever the platform vendor decides next.

Rollout effort: 2 to 6 weeks on a CIAM platform with first-class passkey support. Longer if you are building WebAuthn directly, because conditional UI, credential discovery, and the fallback ladder are the hard parts, not the cryptography.

2. Device-bound FIDO2 security keys

A physical authenticator (YubiKey, Feitian, Google Titan, or a platform authenticator configured as device-bound) where the private key is generated in the key and cannot be exported. This is the only method on this list that meets AAL3 as written.

Best for: domain admins, finance approvers, source-code and production access, regulated environments, and any account whose compromise is a company-level event.

Advantages: the strongest phishing resistance available, no dependency on a phone or a cloud account, works on shared devices, and it is attestable, so you can prove to an auditor which model of authenticator was used.

Disadvantages: the cost is logistics, not licensing. You buy at least two keys per user so there is a spare, you ship them, you track them, you replace lost ones, and you build a vetted re-enrolment process for the day someone loses both. Yubico's list prices start at $29 (Security Key Series), $58 (YubiKey 5 Series), and $98 (Bio Series). Budget the shipping and the replacement rate, not just the unit price.

Rollout effort: 1 to 3 months, most of it procurement, distribution, and designing recovery. The technical integration is the same WebAuthn work as passkeys.

3. Push approval (mobile authenticator)

The user signs in, an app on their enrolled phone shows an approval prompt, and they accept it. Modern implementations require number matching, show the requesting application and location, and rate-limit repeated prompts.

Best for: workforce deployments with a managed mobile fleet, organisations already running Microsoft Authenticator, Duo, or Okta Verify, and step-up approval on top of another primary factor.

Advantages: familiar, fast, no hardware to ship, and it carries device-posture signal the identity provider can use. Deployment is well-trodden ground with mature tooling.

Disadvantages: push is not phishing resistant on its own. Push fatigue, where an attacker with a stolen password spams prompts until someone taps accept, is a proven and repeatedly used technique. Number matching reduces it materially but does not eliminate adversary-in-the-middle proxying. It also requires every user to own and carry a suitable phone, which excludes frontline and shared-device populations.

Rollout effort: 2 to 4 weeks if you already have the identity provider. Add time for the phone-enrolment helpdesk spike in week one.

4. Magic links

The user enters an email address, receives a single-use signed URL, and clicking it signs them in. Technically passwordless. Functionally, it relocates the credential into the mailbox.

Best for: low-risk consumer products, early-stage products that need a login today, and secondary flows such as invitation acceptance.

Advantages: the cheapest method to build and operate. No hardware, no app, no enrolment ceremony, and no password reset flow to maintain. Users already understand it.

Disadvantages: the security of the account is exactly the security of the mailbox, and it is not phishing resistant. Email deliverability becomes a login-availability problem: a delayed or spam-filtered message is a failed login. Corporate link scanners routinely pre-fetch URLs and burn single-use tokens before the human clicks. Link-opening in an in-app browser breaks session continuity. Do not use this for anything with money, health data, or admin rights behind it.

Rollout effort: 1 to 2 weeks. Most of the real work is deliverability and token-handling hygiene, not the feature itself.

5. Email or SMS one-time codes

A six-digit code sent to a phone number or mailbox. Included here because it is what most organisations are actually migrating away from, and because the comparison is the argument for the migration.

Best for: nothing, as a primary method, in a new build. It survives as a fallback for users who cannot use anything else, and as a step-up in low-risk flows.

Advantages: universal reach. Every user has a phone number or an email address, no app install required, and it works on a ten-year-old handset.

Disadvantages: SMS is vulnerable to SIM swap, SS7 interception, and real-time phishing relay, and NIST has been steering implementers away from it for years. It is also the most expensive method to run at consumer scale, because you pay per message and you absorb SMS pumping fraud. Delivery is unreliable in exactly the markets where support costs most.

Rollout effort: days. Retiring it is the project, not adding it.

Feature comparison matrix

Attribute	Synced passkeys	Device-bound keys	Push approval	Magic links	Email or SMS OTP
Phishing resistant	Yes	Yes	Partial, with number matching	No	No
Resists adversary-in-the-middle proxy	Yes	Yes	No	No	No
Server holds a stealable secret	No	No	No	No	No
Meets NIST AAL3	No	Yes	No	No	No
Hardware cost per user	None	$29 to $98+ per key, two keys recommended	None if BYOD	None	None, but per-message cost
Works offline	Yes	Yes	No	No	No, for SMS
Works on shared or kiosk devices	No	Yes	Partial	Partial	Partial
Survives device loss without helpdesk	Yes, via platform sync	Only if a spare key exists	No	Yes	Partial
Measured time to authenticate	8.5 seconds average	Not measured separately	Grouped in the 31.2 second figure	Not measured separately	Grouped in the 31.2 second figure
Attestable to an auditor	Limited	Yes	Partial	No	No
Implementation complexity	Medium	Medium technically, high operationally	Low to medium	Low	Low

Timing figures come from the FIDO Alliance Passkey Index, which reports an average of 8.5 seconds per passkey sign-in against 31.2 seconds for traditional multi-factor methods. Those are self-reported aggregates from nine large consumer deployments, so read them as direction rather than as a target for your own product. The other rows describe properties of the method, not measurements.

Cost model

Two kinds of number appear in passwordless budgets. The first is published on a seller's own price list and can be checked in a minute. The second is integration effort and support load, where no credible public benchmark exists. This section keeps them apart, because mixing them is how a spreadsheet of invented dollars reaches a finance review.

Published unit prices, read September 2026

Item	Published list price	Source
Security Key NFC by Yubico, FIDO2 only	$29 per key	yubico.com/store
YubiKey 5 NFC and 5C NFC	$58 per key	yubico.com/store
YubiKey Bio, FIDO Edition	$98 per key	yubico.com/store
Google Titan Security Key	$30 per key	store.google.com
Outbound email, Amazon SES	$0.16 per 1,000 emails on the first 10 million per month	aws.amazon.com/ses/pricing
Outbound SMS to a US number, AWS End User Messaging	$0.01 per message plus a $0.01 carrier fee	aws.amazon.com/end-user-messaging/pricing
Consumer identity platform, Auth0 B2C	Free to 25,000 monthly active users, then $70 per month at 1,000 MAU on Essentials and $1,000 per month at 5,000 MAU on Professional	auth0.com/pricing

Hardware prices are the manufacturer's own store rather than a reseller, and exclude shipping and tax. The message and platform rows are one provider's public rate card each, picked because the numbers are published without a sales call. Your providers will differ, and their rate cards are equally checkable in a minute.

What those prices imply, at 1,000 users

Every line below is arithmetic on a price in the table above, with the working shown. Change an input and the output changes with it.

Calculation	Working	Result
Two FIDO2-only keys per user	2,000 keys at $29	$58,000 at list
Two YubiKey 5 NFC per user	2,000 keys at $58	$116,000 at list
Annual replacement at a 5% loss rate	50 keys at $29 to $58	$1,450 to $2,900 a year
Email code or magic link, two logins per user per month	24,000 emails at $0.16 per 1,000	$3.84 a year
SMS code to US numbers, same volume	24,000 messages at $0.02	$480 a year
Passkeys and push approval	No per-authentication message	$0 a year

The 5% loss rate is your input, not a published benchmark, so substitute your own asset-loss experience. The two message rows are what make the SMS argument concrete: at identical volume, SMS costs about 125 times what email costs, before any SMS pumping fraud. Both are small next to the hardware line, which is the point.

What has no public price

Integration effort and support load are usually the largest lines in a passwordless budget, and neither has a credible public benchmark. The dollar figures in circulation come from parties selling the outcome. Estimate these in engineer-days and helpdesk-hours at your own rates, and answer these questions before you put a number on them.

• Integration. Are you buying a platform with first-class WebAuthn support or building against the API? How many applications authenticate, and how many speak OIDC or SAML today? Does conditional UI need front-end work in each one? Who designs the recovery path, which is normally larger than the login path?
• Enrolment and support. How many users, prompted over how many weeks, at what contact rate in week one? What does an hour of your helpdesk cost fully loaded? For hardware, add receiving, tracking, shipping to new joiners, and the vetted process for the person who loses both keys.
• The offsetting saving. Reset tickets do fall. The FIDO Alliance Passkey Index reports up to an 81% reduction in sign-in-related helpdesk incidents across its nine participating deployments, self-reported. Enrolment and recovery tickets are new work, so model the net rather than the gross.

Two structural points hold whatever numbers you put in. Hardware key programmes are dominated by logistics and replacement, not by the keys themselves. And the net saving arrives after the first full year, not during it. For the payback case, see the ROI of passwordless guide.

Decision framework

Five questions decide the answer, in this order.

1. What is the worst thing an attacker can do with a compromised account? If the answer involves money, regulated data, or production systems, the primary method is phishing resistant and there is no argument. If the answer is "read their saved recipes", magic links are defensible.
2. Do you have an assurance-level obligation? If any control framework, contract, or regulator pins you to AAL3 or an equivalent, device-bound hardware is mandatory for that population. Synced passkeys will not satisfy it.
3. What hardware do your users actually have? Enumerate the population without a modern phone, on shared devices, or on unmanaged machines. That group determines your fallback, and the fallback is where the attack lands.
4. Who absorbs recovery? Synced passkeys push recovery to Apple and Google. Hardware keys push it to your helpdesk. Push pushes it to phone re-enrolment. Pick the one your support model can carry.
5. What is your migration path off the current method? A passwordless method you cannot roll back from is a production risk. Keep the old path live in parallel for one full cycle.

Recommended pairings

Every deployment needs a primary and a designed backup. The single most common failure in passwordless projects is shipping the primary and improvising the backup, because the improvised path becomes the weakest link and the route attackers use.

Population	Primary	Backup	Explicitly not
Consumer app	Synced passkeys	Email OTP with rate limiting and risk checks	SMS as the only fallback
General workforce	Synced passkeys	Push approval with number matching	Security questions
Administrators and privileged access	Device-bound FIDO2 key	Second device-bound key, held in escrow	Any fallback the helpdesk can trigger by phone
Regulated or AAL3	Device-bound FIDO2 key	Second key plus in-person re-proofing	Synced passkeys
Frontline or shared devices	Device-bound key on a lanyard	Supervisor-attested reset	Push to a personal phone
Early-stage product	Magic links	Email OTP	Building your own WebAuthn stack first

How this matrix was built

This is a documentation and standards review, not a lab test. No hands-on benchmarking claims are made here. What was checked, in September 2026:

• Standards text. NIST SP 800-63B-4 (final, July 2025) for assurance levels and the syncable-authenticator position, which states that syncable authenticators shall not be used at AAL3. W3C WebAuthn Level 3, a Recommendation since 25 August 2026, for the credential model and transport behaviour.
• Adoption data. The FIDO Alliance State of Passkeys 2026 report, including its stated methodology (two Sapio Research studies fielded April 2026, 11,000 consumers and 1,400 workforce decision-makers across ten countries). It is vendor-adjacent survey data, so treat the direction as sound and the precise percentages as soft.
• Performance data. The FIDO Alliance Passkey Index (October 2025), an aggregate of figures reported by nine member deployments including Amazon, Google, Microsoft, PayPal, and TikTok. The companies reported their own numbers, so treat them as the direction of travel at consumer scale.
• Published prices read on the seller's own site in September 2026: the Yubico store, the Google Store, the Amazon SES and AWS End User Messaging rate cards, and the Auth0 pricing page. No reseller listings, no quoted prices.
• Threat behaviour that is publicly documented and repeatedly observed: push fatigue, adversary-in-the-middle proxies, SIM swap, and link scanners burning single-use tokens.

Every dollar figure on this page is either a list price published on the seller's own site, or arithmetic on one of those prices with the working shown. Integration effort and support load carry no dollar figure here, because no credible public benchmark exists for either. Where a number could not be sourced, it was removed rather than softened. The rollout-effort ranges beside each method are planning estimates for sequencing a project, not measured figures, and no public benchmark exists for them.

Frequently Asked Questions

Which passwordless method should we choose?

Match the method to the threat model rather than to the technology. Synced passkeys are the correct default for consumer and general workforce login. Device-bound FIDO2 keys are the answer for administrators, privileged access, and anything with an AAL3 obligation. Push approval is a workable bridge on a managed mobile fleet. Magic links are the cheapest and weakest, and they inherit the security of the mailbox behind them.

Are magic links really passwordless authentication?

Technically yes, functionally they relocate the problem. A magic link makes the user's email account the credential, so the security of the login is exactly the security of that mailbox. That is acceptable for low-risk consumer products and a poor fit anywhere account takeover has real consequences, because a compromised mailbox becomes a compromised account everywhere it is used.

Why are security keys more expensive than other methods?

Because the cost is hardware plus logistics, not licensing. You buy physical devices at $29 to $98 each on list, you buy spares because people lose them, you ship them to new joiners, and you build a vetted recovery process for the ones that go missing. The authentication itself is nearly free. The programme around it is what costs money.

Do we still need a backup authentication method?

Yes, always, and it is the most commonly skipped step. Every passwordless method fails in ordinary ways: phones break, keys get lost, biometrics stop reading, platform accounts get locked. Without a designed recovery path, support desks improvise one, and improvised recovery becomes the weakest link in the system and the route attackers actually use.

Is biometric data stored on a server?

With platform authenticators, no. The biometric stays in secure hardware on the device and is used only to unlock a private key that never leaves it, so your server receives a cryptographic assertion rather than a fingerprint or a face. That distinction matters in privacy review, and it is worth confirming explicitly with any vendor that claims biometric support.

What is the difference between synced and device-bound passkeys?

A synced passkey is backed up to the user's platform or password-manager account, so it survives a lost device and can appear on several devices. A device-bound passkey lives only in the hardware that created it and cannot be exported. Synced passkeys win on recovery and adoption. Device-bound passkeys win on assurance, and NIST SP 800-63B-4 permits only the device-bound form at AAL3.

How is passwordless different from multi-factor authentication?

They answer different questions. Multi-factor authentication adds a second check on top of a password. Passwordless removes the password as a factor entirely, usually replacing it with possession of a device plus a local biometric or PIN. A well-implemented passwordless method is often multi-factor by construction, which is why it can be both stronger and faster to use.

Can we deploy just one method for everyone?

Almost no organisation manages it. Populations differ: administrators need higher assurance than customers, frontline staff may have no phone, and some users cannot complete a biometric enrolment. Plan for a primary method covering the majority, a higher-assurance method for privileged accounts, and one designed fallback. Three paths, each documented, beats one path plus improvisation.

Next steps

1. Segment your users by worst-case impact and by the hardware they actually own. This produces the populations, and the populations produce the method choice.
2. Pick a primary and a backup per population using the pairings table above, and write down why each was rejected as well as chosen. That record is what stops the decision being relitigated every quarter.
3. Price the real thing. Get vendor quotes, add hardware at list plus a replacement rate, and put the year-one support spike in the model rather than after it.
4. Run the rollout from the implementation checklist, which sequences assessment, pilot, departmental rollout, and ongoing review.

Related reading: passkeys explained, FIDO2 explained, account recovery design, and the top passwordless CIAM platforms if you are choosing a vendor rather than a method.