Salesforce is done asking. Starting July 10 in sandboxes and July 20 in production, multi-factor authentication becomes mandatory for every employee user — and phishing-resistant MFA becomes mandatory for every admin and privileged account. If you have not prepared yet, the clock is not just ticking. It has already run out for sandbox environments.
This is not the first time Salesforce has talked about MFA. It has been a contractual requirement in the Master Subscription Agreement since 2022. But enforcement was soft. Orgs could enable it for some users, waive it for others, and nobody got locked out. That changes with the Summer ’26 release wave. Salesforce is locking the settings so they cannot be turned off, and users who have not registered a qualifying method will be blocked at the login screen.
What Is Actually Changing
Two separate enforcement waves are rolling out simultaneously, and they target different groups with different requirements.
MFA for All Employee Users
Every user with an employee license must authenticate with a second factor when logging in through the Salesforce UI. This applies to all profiles, all permission sets, all orgs. The enforcement timeline is staggered by Release Group:
- Sandboxes: Starting July 10, 2026
- Production: Starting July 20, 2026
The methods that qualify include the Salesforce Authenticator app (push notification), third-party authenticator apps like Google Authenticator or Microsoft Authenticator (TOTP codes), physical security keys (YubiKey, Google Titan), and built-in authenticators (Touch ID, Face ID, Windows Hello). What does not qualify: SMS codes and email codes. Salesforce does not consider those strong enough.
One detail that catches people off guard: if your org has users with the “Waive Multi-Factor Authentication for Exempt Users” permission, that permission stops working after enforcement. Those users will be prompted to enroll like everyone else. If you have legitimate automation or integration users that genuinely need an exemption, you need to file a case with Salesforce Support.
Phishing-Resistant MFA for Privileged Users
This is the stricter requirement, and it targets anyone with elevated access. You are in scope if your account has any of these, whether assigned through a profile, permission set, or permission set group:
- System Administrator profile
- Modify All Data permission
- View All Data permission
- Customize Application permission
- Author Apex permission
For these accounts, standard MFA methods are not enough. Regular authenticator apps, push notifications, and TOTP codes — including codes from password managers like LastPass or 1Password — do not satisfy the requirement. Only phishing-resistant methods qualify:
- Built-in authenticators: Touch ID, Face ID, Windows Hello (device-bound biometrics using FIDO2/WebAuthn)
- Physical security keys: YubiKey, Google Titan, or any FIDO2/WebAuthn-compliant key
The enforcement dates match the general MFA wave: July 10 for sandboxes, July 20 for production.
Why Salesforce Is Drawing a Hard Line Now
The reason for the stricter requirement on privileged accounts is not theoretical. Salesforce has documented an active threat pattern that works like this: an attacker calls someone on the phone, pretends to be IT support, and walks them through logging into a fake Salesforce page. The fake page captures both the password and the MFA code in real time, then uses both to log into the real Salesforce org before the code expires.
This attack works against regular MFA methods. Push notifications can be approved by a distracted user. TOTP codes can be captured by a convincing phishing page. But phishing-resistant methods stop this cold because they are cryptographically bound to the real Salesforce login domain. A fake page on a different domain simply cannot complete the cryptographic handshake.
According to the Arkus security analysis published in June 2026, Salesforce has seen a measurable increase in account takeover attempts targeting admin accounts in 2025 and early 2026. The pattern is consistent: social engineering to capture credentials, then immediate exploitation before the victim notices. Phishing-resistant MFA makes this specific attack vector ineffective.
What You Need to Do Right Now
If you are reading this on or after July 15, 2026, your sandbox environments may already be enforcing these requirements. Here is a prioritized action list.
Step 1: Enable Built-In Authenticator Support
In Setup, search for “Identity Verification” and enable the setting: “Let users verify their identity with a built-in authenticator such as Touch ID or Windows Hello.” If your org was created after Summer 2025, this may already be on. If it is not, enable it immediately — this is a prerequisite for both built-in authenticators and physical security keys to work.
Step 2: Identify All Privileged Users
Run a report or query to find every user who has the System Administrator profile or any of the four qualifying permissions (Modify All Data, View All Data, Customize Application, Author Apex). Check permission sets and permission set groups too, not just profiles. You might be surprised how many service accounts and dormant admins are in scope.
A quick SOQL query to start:
SELECT Id, Name, Profile.Name, IsActive
FROM User
WHERE Profile.Name = 'System Administrator'
AND IsActive = trueFor permission set checks, query the PermissionSetAssignment object joined with PermissionSet where the permission name matches one of the four qualifying permissions.
Step 3: Distribute Hardware Security Keys
If you are going the hardware key route, budget approximately $25 to $50 per key. Buy two per user — a lost key should not mean a lockout. Register both keys before enforcement hits. Popular options include YubiKey 5C NFC (USB-C with NFC, works with laptops and phones) and YubiKey 5Ci (dual USB-C and Lightning for mixed device environments).
For organizations that prefer not to distribute hardware, built-in authenticators (Touch ID on Mac, Windows Hello on PC, Face ID on iPhone) work without any physical tokens. Each user registers their own device biometrics during the enrollment flow.
Step 4: Verify SSO Configuration
If your org uses single sign-on through Okta, Azure AD, or another identity provider, SSO alone does not satisfy the MFA requirement. Your IdP must actually enforce MFA, and for privileged users, it must pass AMR (Authentication Methods References) or ACR (Authentication Context Class Reference) signals indicating that a phishing-resistant method was used. Salesforce inspects these signals at login time. Contact your IdP team to confirm the configuration.
Step 5: Check Your Release Group Schedule
Salesforce published a detailed enforcement schedule organized by Release Groups and target instances on July 6. Go to the MFA Enforcement for All Employee Users article and look for the “Release Group Enforcement Schedule” section to find the exact date for your specific org instance.
The Synced Passkey Question
One area that causes confusion is synced passkeys. Password managers like 1Password, iCloud Keychain, and Google Password Manager can create passkeys that feel identical to built-in authenticators at the login screen. They may work for Salesforce logins today.
However, Salesforce’s documentation defines phishing-resistant methods as “device-bound.” Synced passkeys that travel across devices through a cloud account are not device-bound by definition. Whether Salesforce tightens enforcement to reject synced passkeys in the future is an open question, but the definitional language and the technical infrastructure to distinguish them are already in place.
The safe approach: register your device’s built-in authenticator (Touch ID, Windows Hello) or a physical security key as your primary method. Do not rely on a synced passkey from a password manager as your only registered option.
The Broader Security Wave of Summer ’26
MFA enforcement is part of a larger push. The Security-Related Product Updates roadmap published on July 10, 2026 outlines five security changes rolling out in the Summer ’26 window:
- Email Domain Verification — Phase 2 enforcement for allowlisted domains running June 29 through July 27, 2026 in both sandboxes and production
- VPN and Proxy Blocking — Preventing connections from anonymizing VPNs, proxies, and high-risk IP addresses for Connected App and API usage (enforced since April 24, 2026)
- Extended Login Anomaly Detection — Enhanced containment for suspicious login patterns (enforced since early April 2026)
- Phishing-Resistant MFA for Privileged Users — Covered above
- MFA for All Employee Users — Covered above
Salesforce has also withdrawn the Login IP Range enforcement that was originally planned for Summer ’26, but still recommends IP restrictions as a defense-in-depth measure. If you have not implemented IP restrictions yet, the setting “Enforce login IP ranges on every request” in Session Settings is worth enabling — it checks the IP address on every request, not just at initial login.
Impact for Companies and Developers
For administrators: This is a time-sensitive operational task. Every privileged user needs a phishing-resistant method registered before enforcement hits their instance. If you have 50 admin-level accounts, that is potentially 50-100 security keys to procure and distribute, plus the biometric enrollment sessions for users going the built-in authenticator route. Start this week if you have not started already.
For developers: If you use a System Administrator profile for development (many teams do), you are in the privileged user scope. Your daily login flow changes. If you have been copying TOTP codes from a password manager, that stops working. Set up Touch ID, Windows Hello, or get a YubiKey plugged into your machine.
For organizations using SSO: The IdP configuration is the most common failure point. Your identity provider must correctly signal MFA to Salesforce. If the signal is missing or incorrect, Salesforce treats it as a non-MFA login and enforcement kicks in. Test this in a sandbox before production enforcement starts.
For integration and automation accounts: Service accounts that log in through the UI (rare but they exist) need MFA too. For API-only integrations that authenticate via OAuth, MFA does not apply to the API token flow, but any UI-based management of those accounts will require MFA.
Conclusion
Salesforce’s MFA enforcement is not a future event. Sandboxes started enforcing on July 10. Production starts July 20. The staggered rollout by Release Group means some orgs have days, others have weeks — but none have months.
The technical requirements are clear: standard MFA for every user, phishing-resistant MFA for every privileged account. The methods are well-established (FIDO2, WebAuthn, built-in biometrics). The cost is modest ($25-50 per key, or free if using device biometrics). The risk of not acting is a hard lockout at the login screen.
Check your Release Group schedule, identify your privileged users, distribute security keys or set up biometric enrollment, and verify your SSO configuration. Do it today, because the enforcement dates do not move.
References: