Phishing-Resistant MFA Support Matrix 2026

Most business SaaS apps now support phishing-resistant MFA, and very few let you require it. Of 95 widely used business apps in Start with Identity's Phishing-Resistant MFA Support Matrix, 51 (53.7%) document passkeys or FIDO2 security keys on their own login, but only 12 (12.6%) let an admin make them mandatory. Thirty-one of the 51 leave the factor optional, so any user can still sign in with an authenticator code or SMS that a phishing page can relay. The usual answer is to enforce at the identity provider over SSO, and that is where the second problem sits: 49 of the 82 apps (59.8%) that offer SSO and document its plan charge more for it. For two of every three apps that cannot enforce locally, phishing resistance costs a plan upgrade.

This report covers what the matrix measures, the eight findings, the vendor facts that surprised us most, and a concrete SSO-first route to phishing-resistant coverage. Every cell links to the vendor's own documentation, and the data is free to reuse under CC BY 4.0.

Methodology

Scope. 95 business SaaS apps that employees and admins sign in to, in 10 categories: collaboration, productivity, CRM and sales, HR and finance, DevOps and engineering, cloud infrastructure, security and IT, data and analytics, design and marketing, and support and service. We picked widely used products, not a random sample. What we classify is the app's own workforce login: how an employee or admin signs in to the vendor's hosted app, not the customer-facing login features the vendor sells. Eleven of the apps are consoles of identity or security vendors that have an SWI profile (for example the Okta Admin Console and the Duo Admin Panel), and we classify their admin login the same way.

Sources. Vendor documentation and pricing pages only: help centers, admin guides, security pages, changelogs and plan comparison tables. No analyst reports, reviews or forum posts count as evidence for a "yes". The dataset holds 365 source links, and every app was verified on October 31, 2026. We did not sign up for or test the products; a "yes" means the vendor documents it.

What the values mean.

"Not documented" is never counted as "no". It is a finding of its own (Finding 8). The SSO fields record whether SAML and OIDC are offered at all, the lowest plan that includes SSO as named on the pricing page, and an SSO tax class: none (on every paid plan), upper-tier, enterprise-only, add-on, not offered or plan not documented. SCIM is yes, enterprise-only, no or not documented.

Limits. Documentation lags and leads products: a feature can ship before the help center catches up, or a doc can describe a beta not every tenant has. Plan names and inclusions change, often quarterly. A "yes" on enforcement can still need a paid add-on (Microsoft's Conditional Access needs Entra ID P1, which Microsoft 365 Business Basic and Standard do not include). Where a vendor sells only by quote and its docs tie SSO to no plan (ServiceNow, Gong), the SSO tax is classed "none" because no gating is documented, not because a vendor said so. Ten vendors' help or pricing pages rendered only with JavaScript or blocked automated reading, which drives some of the "not documented" cells. Category groups are small (4 to 16 apps), so read category rates as directions.

The script scripts/reports/mfa-matrix-report.mjs prints every number below from the dataset, with its denominator.

Finding 1: support is common, enforcement is rare

Among the 78 apps that document at least one of the two factors, 51 (65.4%) support one. Security keys are a little more common than passkeys: 11 apps document keys and not passkeys (among them 1Password, Box, Heroku and Tableau Cloud), while 4 document passkeys and not keys. Only Slack explicitly says no to security keys while supporting passkeys.

Now the gap. For the 51 apps that support a phishing-resistant factor:

That is a gap of 39 apps between "supports" and "enforces", or 53.7% of all apps against 12.6%. Optional phishing-resistant MFA protects the users who choose it. It does not protect the account an attacker targets, because the attacker's phishing page simply asks for the weaker factor the account still allows. The pattern repeats across GitHub, GitLab, Atlassian Cloud, Dropbox, Notion, Stripe, Shopify, Salesforce and the Cloudflare dashboard: each documents keys or passkeys and an admin "require 2FA" switch, and none lets the admin say which 2FA.

Finding 2: the apps that enforce are mostly identity platforms

Seven of the 12 apps that let an admin require phishing-resistant MFA are identity platforms or sign in through one: Microsoft 365, the Azure portal and the Microsoft Entra admin center (all through the built-in Phishing-resistant MFA authentication strength in Conditional Access), Google Workspace and Google Cloud console (the 2-Step Verification option "Only security key", which now accepts passkeys too), the Okta Admin Console (an app sign-in policy requiring a phishing-resistant possession factor) and the Duo Admin Panel (Owners can limit admins to chosen methods, so passkeys-only is possible).

Only five other business apps document it:

• Confluent Cloud: local-account MFA is FIDO2 only.
• HubSpot: Super Admins can set passkeys as the allowed login method with an enforcement date.
• Rippling: authentication policies can require MFA per group or employee, and Rippling's own example is requiring YubiKeys for admins.
• ServiceNow: a FIDO2 MFA factor policy targeted by role or group suppresses other factors.
• Snowflake: an authentication policy can restrict MFA to passkeys.

Even identity and security vendors' own consoles are uneven. Of the 11 apps from vendors with an SWI profile, 9 support a phishing-resistant factor and 3 let admins require it (Okta, Microsoft Entra, Duo). Bitwarden, 1Password and Cloudflare document keys but no way to require them, and Auth0, LastPass and Palo Alto Networks Strata Cloud Manager do not document enforcement.

Finding 3: one app in five offers only phishable MFA

21 of 95 apps (22.1%) document their local MFA and it includes neither passkeys nor security keys: TOTP authenticator apps, SMS or email codes only.

The phishable-only group includes Figma, Zendesk, monday.com, Airtable, Calendly, Intercom, Pipedrive, Mailchimp, Webflow, Netlify, DigitalOcean, Supabase's dashboard, Xero and LinkedIn Sales Navigator. Four more apps, Gong, Outreach, Smartsheet and the Twingate admin console, have no local MFA at all and rely on the identity provider. Data platforms score highest: Snowflake, Databricks, Confluent, MongoDB Atlas, Elastic, Tableau and dbt all document a FIDO2 option, and Snowflake customer tenants were the target of the 2024 credential campaign, where stolen passwords worked on accounts without MFA. DevOps tools document least: 10 of 16 leave at least one factor field undocumented.

Finding 4: six in ten apps charge more for SSO

The denominator is the 82 apps that offer SSO and document which plan includes it. We excluded 9 apps that sell by quote and tie SSO to no plan (BambooHR, Deel, Jamf Pro, Kandji, NetSuite, Outreach, Rippling, Strata Cloud Manager, Workday) and 4 with no SSO at all (JetBrains Account, npm, PyPI, Xero). Counting them as "no tax" or "taxed" would only add assumptions.

Enterprise-only SSO includes GitHub, Asana, Linear, Loom, Lucid, monday.com, Netlify, Webflow, Smartsheet, ClickUp, Coda, dbt Cloud, CircleCI, Docusign and Bitwarden. The add-on group is Atlassian (Atlassian Guard Standard, which covers Jira, Confluence, Trello and Bitbucket and is included in Atlassian Cloud Enterprise), Calendly, Postman and Vercel. Collaboration (8 of 8) and design and marketing (5 of 5) tax SSO in every app we checked; infrastructure and data platforms mostly do not (Snowflake, Databricks, Confluent, MongoDB Atlas, AWS, Google Cloud, Azure, Cloudflare, Datadog and GitLab include SSO on every paid plan).

Protocol support is lopsided. SAML is offered by 83 of 95 apps (87.4%) and OpenID Connect by 30 (31.6%); 25 offer both, 58 SAML only and 5 OIDC only (1Password, LastPass, DigitalOcean, Mailchimp and the Tailscale admin console). Seven apps name no SSO protocol, though BILL and QuickBooks Online offer SSO without naming one. If your identity provider is OIDC-first, plan on SAML 2.0 for most of the SaaS estate.

Finding 5: where phishing resistance costs a plan upgrade

Combine Findings 1 and 4. Of the 71 apps with a documented SSO plan that do not let an admin require phishing-resistant MFA locally, 48 (67.6%) put SSO behind a higher tier, an enterprise plan or an add-on, and 20 of the 71 (28.2%) on an enterprise plan. In those apps the only way to make passkeys or security keys mandatory is to buy the plan that includes SSO and enforce at the identity provider. Of the 11 apps that enforce locally and document an SSO plan, just one (HubSpot) also taxes SSO.

So the SSO tax is not just a convenience fee. For two in three apps that cannot enforce on their own, it is the price of phishing-resistant MFA. A Slack workspace below Business+, a Notion workspace below Business, a Figma team below Organization or a GitHub organization below Enterprise cannot require phishing-resistant sign-in for that app at all, by local setting or by SSO, without upgrading. The TCO calculator is a reasonable place to put that cost next to the rest of the identity budget.

Across all 95 apps, 77 (81.1%) offer SSO but have no local setting that requires phishing-resistant MFA. For those, the identity provider is the only enforcement point.

Finding 6: requiring SSO can switch off the app's own passkeys

In 9 of the 51 apps that support passkeys or security keys (17.6%), turning on required SSO disables the app's local passkeys or local MFA: Notion, Dropbox, Box, Docusign, HubSpot, BambooHR, Brex, Bitwarden and Databricks. That is reasonable design, since one strong login is better than two, but it has a consequence teams miss. Once SSO is mandatory, the phishing resistance you saw in the app's settings is gone, and the account is exactly as strong as the identity provider's policy for that app. If the IdP still allows push or TOTP, so does the app.

The reverse also happens. Some apps keep a door open next to SSO: HCP Terraform owners can bypass SSO, Linear's top role can still log in by any method, 1Password Owners still sign in with their account password and Secret Key, Grafana Cloud exempts social-login users from enforced MFA, and Coda's 2FA covers only email and password logins. The notes for 12 apps document a setting that makes SSO the only way in (among them Intercom, Expensify, Mailchimp, Webflow, Kandji, Ramp, Shopify Plus and Stripe). These are the break-glass and bypass paths to inventory.

Finding 7: SCIM is common, but often on a pricier plan than SSO

Of the 66 apps that document their SCIM status, 60 (90.9%) offer it and 17 (25.8%) only on an enterprise plan. Seven of those 17 sell SSO on a lower plan than SCIM: Notion, Miro, Docker Hub, Postman, Vercel, Calendly and the Cloudflare dashboard (SSO free, SCIM Enterprise). Microsoft 365 counts as SCIM "yes": inbound provisioning needs Entra ID P1, which Microsoft 365 Business Premium includes. Buying SSO without SCIM leaves deprovisioning to a manual step, which is where offboarding fails (see where SCIM provisioning breaks). Six apps document no SCIM at all: Google Workspace (IdPs provision through Google's own APIs instead), Zendesk (which points to its user API), Pipedrive, npm, PyPI and Xero.

Finding 8: a third of vendors do not document their own MFA

35 of 95 apps (36.8%) leave at least one of passkey support, security key support or enforcement undetermined from public documentation, and 11 leave all three: ADP Workforce Now, Asana, BILL, Deel, Jamf Pro, Miro, PagerDuty, Strata Cloud Manager, Twilio Console, Workday and Zoom. Across the five classified fields, 105 of 475 cells (22.1%) are "not documented".

We separate two causes. In 8 of the 35 apps, the help center rendered only with JavaScript, returned HTTP 403 or sat behind a login (Asana, BILL, ClickUp, Deel, Docusign, Miro, Workday and Zoom). That is partly our tooling limit, and the information may be on a page a signed-in admin can see. In the other 27, the vendor's readable documentation is silent. Either way, a buyer cannot verify the vendor's MFA options before signing, which makes "not documented" a vendor-risk finding in its own right. Ask for it in the security questionnaire, in writing, and record the answer.

Vendor-documented facts that contradict common belief

Each item links to the app's row in the matrix, where the vendor source sits.

• GitHub's "secure methods" include TOTP. Org owners can turn on "Only allow secure two-factor methods", but GitHub counts authenticator apps and GitHub Mobile as secure alongside passkeys and security keys, so admins cannot require phishing-resistant methods only. SAML and SCIM need GitHub Enterprise. Row.
• AWS IAM cannot require an MFA type. IAM users can register passkeys or FIDO security keys, but the policy conditions aws:MultiFactorAuthPresent and aws:MultiFactorAuthAge test only that MFA happened and when. AWS IAM Identity Center, at no additional charge, can allow only security keys and built-in authenticators. Row.
• Confluent Cloud's local MFA is FIDO2 only. When an OrganizationAdmin requires MFA, every local user must use a security key, biometric authenticator or passkey. Google and GitHub sign-in and SSO users sit outside that MFA. Row.
• npm turned off new TOTP. Since October 2025, new 2FA setups on npmjs.com must use WebAuthn or passkeys. Existing TOTP still works, org owners cannot restrict methods, and npm organizations have no SSO. Row.
• Snowflake can be passkey-only. An authentication policy with MFA_POLICY = (ALLOWED_METHODS = ('PASSKEY')) restricts sign-in to passkeys, and Snowflake's phased removal of single-factor passwords ran from September 2025 to October 2026. Row.
• Salesforce includes SSO in all editions. Help docs list SAML federated authentication and SCIM as available in all editions. Salesforce enforced phishing-resistant MFA for privileged users from July to September 2026, but other users can still choose Salesforce Authenticator or TOTP. Row.
• HubSpot passkeys work on every tier, and admins can require them. Super Admins can set passkeys as the allowed login method with an enforcement date, while SAML SSO needs Professional or Enterprise. Row.
• Slack has passkeys but no security keys. Passkey sign-in reached Free, Pro and Business+ workspaces in September 2026, Slack says it does not support U2F, and owners can require 2FA and block SMS but cannot require passkeys. Row.
• Figma has no security keys or passkeys. Its own 2FA is SMS or authenticator apps, and requiring 2FA org-wide needs the Governance+ add-on, which is Enterprise-only. Row.
• Notion supports security keys but owners cannot enforce passkeys, and passkeys turn off when the organization requires IdP login. Row.
• Microsoft 365 enforcement is not in every plan. Passkeys are in all Entra ID editions including Free, but requiring them needs Conditional Access, which needs Entra ID P1 (in Business Premium and E3/E5, not Business Basic or Standard). Microsoft Authenticator can hold device-bound passkeys. Row.

What to do: the SSO-first route to phishing resistance

Phishing-resistant MFA means WebAuthn/FIDO2 passkeys and security keys, or PKI-based authentication. CISA calls it the gold standard and rates authenticator codes and push as phishable, and OMB M-22-09 requires it for US federal agency staff. The matrix shows that you cannot get there app by app for most of a SaaS estate. You get there through the identity provider.

1. Enforce at the IdP first. Require passkeys or FIDO2 security keys in the identity provider's sign-in policy for every SaaS app it fronts, using an authentication strength or app policy rather than "MFA required". The passkey rollout checklist covers enrollment, recovery and the help desk, and the phishing-resistant MFA rankings compare the vendors.
2. Put every app behind SSO and make SSO mandatory. Use the matrix to list apps where SSO sits on a higher plan and budget for it. Where an app can enforce locally (the 12 in Finding 2), turn that on for any accounts SSO does not cover.
3. Close local-login bypasses. Inventory owner and admin accounts that keep a password, social sign-in that skips SSO, and break-glass accounts. Give break-glass accounts security keys stored offline, alert on every use, and review them quarterly. Recheck apps where requiring SSO turns off local passkeys (Finding 6), because the IdP policy now does all the work.
4. Provision and deprovision with SCIM. SSO stops a leaver from signing in through the IdP, but only SCIM removes the app account, its sessions and API tokens. Where SCIM is enterprise-only, put that in the purchase decision.
5. Use local phishing-resistant MFA where there is no SSO. For npm, PyPI, Xero and other apps with no SSO, require security keys by policy and check enrollment by audit, since most of them cannot enforce it.
6. Do not treat MFA as the whole fix. The Identity Breach Report 2026 found MFA bypassed in 25 of the 40 breaches where MFA status was known, through phishing, push spam, help desk resets, OAuth consent and stolen sessions. Phishing-resistant factors stop the first two. Session binding, consent controls and help desk verification handle the rest. The Identity Breach Database has the incidents.

About the data

• Dataset: the Phishing-Resistant MFA Support Matrix, 95 apps, downloadable as CSV and JSON (below). Every row carries the vendor documentation and pricing URLs behind it and a verified_on date. Each app has a stable anchor in the matrix (/tools/mfa-matrix/#<slug>).
• Reproduce it: node scripts/reports/mfa-matrix-report.mjs in the site repository prints every figure in this report with its denominator. scripts/verify-mfa-matrix.mjs validates the records and writes the downloads.
• Re-checks: plan names and MFA options change often. We plan to re-verify the matrix quarterly and date every change.
• License and citation: CC BY 4.0. Cite as "Start with Identity, Phishing-Resistant MFA Support Matrix 2026" with a link to this page. Each key finding has a stable anchor (for example #finding-4).
• Corrections: if you are a vendor and a cell is wrong or out of date, or you have published documentation we missed, tell us through the contact page with a link to the public page. We update from public documentation only, re-run the numbers and date the change.