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: The PermissionsBypassMFAForUiLogins API field name for the "Waive Multi-Factor Authentication for Exempt Users" user permission is removed from the PermissionSet and Profile object schema, unless you have reached out to Salesforce Support for an extension to continue using it for valid exempt reasons. When removed, referencing this field by API name will cause compilation errors that block package installs or upgrades. Customers and partners must audit their code and metadata and remove all references to this field.

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 

How does the phishing-resistant MFA mandate affect Partner Admin shared logins, and what are my compliance options?

Partner Admin Shared Logins must use phishing-resistant MFA, a requirement you can satisfy by using a FIDO2/WebAuthn-compliant password manager (like 1Password or Bitwarden) to store and share Passkeys. If your current tools do not support these standards, you may either upgrade to a password management tool that does support Passkeys or, where feasible, switch to individual user licenses so each administrator can register their own personal Passkeys or hardware security keys.

I have a temporary extension applied for my org. Why are my users still being prompted for MFA and seeing the "Create a Passkey" screen on login?

Having a temporary extension granted does not automatically stop the MFA "Create a Passkey" prompts. The MFA For All Employees Extension extension gives your org admin the ability to disable platform-enforced MFA, but the following must be true to suppress MFA prompts:

1. The appropriate extension(s) are active:
   1. MFA For All Employees Extension, for non-privileged users. Privileged users are still required to use PRMFA.
   2. MFA For All Employees Extension and Phishing Resistant MFA (Passkeys) Extension, for all users
2. The org admin has disabled the "Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org" setting in Setup → Identity Verification

If users are still being challenged after completing both steps above, check whether the Multi-Factor Authentication for User Interface Logins user permission is assigned. Remove it from the profile or permission set assignment to stop the MFA prompts.

If the above conditions are not met, users may continue to be prompted for MFA to "Create a Passkey" regardless of the extension. For a full breakdown of all extension combinations and their expected behavior, see: MFA and PRMFA Post-Enforcement: Passkey Prompts & Extension Behavior

Can we use the SAML Assertion Validator to check whether our SSO signals meet phishing-resistant MFA requirements?

Yes. the SAML Assertion Validator now classifies each AMR/ACR signal as phishing-resistant, standard, or weak — replacing the previous two-tier model (strong/weak). You can use it to directly confirm whether your IdP's signals satisfy the MFA requirement for standard users or the stricter phishing-resistant MFA requirement for privileged users.

For full details, see the Summer '26 release note: View Phishing-Resistant, Standard, and Weak MFA Methods in the SAML Assertion Validator

Can I see the authentication method and context my SSO identity provider is sending to Salesforce?

Yes. Salesforce provides two fields in Login History to help you understand how your SSO identity provider is authenticating users:

• Authentication Method Reference (AMR) — available since Spring '21, this shows the authentication methods used during login (for example, password, MFA, hardware key). See the Spring '21 Release Note for details.

• Authentication Context Class Reference (ACR) — new in Summer '26, this shows the authentication context class sent by your identity provider, indicating the overall strength of the authentication method used. See the Summer '26 Release Note for details.

Together, these fields help you determine whether your identity provider is sending strong or weak authentication signals — which is critical for understanding whether your SSO logins will satisfy MFA enforcement requirements. To view them, go to Login History in Setup and add the relevant columns to your view. Both values are also available in Event Monitoring via the LoginEvent and LoginEventStream objects.

Will users need to verify their identity before adding a new MFA method?

Change Log

Release Group Instance Mapping

Note: Release Group mapping is subject to change.

To learn how to identify your instance, see View Instance Information for Your Salesforce Organization. 

Once you have determined the release group for your instance, find your detailed rollout timeline in the Release Group Enforcement Schedule mentioned above.