Salesforce MFA Enforcement Is Here: What Actually Happens and How to Avoid Disaster
Between April and July 2026, Salesforce pushed through the most significant wave of security changes the platform has seen in years: mandatory MFA for all users, phishing-resistant MFA for admins, step-up authentication on reports, and more, all compressed into roughly twelve weeks. The community reaction was blunt. One prominent Salesforce consultant has called the rollout "an absolute sh*tshow" on LinkedIn. Another based in Europe described losing client trust because requirements changed mid-rollout: IP range enforcement was on the list, then off, leaving them to walk back the guidance they'd just delivered.
If you've been watching this unfold and wondering whether your org is actually at risk, the good news is: for most organizations, the real-world impact is much smaller than the noise suggests. Here's a clear breakdown of what's actually changing, who's affected, and the bare minimum you need to do to avoid anyone getting locked out.
What's Actually Changing, and When
There are two separate enforcement changes happening on different timelines:
MFA for all employee users kicks in for sandboxes on June 22, 2026, and production on July 20, 2026. This requires every internal user to authenticate with some form of MFA: an authenticator app, push notification, security key, or biometric. This isn't new in principle; Salesforce has technically required MFA since 2022. What's new is that Salesforce is now enforcing it at the platform level, and the "Waive MFA for Exempt Users" permission no longer works as an escape hatch for UI logins.
Phishing-resistant MFA for privileged users kicks in for sandboxes June 22, 2026, and production July 1, 2026. An earlier deadline than the general MFA enforcement. This applies to anyone with the System Administrator profile, or any of these permissions: Modify All Data, View All Data, Customize Application, or Author Apex. These users must use a stronger, WebAuthn-based method like a built-in authenticator like Touch ID, Face ID, or Windows Hello, or a physical security key like a YubiKey.
The reason for the stricter requirement on privileged accounts is straightforward: standard MFA methods like TOTP codes and push notifications can be intercepted in real time through phishing kits and social engineering. Phishing-resistant methods are cryptographically bound to the real login domain, so a fake page simply can't capture them.
* You can query users with privileged permissions with the following SOQL query. Determine if they actually need the permissions they’re assigned and remove them if they don’t:
SELECT Assignee.Id, Assignee.Name, Assignee.Username, Assignee.Profile.Name, PermissionSet.Name
FROM PermissionSetAssignment
WHERE Assignee.IsActive = true
AND Assignee.UserType = 'Standard'
AND (
PermissionSet.PermissionsModifyAllData = true
OR PermissionSet.PermissionsViewAllData = true
OR PermissionSet.PermissionsCustomizeApplication = true
OR PermissionSet.PermissionsAuthorApex = true
)
ORDER BY Assignee.Profile.Name, Assignee.Name
The Simple Checklist: Are You Already Good?
For most organizations that have been managing Salesforce responsibly, you may already be in good shape. Here's the fastest way to check:
1. Is org-wide MFA already turned on? Go to Setup → Quick Find: "Identity Verification" → Identity Verification. Look for the checkbox: "Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org." If this is checked, all your standard users are covered. Salesforce will enforce this automatically on July 20 anyway, but confirming it's already on means no surprises. (Salesforce Help: Enable MFA)
2. Are phishing-resistant methods enabled for enrollment? On the same Identity Verification page, check that both of these are enabled:
"Let users verify their identity with a built-in authenticator such as Touch ID or Windows Hello"
"Let users verify their identity with a physical security key (U2F or WebAuthn)"
These are not on by default and need to be enabled before privileged users can enroll: Salesforce Help: Enable Built-In Authenticators, Salesforce Help: Enable Security Keys.
3. Who are your privileged users? Run the quick SOQL query above or check Setup → Users to identify anyone on the System Administrator profile, or with Modify All Data, View All Data, Customize Application, or Author Apex permissions. These are the users with a July 1 deadline, not July 20.
That's genuinely it for most orgs. If both boxes are checked, the worst case for your privileged users is being prompted to enroll a phishing-resistant method at their next login after the enforcement date, which they can complete on the spot using biometrics on their device.
What Actually Happens If You Do Nothing
The lockout scenario is less catastrophic than it sounds. Salesforce will not silently block users at midnight on enforcement day. What happens is:
Standard users who don't have MFA enrolled will be prompted to register a method at their next login. They cannot complete the login until they do, but the enrollment flow is built into the login experience.
Privileged users who haven't enrolled a phishing-resistant method will hit a similar prompt. Register a compliant method to continue. If built-in authenticators are enabled in your org, they can complete this with Touch ID or Windows Hello on the spot.
The only genuine lockout risk is a privileged user on a device that doesn't support biometric authentication with no security key available. A quick heads-up to your admin team before the enforcement dates eliminates this risk entirely.
What About Existing Integrations?
This is one of the most common concerns and the answer is reassuring: MFA enforcement applies to UI logins only. API-authenticated integrations like connected apps, OAuth flows, service accounts calling the API are completely unaffected. Previously authorized tokens continue to work without any re-authorization.
The one thing worth checking: if you have integration users or service accounts on privileged profiles (System Administrator, or profiles with Modify All Data etc.), confirm they are truly API-only and never authenticate through the UI. If they do touch the UI, they'll hit the phishing-resistant MFA prompt like any other privileged user. The cleaner long-term fix is to move integration users to dedicated profiles with API-only access, which removes them from the MFA enforcement scope altogether. However, there’s no reason to expect these authenticated connections to immediately break on enforcement day, this is more of a long-term hygiene/security note.
If You Use SSO: Don't Assume You're Covered
This is where the most surprises are hiding. If your organization uses an identity provider like Okta, Microsoft Entra, or similar, your users authenticate through the IdP, Salesforce doesn't perform the authentication itself. So Salesforce relies on signals in the SAML response to understand what authentication method was used.
These signals are called AMR (Authentication Methods References) and ACR (Authentication Context Class Reference). For standard users, the IdP just needs to signal that some form of MFA was completed. For privileged users, it needs to signal specifically that a phishing-resistant method was used — values like hwk (hardware key), fpt (fingerprint), or face (facial recognition).
The common failure mode isn't that your IdP doesn't do strong MFA. It's that it does strong MFA but reports it generically, sending "amr": ["mfa"] when Salesforce needs "amr": ["hwk"] or "amr": ["fpt"]. The user did everything right; the configuration didn't.
To check what Salesforce is actually receiving depends on how your SSO is configured. If you're using OIDC, you can query the AuthMethodReference field in Salesforce Login History to see what AMR values were received. However, if you're using SAML, which is the more common setup with IdPs like Okta, AMR and ACR values are not written to Login History at all, so N/A values there don't tell you much either way. When in doubt, your IdP admin can confirm directly what AMR/ACR values the Salesforce application policy is configured to include.
So, reach out to IT and ask them:
Salesforce is requiring phishing-resistant MFA for privileged users (System Administrator, Modify All Data, View All Data, etc.) starting in production on July 1. I checked our Login History and it doesn't indicate if Okta [or other authenticator] is currently passing AMR/ACR signals to Salesforce in the SAML assertion, which (if not) means our privileged users won't satisfy the requirement automatically via SSO.
We have other phishing resistant options available which should kick in as a backup, but wondering if we could confirm if Okta can or is already satisfying the requirements?
SF's documentation is here: https://help.salesforce.com/s/articleView?id=005321563&type=1
The fix is an IdP-side configuration change. Update the application policy to require a phishing-resistant factor for privileged users and ensure the correct AMR claim is included in the SAML assertion. As a backstop regardless of what your IdP sends, privileged users can enroll a phishing-resistant method directly in Salesforce (Avatar → Settings → Advanced User Details → Built-In Authenticators), which satisfies the requirement independently of the SSO flow.
The Bottom Line
The noise around these changes has been loud, and some of it was warranted: the timeline was compressed and the guidance shifted more than once. But for most orgs, the actual to-do list is short: confirm the org-wide MFA setting is on, confirm phishing-resistant methods are enabled for enrollment, identify your privileged users, and give them a quick heads-up. If you're using SSO, spend five minutes in Login History or reaching out to IT to confirm your authenticator is passing the right signals.
That's the difference between a disruptive enforcement day and a non-event.
Ready to Measure and Drive User Adoption?
Curious what your users are actually doing in Salesforce all day? Struggling to capture meaningful metrics on user adoption and usage of the platform? RecordWatch is the first fully Salesforce native solution available on the Salesforce AppExchange that was designed specifically for admins, managers, and leadership to measure and drive Salesforce adoption!
Check out our on-demand demo to learn how RecordWatch can help your organization measure and drive Salesforce adoption.
