Prepare for MFA Enforcement for All Employee Users

Before Enforcement: How to Prepare

1. Audit MFA Configurations and Users: 

   1. Verify the “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” setting status, and identify users with direct MFA permissions (via Profiles/Permission Sets). 

   2. Identify all users assigned the "Waive Multi-Factor Authentication for Exempt Users" permission. Because the effect of this permission will be disabled when the change is enforced, you must contact Salesforce Support to retain the exemption for valid use cases (e.g., automated testing tools).

2. Set Up Org Verification Options: Define the allowed MFA methods for your users and establish how they choose a method during initial registration.

   1. Note: Salesforce requires Privileged Users including Admins users to use phishing-resistant MFA, which means that you must enable built-in authenticators or security keys. Once you enable these methods in Setup, they will be available for all org users. There is no ability to restrict their use to only admins. 

   2. [Recommended] Activate Passkeys: Enable faster, phishing-resistant logins by toggling on "Allow passwordless login with passkeys" in Identity Verification settings. Users can fulfill this requirement by logging in with just their username and a passkey, such as a built-in authenticator or security key. See Passwordless login using Passkeys.

3. Establish Access Recovery Procedures: Define internal processes for Admins to resolve login issues (e.g., generating temporary identity verification codes) to prevent reliance on Salesforce Support for routine resets. See Resolve MFA Access Issues for Your Users.

4. Configure SSO for MFA Compliance: You have two primary paths for SSO: either update your Identity Provider (IdP) to require standard MFA authentication and transmit the necessary AMR/ACR signals, or you may enable Salesforce MFA for your SSO logins. If leveraging your IdP’s MFA service, confirm that the ID token (for OpenID Connect) or the SAML response includes the required AMR/ACR signals.

   1. Check via the Authentication Method Reference (AMR) field and Authentication Context Class Reference (ACR) field in LoginHistory.

   2. Use the Salesforce SAML Validator tool, or a third-party SAML tracer to inspect responses.

5. Pre-Register Users: Proactively communicate the timeline to your users and encourage them to register their MFA methods before the enforcement date to avoid login disruptions.  See Register an identity verification method

6. Test Your MFA Implementation: Enable MFA in a sandbox first to validate your configuration, and the user registration flow before the changes reach production. See Test Your MFA Implementation for Salesforce Orgs.

After Enforcement: Resolve Errors

The steps below resolve errors caused by the change.

1. Identify Blocked Users: Monitor login history for users unable to enroll in Salesforce MFA or complete their MFA challenge. Utilize your MFA Support & Access Recovery Procedures (e.g., for locked-out users, Admins can generate a one-time login code), and reference the Common Multi-Factor Authentication (MFA) Troubleshooting for additional help

2. SSO Signal Issues: If your SSO provider is using phishing-resistant MFA or standard MFA authentication, but doesn't pass required signals, you will be required to enroll in Salesforce MFA. To prevent prompts within Salesforce, coordinate with your SSO provider to ensure the ACR or AMR signals are correctly transmitted.

3. User Lockouts: if a user is locked out, a customer 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). 

Common Questions

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. In Mobile SDK version 13.2.0 and earlier, the default Mobile SDK authentication mode (WebView) cannot support Phishing resistant MFA mechanisms such as Passkeys or hardware security keys (e.g., YubiKey). Users on versions prior to 13.2.0 who choose Passkeys (or another phishing resistant mechanism) as their MFA option 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. Alternatively, advanced authentication can be configured using MDM. For some Android apps that don’t have an intent filter configured, the Login for Admin button doesn’t automatically enable advanced authentication. To add an intent filter, follow the steps in Configuring Advanced Authentication in Android apps. To configure a custom domain in the mobile app, tap the settings menu (gear icon) before logging in, select "Change Server", and enter your custom login host URL.
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?

“Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” is active and greyed out. 

Does MFA now apply to sandbox orgs, not just production?

Yes. With these changes, Salesforce is requiring MFA for all employee (internal) users logging into both production and sandbox orgs. This is a change from prior MFA requirements, which excluded sandboxes. 

Does MFA apply to Experience Cloud / Community users?

No. The MFA login requirement applies to employee (internal) users only. External users logging into Experience Cloud and Community users are not subject to the same MFA login mandate.

Note: that MFA is required for internal users (that is, anyone with a standard user license) who log in to your company's Employee Community or other Experience Cloud sites.

We already enforce MFA through our SSO provider (e.g., Okta, ADFS, Entra). Do we still need to configure Salesforce MFA?

SSO logins can satisfy the Salesforce MFA requirement — but only if your identity provider (IdP) sends valid AMR (Authentication Methods Reference) or ACR (Authentication Context Class Reference) signals proving MFA was used. By default, all SSO logins are treated as having no MFA until a recognized phishing-resistant MFA or standard MFA signal is received. If Salesforce cannot detect a valid signal from your IdP, users will be prompted to enroll in Salesforce MFA

Which 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 or standard MFA signals are detected, the user gains access immediately with no additional authentication requirements.

However, if Weak / 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 a user or admin gets locked out?

If a user is locked out, their 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).

Does the MFA for All Employees requirement apply to Developer Edition, trial, scratch, or other non-paid orgs? 

No. The MFA for All Employees 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.

I have an 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

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?

Yes. When MFA is enforced in your org, users who already have at least one MFA method registered must verify their identity before they can add a new one. Salesforce will prompt them to confirm using their most secure existing method (passkey, Salesforce Authenticator, or a TOTP app). Users with no MFA method on file will receive a one-time code via SMS or email instead. Note that this does not affect users registering an MFA method for the very first time. 

For full details, see the Summer ‘26 release note: Identity Verification Is Required to Register New MFA Verification Methods

Change Log