Passkey and Fallback Capability Matrix: Web, Native Apps, Managed Recovery

Key takeaways

• Passkey support is three questions, not one: web, iOS native, Android native. Vendors answer one and go quiet on the rest.
• The real buying question is who sends the fallback message. Auth0 and Authsignal both hand you an SMS provider to wire up yourself.
• WorkOS ships passkeys in the hosted UI only, with no API path and no self-service passkey management screen.
• Supabase Auth and Firebase Authentication document no WebAuthn support at all. Their factors are TOTP and phone.
• An SMS fallback caps the account at SMS strength. NIST treats PSTN out-of-band as a restricted authenticator.
• Recovery is where the phishing win gets handed back. Design it before the vendor shortlist, not after the contract.

If you are shortlisting a vendor to ship passkeys across a web app and a native mobile app, two facts decide the project and neither one appears on a pricing page. The first is which of your three surfaces the vendor actually documents a passkey ceremony for. The second is whether the fallback factor is a service the vendor operates or a set of API hooks you point at a provider you contract yourself.

This page is a capability reference, checked against vendor documentation on 18 September 2026. It is not a shortlist and it does not rank anybody. The adoption view, which is a different question, lives on the passkey orchestration page.

How to read the cells

Three values appear, and they mean different things.

• Documented. The vendor's own documentation describes it, and the page is cited below the table.
• Not documented. We looked at the vendor's documentation for this capability and it is not described there. That is a statement about the documentation, not a claim that the product cannot do it.
• Not checked in this pass. We did not verify this cell against a primary source on this date. Absence of a check is not evidence of absence.

That third value exists deliberately. Filling unknown cells with a confident tick is how vendor matrices become wrong six months after publication.

Passkey support by surface

Vendor	Web	iOS native	Android native	Domain and RP ID constraint documented
Auth0	Documented, Universal Login	Documented, native passkeys for iOS	Documented, native passkeys for Android	Not checked in this pass
Amazon Cognito	Documented, WEB_AUTHN first factor	Via the same choice-based API, no platform-specific guide cited	Same as iOS	Not checked in this pass
Entra External ID	Documented, passkey (FIDO2) as MFA and passwordless	Native auth supports local account methods only, passkey via web fallback	Same as iOS	Registration requires a custom URL domain
WorkOS AuthKit	Documented, hosted UI only	Not documented	Not documented	Custom domain required before enabling passkeys in production
Clerk	Documented	Documented via Expo setup guide	Documented via Android setup guide	Not checked in this pass
Stytch	Documented	Documented, iOS SDK passkey methods	Documented, Android SDK passkey methods	Not checked in this pass
Descope	Documented, Passkey and Biometrics flow components	Documented, iOS SDK	Documented, Android SDK	Passkeys are domain specific, multi-domain needs a flow condition
Authsignal	Documented	Documented, iOS SDK with no-credential handling	Documented, Android SDK with no-credential handling	Not checked in this pass
Corbado	Documented, overlay in front of an existing IdP	Documented as part of the same overlay	Documented as part of the same overlay	Overlay owns the WebAuthn server, your IdP keeps the users
Supabase Auth	Not documented	Not documented	Not documented	Not applicable
Firebase Auth	Not documented	Not documented	Not documented	Not applicable

Two rows deserve a sentence before you scroll past them.

Entra External ID is the sharpest example of why "supports passkeys" is not a useful answer. Microsoft documents passkey (FIDO2) as both an MFA method and a passwordless primary method in external tenants. It also documents that only email plus password and username plus password local account users can register one, that registration requires a custom URL domain, and that the user must complete MFA before registering. Users who sign in through an external identity provider or through email one-time passcode cannot register a passkey at all.

Supabase Auth and Firebase Authentication are the two rows where the honest answer is a blank. Supabase documents exactly two MFA factor types, an authenticator app using TOTP and phone messaging. Firebase documents passwords, phone numbers, email link, federated providers, and TOTP MFA on the Identity Platform tier. Neither documentation set describes a WebAuthn ceremony. If you are on either and passkeys are the requirement, you are looking at an overlay or a migration, not a configuration change.

Fallback that ships in the product, and who sends it

Vendor	Email code or link	SMS OTP	TOTP	Recovery codes	Who sends the message
Auth0	Not checked in this pass	Documented	Not checked in this pass	Not checked in this pass	You. Configure your own phone messaging provider, Twilio or custom, one per tenant
Amazon Cognito	Documented, EMAIL_OTP first factor	Documented, SMS_OTP first factor	Documented, authenticator app MFA	Not checked in this pass	You. Email OTP requires the Essentials plan or higher plus your own Amazon SES configuration
Entra External ID	Documented, first and second factor with a caveat	Documented, second factor only	Not checked in this pass	Not checked in this pass	Microsoft. SMS is a paid add-on requiring a linked subscription, with opt-in regions and CAPTCHA
WorkOS AuthKit	Documented, Magic Auth email code	Not documented	Documented, MFA	Not checked in this pass	Not checked in this pass
Clerk	Documented, email code and email link	Documented, SMS code	Documented	Documented, backup codes	Not documented on the page checked
Stytch	Documented, email magic links and email OTP	Documented, SMS OTP and WhatsApp OTP	Documented, with recovery codes	Documented, TOTP recovery codes	Not checked in this pass
Descope	Documented, OTP, magic link, enchanted link, embedded link	Documented, OTP and WhatsApp nOTP	Documented, authenticator apps	Documented, recovery codes	Not checked in this pass
Authsignal	Documented, email OTP	Documented, SMS OTP	Documented	Not checked in this pass	You. Pick Twilio, Bird, MessageMedia, TNZ, Modica, or a webhook in the Authsignal portal
Corbado	Inherited from the IdP underneath	Inherited from the IdP underneath	Inherited from the IdP underneath	Inherited from the IdP underneath	Whoever runs the IdP you kept
Supabase Auth	Not applicable to MFA, phone and TOTP only	Documented, phone factor	Documented, app authenticator	Not checked in this pass	Not checked in this pass
Firebase Auth	Documented, email link sign-in	Documented, phone auth	Documented, TOTP MFA on Identity Platform	Not checked in this pass	Not checked in this pass

Managed service versus something you wire up

This is the column that decides the project plan, and it is the one that never makes the comparison chart.

A CIAM vendor can list SMS OTP as a feature while shipping nothing that sends a text message. What it ships is a challenge orchestration layer, a template editor, and a place to paste credentials for a provider you sign a separate contract with. Auth0 documents exactly this: you configure one phone messaging provider per tenant, Twilio or a custom provider, and it carries all SMS and voice. Authsignal, a passkey specialist rather than a full platform, does the same thing with a wider provider list and a webhook escape hatch.

Amazon Cognito is a variant of the same pattern inside one cloud bill. Email one-time passcode as a first factor requires the Essentials feature plan or higher and your own Amazon SES configuration. The default Cognito sender exists, carries a daily cap, and the documentation says plainly that the default limit is below production volume for typical environments.

Microsoft Entra External ID is the clearest managed case in the table and it still comes with strings. Microsoft delivers the SMS. It is a second factor only, never a first factor. It is billed as an add-on against a linked Azure subscription, and Microsoft documents that if the subscription expires or is cancelled, users can no longer authenticate by SMS, which can lock them out depending on your policy. Some regions are deactivated by default and need an explicit opt-in.

Three questions settle this in a vendor call.

1. When an SMS fails to deliver in Indonesia at 2am, whose support queue is it in.
2. Does the per-message cost sit in the identity contract, a telecom contract, or a cloud bill.
3. If the messaging contract lapses, does login break, and for which users.

The first question is the one that changes answers. Vendors who operate delivery answer it immediately. Vendors who do not tend to explain the architecture instead.

What each fallback costs you in security

A fallback is not a feature you add. It is a ceiling you set. The account is exactly as strong as the weakest path into it, and the passkey does nothing about the path the attacker chooses.

• SMS OTP. The weakest common option. SIM swap, SS7 interception, and adversary-in-the-middle proxies all defeat it, and none of them care that a passkey is registered. NIST designates PSTN out-of-band as a restricted authenticator, which obliges the relying party to warn users about the risk and to offer a non-restricted alternative. Shipping passkeys next to an always-available SMS button produces an SMS-grade account with a passkey-grade slide deck.
• Email OTP or magic link. Only as strong as the mailbox, which for most consumers is a Google or Microsoft account that is itself the recovery root for everything else. Phishable in real time by the same proxy kits. Acceptable as one signal among several. Dangerous as the single self-service path back into a high-value account.
• TOTP. Not SIM-swappable and not tied to a carrier, which puts it clearly above SMS. Still phishable through an adversary-in-the-middle proxy, because the user types the code into whatever page asked for it. Good second rung. Not a passkey substitute.
• Recovery codes. Strong against remote attack, weak against human behaviour. Users screenshot them, mail them to themselves, or lose them. They work best generated at enrolment, shown once, and paired with a support path for the majority who will not keep them.
• Help-desk or agent-assisted reset. The highest-assurance option and the most-attacked one. Its strength is entirely the verification script the agent follows. An agent who can reset a passkey after confirming a date of birth has converted your phishing-resistant deployment into a social-engineering target.

Recovery is the real failure mode

Every passkey rollout eventually meets the same wall, and it is not enrolment. It is the user on a brand new phone, on a different platform from the one that holds their synced credential, with a passkey that will not travel.

That user does not fail at the passkey prompt in an interesting way. On iOS, a missing credential and a cancelled prompt return the same error, which is why Authsignal's own mobile guidance tells you to treat both cases identically and present the backup screen. The user fails at whatever you put behind that screen, and whatever you put behind that screen is your actual authentication assurance level.

Having run identity at scale at LoginRadius, across a userbase that grew past a billion identities, the pattern that repeats is consistent. Teams budget carefully for the passkey ceremony and treat recovery as a two-week task at the end. Recovery is then built from whatever channel is cheapest to turn on, which is email or SMS, and the phishing resistance that justified the whole project quietly disappears into the reset flow.

Two design rules follow from that, and neither depends on which vendor you pick.

The first is to enrol the fallback before the passkey, not after. Authsignal documents this as a product pattern: prompt for the passkey only once another factor is bound to the user, so the backup always exists at the moment it is needed. It costs one extra screen at signup and removes the entire class of "new device, no way in" tickets.

The second is to treat recovery as a separate risk decision from login. Rate limit it harder. Add a delay with a cancel notification for high-value accounts. Require more than one weak signal rather than one. The full treatment is in account recovery design, which is the companion to this page.

Running this as an evaluation

Ask for a working demo, not a capability sheet, and ask for it on the surface you actually ship.

1. Register a passkey on the vendor's hosted or embedded web flow, on your own domain, not theirs.
2. Sign in on a native build on both iOS and Android, using the same account.
3. Delete the passkey from the platform credential manager, then sign in again and watch what the fallback screen offers.
4. Do the same on a device from the other platform vendor, to force the cross-platform case that synced credentials do not cover.
5. Ask who sent the email and the text message in steps three and four, and ask for the contract that covers it.

Step five is the one that reorders shortlists. It also tends to surface the gap between a vendor that operates a fallback and a vendor that orchestrates one.

Where this page stops

Anything marked "not checked in this pass" is an open item, not a negative finding. The cells will be filled on the next verification sweep rather than guessed at now.

Several vendors with a Compass profile have no row above. That list includes Keycloak, FusionAuth, SuperTokens, Hanko, Beyond Identity, MojoAuth, Transmit Security, and Frontegg. None was re-verified against its documentation on this date. They are left out rather than carried over from an older check, and their capability records live on their profiles.

If you are staying on a platform whose passkey answer is thin and the only failing axis is enrolment, the overlay route is covered in passkey overlays versus CIAM. If SMS is still your default second factor, the migration sequence is in deprecating SMS OTP.