Skip to content
Start with Identity
Analysis

54% of business SaaS apps support passkeys or security keys. Only 13% let you require them

SWI's Phishing-Resistant MFA Support Matrix checked 95 business SaaS apps against their own documentation. 51 support passkeys or FIDO2 security keys, 12 let admins require them, and 60% of apps with a documented SSO plan charge more for SSO. Here is what the matrix is and how to use it.

By SWI Community TeamNov 9, 2026

Of 95 widely used business SaaS apps, 51 (53.7%) document passkeys or FIDO2 security keys on their own login, but only 12 (12.6%) let an admin require them, according to Start with Identity's new Phishing-Resistant MFA Support Matrix. For each app it records passkey and security key support, whether an admin can make them mandatory, which plan includes SSO, and SCIM support, with every cell linked to vendor documentation checked on October 31, 2026. The analysis is in the full report.

Why we built it

Answering "can we require phishing-resistant MFA in this app?" takes an afternoon per vendor. The facts are spread across help center articles, admin guides, changelogs and pricing tables, and they disagree with each other. One Atlassian article says managed accounts cannot use passkeys while a newer admin article says admins can allow them. GitHub has a setting called "Only allow secure two-factor methods" that still accepts authenticator apps.

The cost side is just as hidden. Most apps cannot enforce passkeys themselves, so the real route is SSO to an identity provider that does. Whether SSO sits two plans up rarely reaches the security review. We wanted one table, with a source behind every cell, that answers both questions.

Three findings

Support is common, enforcement is rare. Of the 51 apps that support a phishing-resistant factor, 31 (60.8%) leave it optional. Optional means a phishing page can ask for the weaker factor the account still allows. Seven of the 12 apps that do enforce are identity platforms or run on one, such as Microsoft 365 through Microsoft Entra Conditional Access, Google Workspace, and the Okta and Duo admin consoles. Only five other business apps document it: Confluent Cloud, HubSpot, Rippling, ServiceNow and Snowflake.

The SSO tax is often the price of phishing resistance. 49 of the 82 apps that offer SSO and document its plan (59.8%) charge more for it, through a higher tier, an enterprise plan or a paid add-on. Apps with no SSO or no documented SSO plan are left out of that rate. Combine that with enforcement: of the 71 apps that cannot require phishing-resistant MFA locally and document an SSO plan, 48 (67.6%) put SSO behind a higher price. For two apps in three, enforcing passkeys means paying for the plan that includes SSO.

A third of vendors do not document their own MFA. 35 of 95 apps (36.8%) leave passkey support, security key support or enforcement undetermined from public documentation, and 11, including Zoom, Asana, Miro and Workday, leave all three undetermined. In 8 of the 35 the help center could not be machine-read. In the other 27 the readable docs are silent. We count "not documented" as its own value, never as "no", because a buyer who cannot check a vendor's MFA options before signing has a vendor-risk finding either way.

How it helps

Security architects and IAM teams. Use the matrix as the MFA and SSO line of a SaaS onboarding checklist. Filter to apps where enforcement is "No" or "Via SSO only" and you have the list that must sit behind the IdP with SSO required. The report also flags apps where requiring SSO switches off the app's own passkeys, and apps where owners keep a local login, which are the bypasses to close. Pair it with the passkey rollout checklist and the WebAuthn and FIDO2 standard page.

Procurement and vendor risk. The SSO plan column turns the SSO tax into a budget line before renewal, not after the security review. Where MFA options are "Not documented", ask in the security questionnaire for a public link. The source URLs in each row are evidence you can attach to the assessment.

Auditors and GRC teams. Phishing-resistant MFA coverage is easier to evidence per app when each claim points to the vendor's own page with a verification date. The matrix separates "the app supports it" from "an admin can require it", which is the distinction a control test needs. Map it to your SaaS inventory, then test the IdP policy the rest rely on.

Analysts and research organizations. The data is free under CC BY 4.0. Download the CSV or JSON, cite "Start with Identity, Phishing-Resistant MFA Support Matrix 2026" with a link, and link a specific figure with its finding anchor, such as #finding-4. Each app has its own anchor in the matrix too, for example /tools/mfa-matrix/#github. We plan quarterly re-checks, each change dated.

SaaS vendors. If your app is missing or a cell is wrong, the fix is public documentation. Document your MFA methods, whether admins can require passkeys or security keys, which plan includes SSO and SCIM, and send the link through our contact page. We update from public pages only, so a vendor that documents enforcement gets credit for it, and one that does not stays "Not documented".

What to do now

Enforce passkeys or FIDO2 security keys at the identity provider, put every app that supports it behind mandatory SSO, close local-login and break-glass bypasses, and provision with SCIM so leavers lose app accounts too. Our earlier post on where SCIM provisioning breaks covers that last step, and the phishing-resistant MFA rankings compare the vendors that can do the enforcing. The Identity Breach Report 2026 is the reminder of why: where the record says whether MFA protected the abused account, it was bypassed in 25 of 40 breaches.

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Independent analysis. No vendor sponsorship. Editorial policy · Report a correction