Salesforce's Complete MFA Overhaul: What Admins and All Users Need to Know by July 2026

Salesforce is rolling out a two-tier MFA enforcement strategy in 2026. Starting June 22 in sandboxes and July 1 in production, admins and privileged users must use phishing-resistant authentication methods. Then, on July 20, the requirement expands to every employee user in your org. Here's what's changing, who's affected, and how to prepare your entire organization.

The Two-Tier MFA Strategy

Salesforce's 2026 security overhaul isn't a single MFA requirement—it's two overlapping mandates:

Tier 1 (July 1, 2026): Phishing-resistant MFA for admins and privileged users only.

Tier 2 (July 20, 2026): Standard MFA for every employee user.

Understanding the difference between these tiers is critical. They have different deadlines, different acceptable methods, and different implementation paths.

Tier 1: Phishing-Resistant MFA for Privileged Users

Who's Affected

A user needs only one of these to be in scope:

• Users with the System Administrator profile
• Anyone with the Modify All Data permission
• Anyone with the View All Data permission
• Anyone with the Customize Application permission
• Anyone with the Author Apex permission

What Qualifies as Phishing-Resistant

• WebAuthn-based security keys (YubiKey, Titan, Feitian, and similar)
• Built-in device authenticators (Windows Hello, Apple Touch ID/Face ID, Android passkeys)

What No Longer Qualifies

• Salesforce Authenticator app push notifications
• SMS or one-time password (OTP) codes
• Google Authenticator or Microsoft Authenticator TOTP codes

Why This Matters

Admin-level credentials are the highest-value phishing target. A single compromised admin session can expose or alter an entire org. By requiring a phishing-resistant method for these accounts, Salesforce is raising the bar for attackers trying to gain administrative access.

Standard push notifications and SMS codes are vulnerable to MFA fatigue attacks. An attacker can bombard a user with push notifications until they accidentally approve one. SMS codes can be intercepted or relayed through adversary-in-the-middle attacks. Phishing-resistant methods like security keys and passkeys are immune to these attacks because they cryptographically verify the login domain—a fake login page can't trick them.

Direct Login vs. SSO

Direct UI Login: The privileged user registers a passkey or security key directly in Salesforce. When they try to log in without one, Salesforce blocks them.

SSO Login (Okta, Azure AD, Ping, etc.): Salesforce can't enforce a phishing-resistant method inside a third-party SSO flow. Your identity and security team must configure the SSO provider itself to require a phishing-resistant factor for these users. This is the step organizations most often miss.

If your org uses SSO, coordinate with your identity team now. They need to set up conditional access policies or MFA rules in your SSO provider to require phishing-resistant authentication for users with Salesforce admin roles.

Tier 1 Timeline

Tier 2: Standard MFA for All Employee Users

What's Actually Changing

Salesforce has required MFA since February 2022, but enforcement has largely relied on self-attestation. Many orgs still have users without it fully set up. Starting June 22, 2026 in sandboxes and July 20, 2026 in production, Salesforce is closing that gap with direct, technical enforcement at login for every employee user.

Who's Affected

Every employee or internal user who logs into Salesforce directly or via SSO. This includes:

• Sales reps
• Marketing users
• Service agents
• Finance and operations staff
• Any other internal user with a standard license

What Counts as Acceptable MFA

For direct username/password login: The Salesforce Authenticator mobile app (push notification) is the standard method most orgs will use. Security keys and built-in device authenticators are also accepted but optional at this tier.

For SSO login: The SSO provider itself must be configured to require MFA. Salesforce enforcement checks that the SSO session included an MFA step—it doesn't layer its own on top.

Tier 2 Timeline

How to Prepare Your Org

For Tier 1 (Privileged Users)

1. Identify all privileged users by pulling a permission-set and profile report. Don't assume it's just your IT team—you might have consultants, contractors, or business users with elevated permissions.
2. Determine login method. Which users log in directly vs. through SSO? This determines your implementation path.
3. For direct login users: Communicate the requirement and deadline. Provide clear instructions for setting up a security key or passkey. Budget for multiple security keys per user (one for backup).
4. For SSO users: Coordinate with your identity team to configure phishing-resistant MFA in your SSO provider. Verify that MFA is actually enforced, not just available.
5. Test in sandbox starting June 22. Have your help desk understand what a real lockout looks like before production enforcement.
6. Verify redundancy. Make sure you have at least two admins with phishing-resistant MFA set up before July 1.

For Tier 2 (All Employee Users)

1. Run an MFA adoption report to identify users who haven't registered an MFA method. Use Setup > Identity Verification or your MFA adoption dashboard.
2. Roll out the Salesforce Authenticator app org-wide with clear setup instructions and a target completion date ahead of your production stagger window.
3. For SSO orgs: Confirm with your identity team that MFA is actually enforced inside the SSO provider—not just available.
4. Communicate broadly. Explain what the login screen will look like, which MFA methods are acceptable, and who to contact if someone gets stuck.
5. Test in sandbox first (June 22 window) so your help desk knows what a real lockout looks like before production enforcement.
6. Staff your help desk for a surge. Because this hits every employee user (not a small admin group), unprepared orgs typically see a help-desk spike during the production stagger window.

What Happens If You Don't Prepare

For Tier 1

If a privileged user hasn't set up phishing-resistant MFA by July 1, their login will be blocked. They'll see an error message directing them to set up a compliant method. Only after they register a security key or passkey will they be able to log in again.

This creates operational risk if you have multiple admins and one of them is unavailable during the enforcement window.

For Tier 2

Users without a registered MFA method are blocked from logging in once enforcement reaches their org—no self-service bypass. Because this hits every employee user, unprepared orgs typically see a help-desk spike, not just a handful of tickets.

SSO orgs that assumed "SSO means we're covered" may discover their identity provider was never actually configured to require an MFA step.

The Bigger Picture

This two-tier approach is part of Salesforce's broader shift toward zero-trust security. The platform is moving away from the assumption that a single strong password plus any MFA is sufficient. Instead, it's implementing layered controls: phishing-resistant MFA for high-value accounts, step-up authentication for sensitive actions, and anomaly detection for suspicious logins.

For organizations managing complex Salesforce environments, staying ahead of these changes requires planning and communication. Consider working with experienced Salesforce consulting partners who can help you identify privileged users, configure SSO correctly, and roll out MFA smoothly across both tiers.

Understanding how this fits into your broader sales activity tracking and territory management strategies will also help you appreciate the security context. Contact us today if you want to discuss how to prepare your org for these changes.