Salesforce MFA Enforcement: Your Last-Minute Preparation Checklist

Salesforce turns on production enforcement for Multi-Factor Authentication (MFA) on July 20, 2026, staggered across a 15-day window. If your org sits at the front of that window, enforcement lands immediately and without prior warning. There was a brief pause on July 1 over an issue with security key prompts, but the schedule is active again. With limited time left, here is a day-by-day plan to get compliant.

Before enforcement begins

• Every user must have a compliant MFA method configured.
• Privileged users, System Administrators among them, require phishing-resistant MFA.
• SSO authentication signals must be validated.
• Integration accounts need a review.
• Support staff must be ready for user resets.

The plan assumes you are either starting from scratch or tying off loose ends. It front-loads the heavy tasks so you are not spending a weekend on admin work.

Day 1: Audit your setup and communicate

Understand the environment you have before you change any configuration.

Confirm your authentication model

Work out how your users log in to Salesforce:

• Salesforce-native login. Users authenticate with Salesforce credentials, and MFA enrollment and enforcement are managed inside Salesforce.
• Single sign-on (SSO). Users authenticate through an external Identity Provider (IdP) like Okta, Microsoft Entra ID (Azure AD), Ping Identity, or ADFS. The IdP must enforce MFA, and Salesforce must receive proof that it did.

With SSO, Salesforce relies on the Authentication Methods References (AMR) and Authentication Context Class References (ACR) the IdP passes. Get those signals wrong and users are either prompted for Salesforce-native MFA or blocked from access. Work with your identity team so the IdP sends the right phishing-resistant authentication signals.

Two ways to remediate an SSO setup:

1. Configure your IdP to pass the required phishing-resistant authentication signals.
2. Have affected privileged users register a Salesforce-native phishing-resistant method (e.g., passkey, FIDO2 security key) as a fallback.

Checking the model now saves you a lot of troubleshooting later.

Identify System Administrator accounts and privileged users

List every user on the System Administrator profile. Then check who has elevated privileges through Permission Sets or Permission Set Groups, particularly Modify All Data, Manage Users, View All Data, Customize Application, or Author Apex. All of them are mandated to use phishing-resistant MFA.

Use Data Loader or a similar tool to query the PermissionSetAssignment object to identify all active users with these permissions:

SELECT
    Assignee.Id,
    Assignee.Name,
    Assignee.Email,
    Assignee.Username,
    Assignee.IsActive,
    PermissionSet.Name,
    PermissionSet.Profile.Name,
    PermissionSet.PermissionsModifyAllData,
    PermissionSet.PermissionsViewAllData,
    PermissionSet.PermissionsCustomizeApplication,
    PermissionSet.PermissionsAuthorApex
FROM
    PermissionSetAssignment
WHERE
    Assignee.IsActive = TRUE
    AND (
        PermissionSet.PermissionsModifyAllData = TRUE
        OR PermissionSet.PermissionsViewAllData = TRUE
        OR PermissionSet.PermissionsCustomizeApplication = TRUE
        OR PermissionSet.PermissionsAuthorApex = TRUE
    )

That catches active users holding the affected permissions, whether they came from a Profile, a Permission Set, or a Permission Set Group.

Locate users needing MFA method registration

Run the standard identity verification methods report in Salesforce Setup to see which users still need to register an approved MFA method. Compile the list and pick out everyone with no verified authentication method on file.

Then communicate:

• Send clear, concise communications explaining why MFA is being enforced (Salesforce org-wide, no opt-out).
• Specify the enforcement timeline for your organization.
• Provide step-by-step instructions for MFA enrollment.
• Establish a dedicated support channel (e.g., Slack, Teams, shared inbox) for user questions.

By the end of Day 1 you should know exactly where your org stands on MFA, and no user should be able to get blindsided by lockout.

Resources:

• See How Your Users Verify Their Identity
• Which Salesforce Users Need Passkeys? A Quick Guide for Admins
• Multi-Factor Authentication for Salesforce

Day 2: Deploy MFA and reinforce communication

Register backup authentication methods

Make sure every user registers at least one backup authentication method. Devices get lost, reset and damaged, and if that device held the only method, your support queue pays for it. Start with the people least likely to have easy access to a personal smartphone or a dedicated device: manufacturing and warehouse staff, contractors, anyone on a shared workstation.

Deploy MFA org-wide

For most users, deployment comes down to one of the following:

• Salesforce Authenticator, Salesforce's mobile app.
• Third-party TOTP applications such as Google Authenticator and Microsoft Authenticator.

Verification methods based on email, SMS, or voice calls do not satisfy Salesforce's MFA requirement, and none of them should be a user's sole authentication method.

Enable phishing-resistant methods in Setup

Configure and enable the supported phishing-resistant MFA options for privileged users in Setup → Identity Verification. These methods meet the phishing-resistant requirement:

• Built-in authenticators: Touch ID, Face ID, Windows Hello.
• FIDO2/WebAuthn security keys such as YubiKey.
• Cloud-synced passkeys stored in compliant platforms like password managers.

Methods that do not qualify as phishing-resistant:

• Salesforce Authenticator push notifications.
• TOTP applications (Google Authenticator, Microsoft Authenticator, Authy).
• SMS-based verification codes.
• Email verification codes.

Make sure the affected users understand the requirements and have ample time to register and test their devices.

Communicate again

Send a final reminder covering the enforcement timeline, enrollment instructions, and support channels. A reminder that lands at the right moment can take a real bite out of the ticket queue.

Resources:

• Enabling Salesforce MFA: Top 5 Methods for Salesforce Admins
• Configure the MFA Verification Methods Available to Your Users for Salesforce Orgs
• Prepare for MFA Enforcement for All Employee Users

Day 3 (Friday): Address non-standard logins and edge cases

Integrations, middleware, and the critical exceptions get their turn today.

Integration users, middleware, and API connections

Go through every connected app, external client application, and integration user setup. A non-human login that fails MFA breaks a business process immediately. Fix anything fragile now.

Request exemptions (if necessary)

Accounts like test automation or RPA tools that rely on the "Waive Multi-Factor Authentication for Exempt Users" permission lose it: the permission stops working automatically once enforcement begins. Obtaining an exemption means going through Salesforce Support directly, and the morning of enforcement is the worst possible time to start that conversation. Open the case well in advance.

Validate SSO signals

If you use an IdP, go back to your identity team and confirm that AMR and ACR signals are being passed correctly. Salesforce needs them to verify upstream MFA compliance. Incorrect signals will result in users being blocked.