Preparing for Salesforce’s Mandatory MFA Changes in 2026

As credential theft and AI-powered phishing campaigns become increasingly sophisticated, Salesforce is raising the bar on its security standards. As a Salesforce Platform Owner, System Administrator or even a Consultant, Salesforce enforcing stricter Multi-Factor Authentication (MFA) requirements across all direct UI and Single Sign-On (SSO) logins is going to have an impact on you.

‍
As a Salesforce customer, it is critical to understand that this is no longer just a contractual recommendation; it is a technical enforcement that could block user access if not properly prepared for. Below is a comprehensive guide to the upcoming changes, how they impact different user groups, and the actionable steps required to implement them smoothly.

‍
The headline impact for general users is, if you are not using some form of MFA or your 2-factor authentication uses a code sent to an email address or SMS, you’re going to be forced to use a compliant MFA tool such as Salesforce Authenticator. The biggest impact is going to be on “Privileged Users”. These are users with a System Administrator profile or permission sets that include View All and/or Modify all access (along with a few additional criteria). The impact here is greater as you will need to increase your level of compliance with a tool that meets those requirements. This will be some form of built-in authenticator bound to a device such as a computer or phone to generate the token. Applications that support this include Windows Hello or Apple Touch ID but you are not limited to these. Read below for technical requirements.

‍
Timeline and Scope of the Changes

‍
The enforcement will be rolled out in stages:

‍

• Sandboxes: Enforcement begins on June 22, 2026 (staggered over 7 days).
• Production (Privileged Users): Enforcement begins on July 20, 2026 (staggered over 30 days).
• Production (All Other Employee Users): Enforcement begins on July 20, 2026 (staggered over 30 days).

‍
What is Not Affected: This mandate applies to paid Production and Sandbox orgs for internal employee users. It does not apply to Experience Cloud/Community users, nor does it apply to non-paid environments like Developer Edition, trial, or scratch orgs. Additionally, the "Waive Multi-Factor Authentication for Exempt Users" permission will no longer automatically exempt users; administrators must contact Salesforce Support for valid exceptions like automated testing tools.

‍

Impacts on User Groups

‍
Salesforce is categorising the authentication requirements based on user permissions, enforcing a stronger baseline for highly privileged users.
‍

1. Privileged Users (System Administrators)

‍
A "privileged user" is defined as anyone assigned the System Administrator profile, or anyone with the following permissions (including via permission sets): Modify All Data, View All Data, Customize Application, or Author Apex. These permissions allow the user to do what they want with the data, so while powerful in the right hands, they can create havoc in the wrong ones.

‍

• The Impact: Standard TOTP authenticator apps (like Google Authenticator or Microsoft Authenticator) and mobile push notifications will no longer be accepted for these users because they are vulnerable to Adversary-in-the-Middle phishing attacks and MFA fatigue. In other words, these are techniques where an attacker takes over the login code and can use this on thier own machine. The new required tokens can only be used on the machine from which they are generated.
• The Requirement: Privileged users must use Phishing-Resistant MFA. This relies on WebAuthn and FIDO standards to verify the real login domain. Acceptable methods include built-in authenticators (e.g., Apple Touch ID, Face ID, Windows Hello) or physical hardware security keys (e.g., YubiKey, Google Titan).

‍

‍
2. Non-Privileged Users (Standard Employees)

‍
This group encompasses any user who does not hold the privileged permissions listed above.

‍

• The Impact: These users are subjected to a technically enforced org-wide setting: “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org”.
• The Requirement: Non-privileged users are permitted to use Standard MFA. This includes the Salesforce Authenticator app, third-party TOTP such as the Google, Salesforce or Microsoft Authenticator apps, or phishing-resistant methods. One-time passcodes delivered via email, SMS, or phone calls will not satisfy the requirement.

‍
3. Single Sign-On (SSO) Users

‍
If your org uses an SSO identity provider (IdP) like Okta or Azure AD, MFA must be enforced at the IdP level.

‍

• The Impact: SSO alone does not satisfy the requirement. The IdP must pass specific authentication claims in the SAML payload or OIDC token—specifically the AMR (Authentication Methods Reference) or ACR (Authentication Context Class Reference) signals.
• The Requirement: If Salesforce does not receive a valid signal matching the user's required security tier (Standard or Phishing-Resistant), the user will be prompted to register an MFA method directly within Salesforce.

‍
(Note: While the provided sources extensively detail Salesforce's side of the configuration, additional information from outside web sources—specifically your Identity Provider's documentation (e.g., Okta, Microsoft Entra ID)—will be required to successfully configure the mapping of AMR/ACR claims to the SAML/OIDC payload.)
‍

4. Salesforce Integration Users

The mandatory MFA enforcement for both standard and phishing-resistant requirements targets UI-based employee logins only. Therefore, logins that happen strictly via the API are unaffected by this change.

‍

For your system integrations, here is how different authentication flows are treated:

‍

• Unaffected Flows: Connected Apps or External Client Apps utilising headless flows, such as JWT Bearer or Client Credentials flows, are entirely unaffected because they do not require a UI login.

• Affected Flows: If your integration uses OAuth Web Server or Hybrid Token flows that require a user to log into the Salesforce UI to complete the authorisation process, that specific UI login step will be subject to MFA enforcement.

Implementation Steps

‍
To prevent mass user lockouts on a Monday morning in June or July, the following implementation steps could be executed (please note these should be viewed as guiding principles rather than a guaranteed prescriptive framework, as other factors can influence the outcome) :

‍
Step 1: Audit Current MFA Adoption and User Privileges

‍

• Run the free MFA Requirement Checker in Setup to identify your org's baseline. Click here. ​​
• Audit user permissions. Use SOQL queries to identify all users holding the System Administrator profile or the PermissionsModifyAllData, PermissionsViewAllData, PermissionsCustomizeApplication, or PermissionsAuthorApex fields.
• Review Login History to determine if your SSO provider is currently passing valid AMR/ACR signals.

‍
Step 2: Enable Phishing-Resistant Methods in Setup

‍

• Navigate to Setup → Identity Verification.
• Enable the settings: "Let users verify their identity with a built-in authenticator (passkey) such as Touch ID or Windows Hello" and "Let users verify their identity with a physical security key (passkey) such as U2F or WebAuthn".
• (Optional but Recommended): Activate "Allow passwordless login with passkeys" to streamline the login process for users utilising hardware keys or biometrics.

‍
Step 3: User Device Registration

‍

• For Privileged Users: Have them navigate to Personal Settings → Advanced User Details and locate the "Built-in Authenticators" or "Security Keys" row to register their devices. It is highly recommended that admins register at least two methods (e.g., a laptop or phone biometric and a backup hardware key) to prevent lockouts.
• For Non-Privileged Users: Ensure they have downloaded the Salesforce Authenticator or an approved TOTP app and linked it to their accounts.

Step 4: SSO Configuration Update

‍

• Work with your Identity Management team to ensure your SSO provider is configured to pass valid AMR or ACR attributes.
• For privileged users, the SAML payload must contain phishing-resistant signals (e.g., fido, hwk, passkey, vbm) to avoid a secondary Salesforce prompt.

‍

Step 5: Communication and Testing

‍

• Test the end-to-end registration and SSO login flows in a sandbox environment before the June 22nd sandbox enforcement date. Note: Once you have set-up the passkey, you will need to log out and tick the “Remember Me” box in some cases.
• Send communications to your users early, explaining the new requirement and providing guides for registering their authenticators or hardware keys. Establish internal access recovery procedures for admins to generate temporary verification codes if a user is locked out.

‍

Need Help?

‍

At Gen25, we help organisations assess their current state, identify potential risks and develop a practical roadmap towards compliance. From MFA readiness assessments and SSO validation to user onboarding and change management, we can help ensure a smooth transition with minimal disruption to your business.
Want to know how we can help your organisation with these changes? Get in touch with our team!

‍

Ryan Farnaby, Commercial Director UK
r.farnaby@gen25.com
+447368 641599

‍

Joris van Wessem, Account Executive NL
j.vanwessem@gen25.com
+31611274732

‍