As part of Salesforce's effort to implement additional security, Salesforce is going to be enforcing the use of phishing resistant MFA for System Administrators and Users with the Modify All Data, View All Data, Customize Application, or Author Apex permissions. The reason why Salesforce is enforcing this change is to close security gaps and prevent anyone other than the Users themselves from accessing Salesforce with their login. 

This change will be enforced by Salesforce over a one month period starting on July 1st. This new level of authentication will be enforced for both direct UI logins and SSO logins in both Production and Sandbox. This change will not impact any Users who do not have any of these elevated permissions.

MFA vs. Phishing-Resistant MFA

An important distinction to keep in mind is that traditional MFA methods such as temporary one-time passcodes (TOTP) or an authenticator app do not satisfy the requirements for phishing-resistant MFA. While these traditional MFA methods seem secure, they are able to be reused or accessed by malicious actors. This is where phishing-resistant MFA methods are different. These methods are typically tied to the domain that triggered the authentication, do not have an OTP or push notification that can be stolen, and phishing sites can't trigger authentication.

Some common phishing-resistant MFA methods include WebAuthn Security Keys, Built-In Authenticators (including Touch ID/Windows Hello), Admin-Generated Temporary Verification Codes, and Passkeys from a Password Vault or other passkey generation tool. We recommend speaking with your IT Consultant or internal IT representative for recommendations on methods to use, what methods may already be available within your firm, and how to best implement them for usage with systems like Salesforce.

Authentication Strength & Evaluation Logic

When logging into Salesforce, either through a direct login or via SSO, the authentication is tracked and categorized into three tiers. These are: Phishing-Resistant MFA, Standard MFA, or Weak MFA/No MFA. This classification will depend on whether you login directly or login via SSO.

Before Enforcement: How to Prepare

Salesforce has provided the following guidance on the steps to take prior to this change.

1. Audit Users Impacted by the Change: 

   • Identify all users who are assigned the System Administrator profile or any of the following permissions: Modify All Data, View All Data, Customize Application, or Author Apex. You can use Salesforce Reports, User List Views, SOQL, or the User Access and Permissions Assistant.

   • 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 - ensure Security Keys and/or Built-In Authenticators are enabled in your Org. 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 or other privileged users. 

   • [Recommended] Activate Passkey login: For faster logins, allow passwordless login with passkeys. Users can satisfy the phishing-resistant MFA requirement by logging in with just their username and their passkey (built-in authenticator or security key). In your Identity Verification settings, toggle on "Allow passwordless login with passkeys." See Passwordless login using Passkeys.

3. Configure SSO for MFA Compliance: You have two primary paths for SSO: either update your Identity Provider (IdP) to require phishing-resistant 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.

   • Confirm OIDC AMR signals by reviewing Login History.

   • 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.

4. Test your Phishing-Resistant MFA implementation: In your test environment, enable MFA to ensure you can successfully enroll and use phishing-resistant MFA to login. See Test your MFA implementation.

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

After Enforcement: Resolve Errors

• SSO Signal Issues: If your SSO provider is using phishing-resistant MFA, but doesn't send corresponding signals, users 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.

• Privileged User Lockouts: If a privileged user 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, please submit a ticket to the Elements Support Team and we will escalate to Salesforce to help resolve.

How to Enable Phishing-Resistant MFA and Register an Authentication Method

The steps below will walk through how to pre-enable phishing-resistant MFA as an authentication option and register an MFA method

Enabling Phishing-Resistant MFA

1. While logged into Elements, click the Setup gear in the top right-hand corner and click Setup
2. In the Quick Find on the left-hand side, type in Identity Verification and click on Identity Verification on the left-hand side
3. Once on the Identify Verification page, check the checkboxes next to Let users verify their identity with a physical security key (U2F or WebAuthn) and Let users verify their identity with a built-in authenticator such as Touch ID or Windows Hello. Once you've checked these boxes, scroll down and click Save.

Registering Phishing-Resistant MFA

There are a few options for registering a phishing-resistant MFA method. 

1. Built-In Authentication: For a built-in authentication method, you're able to use Touch ID, Face ID, or Windows Hello on devices that support any of these methods. Please keep in mind that these methods are strictly for whichever device you register that method on. This article provides additional information about supported methods and how to register them when prompted or through your User settings.
2. Security Key: For this authentication method, security keys in the form of U2F or WebAuthn keys may be used. Additionally, if you have a password vault such as LastPass, Zoho Vault, or Okta, they will oftentimes support passkeys for the purposes of secure authentication into platforms such as Salesforce. This article provides additional information about supported methods and how to register them when prompted or through your User settings.