Most SaaS apps cannot locally mandate phishing-resistant MFA
A study of 95 SaaS apps reveals most cannot locally mandate passkeys, forcing firms to rely on identity providers and expensive enterprise plans.
Key figures
| Business SaaS apps analyzed | 95 |
|---|---|
| Apps supporting phishing-resistant tools | 53.7% |
| MFA bypasses in known breaches (2026 report) | 25 of 41 |
| Risk reduction of any MFA (Microsoft research) | 99.22% |
Only 12.6% of 95 business SaaS apps allow administrators to locally mandate phishing-resistant MFA, forcing organizations to rely on identity providers for enforcement [1].
The gap between the ability of an app to support secure authentication and an administrator's ability to require it leaves companies vulnerable to account takeover. Because most apps cannot enforce these standards locally, security teams must move the control point to the identity provider (IdP) and eliminate local login paths [1].
The SaaS Enforcement Gap
A report from Start with Identity analyzed 95 business SaaS applications to determine if admins could require phishing-resistant methods, such as passkeys or FIDO2 security keys [1]. While 53.7% of the analyzed apps support these tools, only 12.6% allow an administrator to mandate their use [1].
The data shows a disconnect between technical capability and administrative control. According to the report, 81.1% of the apps offer single sign-on (SSO) but lack any local setting to require phishing-resistant MFA [1]. In these cases, the security of the app depends entirely on the IdP's policy [1].
Of the few apps that allow local enforcement, most are identity platforms themselves, including Google Workspace, the Okta Admin Console, and the Microsoft Entra admin center [1]. Only five non-identity apps document this capability: Snowflake, ServiceNow, Rippling, HubSpot, and Confluent Cloud [1].
The High Stakes of Phishing-Resistant Authentication
The lack of local enforcement is critical because traditional MFA can be bypassed. SWI's Identity Breach Report 2026 found MFA bypassed in 25 of the 41 breaches where MFA status was known [1].
Phishing-resistant MFA, which includes FIDO2 WebAuthn and PKI certificates, is designed to block adversary-in-the-middle (AitM) attacks that steal session tokens or codes in real time [1][3]. Microsoft research indicates that while any MFA reduces account compromise risk by 99.22%, legacy methods like SMS and voice are susceptible to SIM-swap and phishing attacks [6][8].
According to a report by cyberpress.org, Microsoft cited phishing and SIM-swap attacks as reasons to move away from SMS and voice authentication [8].
The IdP Solution and SSO Conflict
To close the enforcement gap, organizations are urged to make SSO the only entry point for each app [1]. IdPs like Okta can then enforce phishing-resistant MFA through app sign-in policies using Okta Verify or FIDO2 WebAuthn [1].
However, mandating SSO can create technical friction. For 17.In 9 of the 51 apps that support passkeys or security keys (17.6%), requiring SSO disables the app's own passkeys or local MFA [1]. The Start with Identity report notes that disabling an app's local MFA in favor of SSO is a reasonable design since "one strong login beats two," but this means the app's security is only as strong as the IdP's specific rule [1].
If an IdP policy still allows phishable factors like push notifications or TOTP for a specific app, those vulnerabilities remain even if the app previously supported local passkeys [1].
Financial Barriers to Compliance
Financial costs often hinder the transition to phishing-resistant security. Among the 71 analyzed apps that cannot enforce secure MFA locally, 67.6% place SSO behind a higher-tier enterprise plan or a paid add-on [1].
This "SSO tax" limits the ability of smaller organizations to centralize and harden their authentication policies [1]. Similar pricing barriers exist for account lifecycle management; while 90.9% of apps documenting their SCIM status offer the service, 25.8% limit it to enterprise plans [1].
SSO stops a leaver from signing in through the IdP, but only SCIM removes the app account, its sessions and its API tokens [1].
What we don't know
- How many organizations have already migrated to customer-managed telecom providers to maintain telephony authentication after the Microsoft SMS retirement?
- What is the specific adoption rate of SCIM among the 66 apps that document its status?
Sources
- [1] How to Enforce Phishing-Resistant MFA Across Your SaaS Apps: An SSO-First Playbook — Start with Identity, Nov 5, 2026
- [3] Phishing prevention 101: Safeguarding your organization - Okta — okta.com, Nov 4, 2026
- [6] What should I do about security after introducing Microsoft 365? Introducing 12 settings｜中山健 セルバ/セルバコンサルティング代表 — note.com
- [8] Microsoft to Retire SMS and Voice MFA in Entra ID, Urges Users to Switch to Passkeys — cyberpress.org
Photos and video from the reports
- Video: An article by Start with Identity regarding the enforcement of phishing-resistant MFA across SaaS apps.
- Photo: A chart showing how adversary-in-the-middle attacks can bypass some MFA but are blocked by hardware keys.
- Photo: A hardware security key used for phishing-resistant authentication.
- Video: A video discussing how traditional MFA can be bypassed.
Further reading
- MFA security part 1: How attackers bypass multi-factor authentication
This guide explains common methods attackers use to bypass MFA, including policy gaps and social engineering.
