How to Enforce Phishing-Resistant MFA Across Your SaaS Apps: An SSO-First Playbook

To enforce phishing-resistant MFA across a SaaS estate, enforce it at the identity provider and make SSO the only way into each app. Very few apps can do it on their own. In SWI's Phishing-Resistant MFA Support Matrix, 51 of 95 business SaaS apps (53.7%) support passkeys or security keys, but only 12 (12.6%) let an admin require them, and 77 of 95 (81.1%) offer SSO but have no local setting that requires phishing-resistant MFA (report). For those 77, the IdP's policy is the control. The steps below cover the policy, the bypasses that undo it, and the emergency accounts that must survive it.

Phishing-resistant MFA here means passkeys and FIDO2 security keys built on WebAuthn, or PKI-based authentication such as certificates. CISA's Implementing Phishing-Resistant MFA fact sheet treats FIDO/WebAuthn and PKI as phishing-resistant, and one-time codes and push notifications as phishable.

Step 1: Sort your apps into four buckets

Use the matrix to classify every app your company signs in to. Each row links to the vendor's own documentation.

The 12 that enforce locally are mostly identity platforms: Microsoft 365, the Azure portal and the Microsoft Entra admin center, Google Workspace and Google Cloud console, the Okta Admin Console and the Duo Admin Panel. Only five others document it: Confluent Cloud, HubSpot, Rippling, ServiceNow and Snowflake, whose authentication policy can set MFA_POLICY = (ALLOWED_METHODS = ('PASSKEY')) (finding 2).

Then mark which apps need a plan upgrade to get SSO. Of the 71 apps with a documented SSO plan that cannot enforce locally, 48 (67.6%) put SSO behind a higher tier, an enterprise plan or an add-on (finding 5). That is a budget line, and it is covered in the SSO tax explained.

Step 2: Require a phishing-resistant method in the IdP policy

"MFA required" is not enough. Most IdP defaults accept push, one-time codes or SMS as the second factor, and a phishing proxy or a code relayed by phone gets through those. The policy has to name the method.

Microsoft Entra ID: Conditional Access authentication strengths

Microsoft Entra Conditional Access offers three built-in authentication strengths: Multifactor authentication strength, Passwordless MFA strength and Phishing-resistant MFA strength. Per Microsoft's documentation, the built-in Phishing-resistant MFA strength allows Windows Hello for Business or platform credential, FIDO2 security keys and Entra certificate-based authentication (multifactor). You apply it with the Require authentication strength grant control in a Conditional Access policy. Microsoft publishes a template policy that requires it for administrator roles, which is the right first target.

Licensing matters. The matrix row for Microsoft 365 notes that passkeys work in all Entra ID editions including Free, but requiring them needs Conditional Access, which needs Entra ID P1 (included in Microsoft 365 Business Premium and E3/E5, not Business Basic or Standard).

A practical order: admins first, then help desk staff and anyone who can approve OAuth apps, then the enterprise applications that hold customer or financial data, then all users. Run each policy in report-only mode before switching it on. The conditional access policies guide covers policy design.

Okta: app sign-in policies with a phishing-resistant constraint

In Okta Identity Engine, each app's app sign-in policy is built from rules. Okta's documentation describes a possession factor constraint called Phishing-resistant, which requires possession factors that cryptographically verify the sign-in origin, and states that passkeys (FIDO2 WebAuthn) and Okta FastPass in Okta Verify satisfy it. The same page notes the trap: a new app sign-in policy starts with a single catch-all rule that allows access with any two factor types. Add the phishing-resistant rule, scope it to the groups you are rolling out, and place it above the catch-all. Then tighten or remove the catch-all for that app once enrollment is complete.

Okta also offers a Hardware protection constraint, which requires keys stored in secure hardware on the device. Consider it for administrators if your policy does not accept synced passkeys for privileged roles.

Google Workspace: "Only security key"

When Google Workspace is your identity provider, or for Google sign-in itself, the 2-Step Verification deployment guide offers an enforcement method of Only security key. Google's help states that passkeys and security keys have the same level of phishing protection, and the matrix row for Google Workspace records that the option accepts both and that admins can limit passkeys to hardware security keys. Before you select it, Google advises finding users who have already set up keys, and setting a 2-Step Verification policy suspension grace period so admins can issue backup codes when someone loses a key. Apply it by organizational unit, starting with super admins.

Step 3: Plan enrollment and recovery before enforcement

Enforcement fails on the day people cannot sign in. Issue at least two authenticators to every administrator (a security key such as a Yubico YubiKey plus a platform passkey), decide whether synced passkeys are acceptable for general staff, and write the recovery path down. Recovery is where attackers go next: a help desk that resets MFA on a caller's word defeats any factor. See help desk social engineering, account recovery and the passkey rollout checklist. The enterprise passkeys guide covers enrollment at scale.

Step 4: Make SSO mandatory in every app

Configuring SSO is not the same as requiring it. If an app still accepts a local password, the IdP policy protects only the users who choose the SSO button. In each app, turn on the setting that makes SSO the only sign-in method. The matrix notes record such a setting for 12 apps, among them Intercom, Expensify ("Require SAML login"), Mailchimp, Webflow, Kandji, Ramp, Shopify Plus (SAML set to Required) and Stripe (finding 6).

Step 5: Close the local-login bypasses

Some apps keep a door open next to SSO even when it is required. From the matrix notes:

• HCP Terraform: organization owners can bypass SSO.
• Linear: admins can require login methods, but the top role can still log in by any method.
• 1Password (row): SSO sign-in is OIDC only, and Owners still sign in with their account password and Secret Key.
• Grafana Cloud: Cloud Portal MFA is TOTP only, and social-login users are exempt from enforced MFA.
• Coda: 2FA applies only to email and password logins, while Google, Microsoft, Apple and magic-link sign-in are also offered; Enterprise admins can turn the other options off.

For every app, list the accounts that can sign in without the IdP: owners, the original admin who created the tenant, social sign-in, magic links, API-created local users and contractor accounts. Turn off what you can. For what you cannot, give the account a security key where the app supports one, store it offline, and review the list quarterly. Watch for the shared account that four people use with one TOTP seed.

Step 6: Recheck apps where SSO turns off local passkeys

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: Notion, Dropbox, Box, Docusign, HubSpot, BambooHR, Brex, Bitwarden and Databricks (finding 6). That is reasonable design, since one strong login beats two, but the passkeys you saw in the app's settings are gone once SSO is mandatory. If the IdP policy for that app still allows push or TOTP, so does the app. Confirm that each of these nine apps is covered by the phishing-resistant rule from Step 2, not by a catch-all.

Step 7: Keep break-glass accounts, and protect them properly

Every enforcement policy needs an exit for the day the IdP, the federation trust or the policy itself breaks. Microsoft's emergency access guidance is a good model for any IdP:

• Keep at least two emergency access accounts.
• Make them cloud-only (in Entra, on the *.onmicrosoft.com domain), not federated or synchronized from on-premises.
• Protect them with phishing-resistant methods, FIDO2 security keys or certificate-based authentication, different from the ones your normal admin accounts use.
• Exclude them from Conditional Access policies that block or restrict sign-in, because the strong method protects the account and a blocking policy could lock you out in the exact emergency. Report-only policies need no exclusion.
• Store credentials in separate, secure locations, monitor every sign-in with alerts, and validate the accounts at least every 90 days.

Do the same for SaaS apps whose SSO setting would lock every admin out if the IdP fails: one local owner account per critical app, a security key held offline, an alert on every use. The break-glass glossary entry covers the pattern.

Step 8: Provision with SCIM

SSO stops a leaver from signing in through the IdP. Only SCIM removes the app account, its sessions and its API tokens. In the matrix, 60 of the 66 apps that document their SCIM status (90.9%) offer it, but 17 (25.8%) only on an enterprise plan (finding 7). Include SCIM in the same purchase as SSO and follow the SCIM provisioning implementation guide.

Step 9: Handle the apps with no SSO

For npm, PyPI, Xero and JetBrains Account, there is no IdP to enforce through. npm is the closest to the goal: since October 2025 new 2FA setups must use WebAuthn or passkeys, though existing TOTP still works and org owners cannot restrict methods. PyPI has required 2FA for all accounts since 2024, with a FIDO/WebAuthn security device or a TOTP app. Xero's mandatory MFA uses Xero Verify push or a TOTP app. Require security keys by written policy where the app supports them, check enrollment by audit, and for package registries prefer trusted publishing over long-lived tokens.

Step 10: Verify, then remember what MFA does not cover

Check the IdP sign-in logs for each app and confirm the authentication method recorded is a passkey, security key, platform credential or certificate. Anything else means a rule is still letting a weaker factor through.

Then close the gaps phishing-resistant MFA cannot reach. SWI's 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 phishing and push routes. They do not stop a stolen session cookie or an OAuth consent grant, which never trigger an MFA prompt. Those need bound, short-lived sessions, consent controls and help desk verification, covered in third-party SaaS token breaches.

For tooling, the best phishing-resistant MFA ranking compares vendors, and the MFA buyer guide covers the decision. The full findings are in the Phishing-Resistant MFA Support Matrix 2026 report.