Salesforce's July 20 MFA Deadline Is Still Coming: What Every User Needs to Do Now

July 1 came and went. If your admins and privileged users made it through without getting locked out, that's the good news. The phishing-resistant MFA requirement for system administrators and anyone with Modify All Data, View All Data, Customize Application, or Author Apex is now live and enforced in production.

But July 20 is a different enforcement, and it has a wider blast radius.

On July 20, Salesforce begins enforcing standard MFA for all internal employee users, not just admins and privileged accounts. The rollout is staggered over approximately 30 days, so some orgs won't hit the wall until mid-August. But the enforcement is automatic, and the orgs that are going to have a bad day are the ones still assuming their current setup is fine.

If you read our earlier post on everything Salesforce changed this spring, you already understand the broader context. This post is specifically about what July 20 means for your non-admin users, the SSO trap that catches orgs by surprise, and the specific things your admin needs to check before the deadline lands on your org.

What July 20 actually enforces

July 1 was about admins and privileged users specifically. July 20 is about everyone else.

Every internal employee user in your production org will be required to complete an MFA challenge at login. The org-wide MFA setting becomes locked. You can no longer turn it off. And the "Waive Multi-Factor Authentication for Exempt Users" permission, which many orgs have used to create workarounds for specific user categories, will no longer exempt users from the MFA requirement.

The qualifying MFA methods for non-privileged users are broader than what's required for admins. Standard users can use:

The Salesforce Authenticator mobile app
Third-party TOTP apps like Google Authenticator or Microsoft Authenticator
Built-in authenticators (Touch ID, Face ID, Windows Hello)
Hardware security keys (YubiKey, Google Titan)

Standard users do not need phishing-resistant methods. That requirement applies only to privileged users and was enforced July 1. For everyone else, an authenticator app is sufficient.

Users who have no MFA method enrolled when enforcement hits their org get a fallback: Salesforce will send a one-time passcode to the email address or phone number on their account. That fallback is not the same as being exempt, and it's not a sustainable path for daily Salesforce users. Users relying on it will be completing an email or SMS challenge every time they log in until they enroll a proper method.

The SSO trap most orgs miss

This is the detail that catches organizations by surprise, and it matters especially for mid-size and enterprise orgs running Salesforce through an external identity provider.

If your org uses SSO through Okta, Azure AD, Ping Identity, ADFS, or any other external IdP, having MFA enabled at the IdP level is not enough on its own. Salesforce requires that the identity provider pass a specific signal, the ACR (Authentication Context Class Reference) or AMR (Authentication Methods Reference) value, in the SAML response or OpenID Connect token confirming that MFA was performed.

If your IdP enforces MFA but isn't configured to pass that signal, Salesforce won't recognize that MFA happened. It will prompt users for another MFA challenge on the Salesforce side, or it won't count the authentication as compliant at all, depending on how your org is configured.

This is not a Salesforce bug or an unreasonable requirement. It's a standard compliance signal that many IdP configurations weren't set up to send because there was no enforcement reason to until now. But it means that "we use MFA in Okta" is not the end of the configuration conversation. Your IdP admin and your Salesforce admin need to verify together that the signal is being passed correctly before July 20.

Who is and isn't affected

Before you start panicking about your full user base, it's worth being specific about scope.

Not affected by July 20 enforcement:

Experience Cloud users (customers, partners, or community members logging in via Experience Cloud portals)
Non-paid orgs: Developer Edition, trial orgs, and scratch orgs are excluded
Automated testing accounts (Selenium, Cucumber, Appium, RPA systems): these are still valid MFA exemptions, but they need to be submitted to Salesforce Support for formal exemption, not managed via the Waive permission, which is being retired
Users on Employee Community licenses
Logins using certificate services with a PIN

Affected by July 20 enforcement:

All internal employee users in paid production orgs who log in through the Salesforce UI
All internal employee users who log in via SSO, subject to the signal requirement described above
Users who currently have the "Waive Multi-Factor Authentication for Exempt Users" permission: that permission will no longer protect them

What your admin needs to do before July 20

1. Find your unenrolled users.

Salesforce's MFA enrollment report shows which users have completed enrollment and which haven't. Run it now. The users showing up as unenrolled in that report are the ones who will hit the fallback OTP flow, or in worse cases, who will have a phone number or email issue that prevents even the fallback from working.

2. Communicate before the deadline, not after.

The users most likely to have a bad day on July 20 are the ones who first hear about MFA when they're blocked at the login screen in the middle of a busy morning. Send a plain-language communication now: what's changing, what they need to do, and who to contact if they have trouble. A three-paragraph email to your user base costs almost nothing. A help desk queue full of locked-out users on July 21 costs considerably more.

3. Check your SSO configuration.

If your org uses an external identity provider, confirm with your IdP admin that ACR or AMR values are being passed correctly in the authentication response. Don't assume this is configured. Verify it. The Okta FAQ for Salesforce MFA compliance is a good starting point if you're on Okta. Other IdP vendors have equivalent documentation.

4. Identify and document legitimate exemptions.

If you have automated testing accounts, RPA service accounts, or other user accounts that have valid technical reasons to be MFA-exempt, those exemptions need to be submitted through Salesforce Support before enforcement hits. The Waive permission approach is being retired. Formal exemptions submitted through Support are the path forward for accounts that have a valid technical reason not to enroll in MFA.

5. Enable MFA enrollment options in Setup.

In Setup, search for Identity Verification and confirm that your org has enabled the methods you want users to use. Specifically, check that "Let users verify their identity by a built-in authenticator" and "Let users verify their identity with a security key" are enabled if you want those options available to your users alongside the Salesforce Authenticator and TOTP apps.

6. Test in sandbox before production enforcement.

The sandbox enforcement date was June 22. If your sandbox is already on the new requirements, use it. Verify the login flows, confirm SSO signals are working, and identify any integration accounts that are breaking. Fix them in sandbox before they become production problems.

What happens if you don't act

The specific failure mode depends on your setup.

For users with no MFA method enrolled and no valid email or phone on their account, enforcement means they can't log in. There's no override from the admin console once the setting is locked. Restoring access for a user locked out this way requires either getting them enrolled (which requires them to be able to log in) or a Salesforce Support case, which takes time.

For SSO orgs that haven't validated their IdP signal, the failure may be less obvious initially: users might be prompted for a second MFA challenge on top of SSO, or authentication may behave inconsistently across sessions. The first indication that something is wrong could be a surge in user support requests that takes time to trace back to the signal configuration.

For orgs relying on the Waive permission to manage exemptions, those users start hitting MFA prompts as if they were never exempt, because after July 20, they won't be. The users most likely to be on that list are exactly the ones who were never onboarded to MFA intentionally, which makes the transition harder to manage on short notice.

Eighteen days is enough time to do this right if you start now. It is not enough time to do it comfortably if you wait until next week.

At Tristella Advisors, our Salesforce practice has been helping clients through security rollouts.:

If you need help getting your org to the July 20 line without a disrupted user base, start at tristellaadvisors.com/services/salesforce-agentforce.

Sources: