Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins

Common Questions

What forms of phishing-resistant MFA does Salesforce support?

Salesforce supports the following phishing-resistant MFA methods:

FIDO2/WebAuthn Authenticators

• Built-in Authenticators: Device-bound passkeys that use the device's secure hardware protected by a PIN or biometric. Examples include:

  • Windows Hello for Business: Uses the device's Trusted Platform Module (TPM) chip with a PIN or biometric; keys are tied to the device and cannot be exported.

  • Apple Passkeys (Touch ID / Face ID): Built into the Apple ecosystem (iPhone, Mac, iPad); keys can be kept device-bound or synced via iCloud Keychain.

  • Android/Google Passkeys: Uses the device's secure enclave and biometrics

• Security Keys: External FIDO2/WebAuthn security keys (e.g., YubiKey), including those that connect via USB, NFC, or Bluetooth.

• Cloud-Synced Passkeys: Passkeys managed through a password manager or cloud keychain (e.g., 1Password, Bitwarden, iCloud Keychain). While not device-bound, they are FIDO2-compliant and meet the phishing-resistant MFA requirement, provided the password manager is FIDO2/WebAuthn-compliant.

Certificate-Based Authentication (CBA)

Certificate-Based Authentication uses x.509 client certificates to verify a user's identity. A corporate certificate is installed on the user's device, and mutual TLS (mTLS) is used to authenticate with Salesforce. The certificate's private key is protected in secure hardware such as a TPM (Trusted Platform Module) or secure enclave, making it resistant to phishing and credential theft. See Certificate-Based Authentication for configuration details.

How are API logins affected?

This change targets UI-based employee logins only

How are logins via the Salesforce mobile app on Salesforce Mobile SDK logins affected?

1. “Login for Admins” button: In Mobile SDK version 13.2.0 and earlier, the default Mobile SDK authentication mode (WebView) cannot support phishing-resistant MFA. Admin users on this version will be blocked from logging in unless their organization pre-configures advanced authentication in the My Domain settings and uses the my domain as their login server. If advanced authentication is not configured, admins can use a new “Login for Admin” menu item that will be added in May 2026 with the release of Mobile SDK 13.2.1. This button forces advanced, browser-based authentication, which enables phishing-resistant MFA automatically. This applies to all the Salesforce internal and third party apps using Mobile SDK. Additionally, Salesforce Mobile App admins can use the "Login with Email" option.
2. Login UX Change for all users: Accompanying the phishing-resistant MFA requirement, Salesforce is changing the login flow so that it displays the username field first, then the password or passkey field after the user clicks Log In. This change works with existing Mobile SDK apps, which means it does not require code changes. However, the two-step flow requires updates to existing automated tests that are configured to handle the previous flow.
   
   

How do I check if the change has taken effect for my org or instance?

Privileged users using Salesforce MFA will only be permitted to use security keys and built-in authenticators. They will no longer be allowed to use the Salesforce Authenticator or Third Party Authenticator Apps (TOTP) to complete required MFA.

If using SSO to login, privileged users will see prompts to enroll and use Salesforce MFA if their SSO provider does not pass the required AMR or ACR signals that confirm phishing-resistant MFA was used. 

Who is considered a "privileged user" for the phishing-resistant MFA requirement?

A privileged user is any user with the System Administrator profile or any user granted one of the following permissions (including via permission sets): Modify All Data, View All Data, Customize Application, or Author Apex. 

Can privileged users use TOTP apps as a valid MFA method?
No. Mobile TOTP applications, including Salesforce Authenticator, do not meet the new phishing-resistant MFA requirement for privileged users including Admins. While these tools are classified as standard MFA, they remain susceptible to phishing. Privileged users facing technical or organizational barriers to adopting phishing-resistant hardware or biometrics should contact Salesforce Support or their account representative for guidance.

Does the phishing-resistant MFA requirement apply to privileged user SSO logins too, or only direct username/password logins?

It applies to both. Privileged users logging in via SSO must have their IdP send a recognized phishing-resistant MFA ACR/AMR signal. If no such signal is received, privileged users will be prompted to enroll in Salesforce phishing-resistant MFA. Prior to enforcement, users will see an in-app prompt to complete enrollment. 

Does enabling phishing-resistant MFA change the enrollment process for all users or just privileged users?

Upon enforcement of this change, any user prompted to set up a new MFA method will be directed to enroll a Passkey, such as a Security Key or Built-in Authenticator, to ensure phishing-resistant protection. For individuals who are not mandated to use a phishing-resistant MFA option, the option to select a third-party authenticator app will remain available.

Which phishing-resistant MFA signal values are recognized by Salesforce from an SSO provider?

For the list of accepted values, see the table in the above section titled: Authentication Strength Tiers

If phishing-resistant MFA signals are detected, the user gains access immediately with no additional authentication requirements.

However, if standard MFA, or Weak MFA / No MFA signals are received then the user will then be prompted via the Salesforce UI to select a verification method and link it to their Salesforce account.

Can we still use the "Waive Multi-Factor Authentication for Exempt Users" permission?

After the enforcement date, this permission will no longer automatically waive MFA requirements. Users with this permission will be prompted to enroll and use MFA in the Salesforce UI. To restore the exemption for valid use cases (e.g., automated testing tools), you must contact Salesforce Support for approval.

What if the only Admin for an org gets locked out?

If an Admin is completely locked out and cannot provide a phishing-resistant MFA factor, another org Admin can generate a temporary identity verification code, disconnect old verification methods, and assist with re-registration. See Resolve MFA Access Issues for Your Users (Salesforce Orgs). If there are no other admins, they can contact Salesforce Support for assistance

Does passwordless login with passkeys count as phishing-resistant MFA?

Yes. Even without a password, passkeys (built-in authenticators and security keys) inherently use multiple factors for authentication.

After a sandbox refresh, how do admins regain access when SSO is disabled and MFA verifiers are lost?

When a Salesforce sandbox is refreshed from production, SAML SSO settings are partially carried over but automatically disabled in the sandbox because the Recipient URL is updated to match the new sandbox URL. As a result, users cannot log in via SSO immediately after a refresh, SAML settings must be reconfigured before SSO access is restored. For full details on what SSO settings are copied and what changes, see SSO (Single Sign-On) SAML Settings Behavior During Sandbox Refresh — What Is Copied and What Changes.

Additionally, MFA verifiers do not carry over after a sandbox refresh since verifiers are org-specific. Admins must log in directly to Salesforce and register a new phishing-resistant MFA verifier before they can reconfigure SSO.

Recommended steps after a sandbox refresh:

1. Log in directly to Salesforce with the account username and password, and enroll your Phishing-resistant MFA verifiers (security key or built-in authenticator)

2. Reconfigure and re-enable SAML SSO settings for the refreshed sandbox, including updating the Recipient URL

Note: Plan ahead before initiating a sandbox refresh by ensuring at least one admin has a compatible phishing-resistant verifier (e.g., a hardware security key) available for direct login, since SSO will be unavailable until SAML settings are reconfigured.

Does the Phishing-Resistant MFA requirement apply to Developer Edition, trial, scratch, or other non-paid orgs? 

No. The Phishing-Resistant MFA requirement is scoped to paid Production and Sandbox orgs only. Developer Edition orgs, trial orgs, scratch orgs, and other non-paid org types are not subject to enforcement.

Is there a SOQL query for auditing users with the "Waive Multi-Factor Authentication for Exempt Users" user permission?

Option 1: Query via PermissionSetAssignment (finds users with the permission through permission sets)                                                                 

  SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,             

         Assignee.IsActive, PermissionSet.Name                                     

  FROM PermissionSetAssignment                                                     

  WHERE PermissionSet.PermissionsBypassMFAForUILogins = true                       

Option 2: Query via Profile (finds profiles that have the permission enabled)

  SELECT Id, Name, PermissionsBypassMFAForUILogins                                 

  FROM Profile                                                                     

  WHERE PermissionsBypassMFAForUILogins = true                                     

Note:   Key API field name: PermissionsBypassMFAForUILogins corresponds to the user permission labeled "Waive Multi-Factor Authentication for Exempt Users" in the UI.

Is there a SOQL query for auditing users with Admin or privileged permissions for determining scope of user impact for PR-MFA?

Query for Users with the Standard System Administrator Profile

  SELECT Id, Name, Email, Profile.Name, IsActive

  FROM User

  WHERE Profile.Name = 'System Administrator'

Query for Users with the privileged User Permissions

  Core "Privileged User" Permissions for Phishing-Resistant MFA Enforcement:

  - PermissionsModifyAllData — Modify All Data

  - PermissionsViewAllData — View All Data

  - PermissionsCustomizeApplication — Customize Application

  - PermissionsAuthorApex — Author Apex

  Query for users with any of these permissions - Via Permission Sets

  SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,

         Assignee.IsActive, PermissionSet.Name

  FROM PermissionSetAssignment

  WHERE PermissionSet.PermissionsModifyAllData = true

     OR PermissionSet.PermissionsViewAllData = true

     OR PermissionSet.PermissionsCustomizeApplication = true

     OR PermissionSet.PermissionsAuthorApex = true

Query for users with any of these permissions - via Profiles

  SELECT Id, Name, Email, Profile.Name, IsActive

  FROM User

  WHERE Profile.PermissionsModifyAllData = true

     OR Profile.PermissionsViewAllData = true

     OR Profile.PermissionsCustomizeApplication = true

     OR Profile.PermissionsAuthorApex = true (edited) 

Change Log