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. Confirm OIDC AMR signals by reviewing Login History.

   2. As SAML ACR values are not yet recorded in Login History (planned for a future release), use a third-party SAML tracer to inspect responses. Note that while the Salesforce SAML Validator assesses AMR/ACR claims, it currently only classifies them as "strong" or "weak" and has not yet been updated to reflect the specific "weak," "standard," and "phishing-resistant" authentication signal strength tiers definitions introduced by this change.

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. Contact Salesforce Support: If an admin is locked out and no other admins are available, contact Salesforce Support for a one-time login code. 

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 Security keys. Users who choose security keys as their MFA option will be blocked from logging in and it is required that their organization pre-configures advanced authentication in the My Domain settings and they use the my domain as their login server. This applies to all the Salesforce internal and third party apps using Mobile SDK. Additionally, Salesforce Mobile App users 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?

“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. Experience Cloud and Community users are not subject to the same MFA login mandate. 

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?

Salesforce categorizes SSO MFA strength into three distinct tiers:

• Phishing-Resistant MFA: cert, fido, fido2, fpt, hwk, iris, pin, pki, pop, retina, sc, Smartcard, swk, TLSClient, user, vbm, wia, X509

• Standard MFA: Face, mobiletwofactorcontract, multipleauthn, okta_verify, passkey, webauthn

• Weak / No MFA (default): pwd, sms, tel, email

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). If an Admin is locked out and no other administrators are available, contact Salesforce Support for a one-time login code..

Change Log