What's changing in Salesforce MFA, what it means for your team, and how to get ahead of it before it gets enforced.

You've probably seen the notices in your Salesforce org. Maybe you've gotten the emails. Maybe you've clicked on the help links, gotten confused, and moved on. If that sounds familiar, you're not alone.

Here's the thing: the deadline is real and it's soon. Starting in mid-June 2026 for sandboxes and early July 2026 for production orgs, Salesforce is enforcing mandatory multi-factor authentication (MFA) — and there's no opting out, no bypass, and no more kicking the can down the road.

Whether you're a Salesforce admin, an IT leader, or a business executive whose team runs on Salesforce, here's what you need to understand and what you need to do.

What's Actually Changing

Salesforce is rolling out two distinct changes, and it matters a lot which one applies to which users in your org.

Change 1: MFA required for all UI logins

Every user who logs into Salesforce through the standard login screen (what Salesforce calls a "native UI login") will be required to use MFA. No exceptions. Critically, this means the "Bypass MFA for UI Logins" permission that many orgs have granted to certain users will simply stop working. Users who've been exempt will suddenly be prompted for MFA and won't be able to get in without it. Note: this does not apply to Experience Cloud users, API-based logins, or users who authenticate via SSO, though if you use SSO, your identity provider will also need to enforce MFA on its end.

Change 2: Phishing-resistant MFA for privileged users

This is where things get more complex. "Privileged users,” which Salesforce defines as System Administrators and any user with the system-wide permissions View All Data, Modify All Data, Customize Application, or Author Apex, must use what Salesforce calls "phishing-resistant" MFA.

Here's the critical catch: the Salesforce Authenticator app does not satisfy this requirement. Neither does Google Authenticator, Authy, or any other standard one-time code app. If your admins are currently using those tools to meet MFA today, they'll need to change their approach.

Phishing-resistant methods that are acceptable include:

• Built-in authenticators like Apple Touch ID or Windows Hello
• Password managers that support passkeys and require biometric authentication, such as 1Password
• Physical security keys such as YubiKey

Trusted IP Ranges don't get you out of this one, either. Privileged users are subject to these requirements regardless of their network location.

Why Is Salesforce Moving So Fast?

Fair question. The honest answer is that they've probably been signaling this for a while, but between the volume of Salesforce release notes, in-app banners, and emails, it's been easy to miss. Now the deadline is genuinely close.

The underlying reason is security. There have been a number of credential-based breaches in the Salesforce ecosystem, phishing attacks where users are tricked into handing over login credentials that work even with standard MFA. Phishing-resistant methods like passkeys are specifically designed to prevent this, because the cryptographic keys involved never leave your device and can't be intercepted or spoofed in a phishing attack.

Ultimately this is a meaningful security upgrade, and for organizations with Salesforce admins and privileged users, it's worth doing right.

What Do You Actually Need To Do?

Let's break it down into concrete steps.

Step 1: Find out who's affected

Run a SOQL query to identify active users who have the "Bypass MFA for UI Logins" permission. These are the users who will be disrupted the moment enforcement kicks in. Similarly, run a query to identify all of your privileged users (System Admins and anyone with the high-level system permissions listed above). If you're not sure how to run these queries, connect with us and we’d be happy to help.

Step 2: Configure your org settings

In Setup, navigate to Identity Verification and enable the following settings: allow users to verify with a built-in authenticator (Touch ID / Windows Hello), show all verification method registration options, require identity verification during MFA registration, and allow passwordless login with passkeys. These settings pave the way for users to register phishing-resistant credentials.

Step 3: Walk privileged users through passkey setup

Once org settings are in place, privileged users will be prompted during login to choose a verification method. They should select "Use a built-in authenticator on your device." At that point, their device or password manager will generate and store a passkey. On future logins, they'll be prompted to verify via Touch ID, Windows Hello, or their password manager — whichever they set up.

This is simpler in practice than it sounds, but it does vary depending on the user's device, browser, and password manager. The best way to get comfortable with it is to test it yourself in a developer edition org or a sandbox before rolling it out to your team.

Step 4: Notify and train your users

Don't just flip the switch and hope for the best. Users who have been bypassing MFA or who aren't familiar with passkeys will hit a wall at login if they're not prepared. Communicate the change in advance, let them know what to expect on screen, and provide guidance on how to set things up. For mobile users, there's also a specific setup process using the Salesforce mobile app that's worth documenting for your team.

Step 5: Do it before your go-lives

If your organization has any major Salesforce deployments, go-lives, or migrations scheduled for June or July, make sure MFA readiness is on your pre-launch checklist. The last thing you want is a go-live disrupted by users who suddenly can't log in because enforcement kicked in and they weren't set up.

A Note on Shared Devices and Password Managers

If you don't already have a password manager in use at your company, now is a good time to consider one. At OpFocus we like to use 1Password, which supports passkeys and biometric authentication. This makes the phishing-resistant MFA experience much smoother across devices.

If a user's device has Touch ID or Windows Hello, they can use that directly. The device itself stores the passkey in a secure hardware chip. Just one caution: passkeys stored on a device's hardware chip are tied to that specific machine, so users logging in from shared or public computers need a different approach, typically a password manager that syncs passkeys across devices.

Don't Wait — The Window Is Short

Sandbox enforcement hits in mid-June, and Production follows in early July. That might feel like a comfortable buffer, but between identifying affected users, updating org settings, testing in a sandbox, and communicating with end users, this is a several-week project for most organizations.

Need help explaining this to your business users? Here is a one-minute pitch for any executive: Salesforce is enforcing stronger authentication for all users, with an even higher bar for admins and power users. This is coming whether we're ready or not. There are configuration changes to make in your org, and users need to be trained and set up before the deadline. The cost of doing it proactively is a few hours of focused work. The cost of not doing it is users getting locked out of Salesforce at the worst possible time.

Start the conversation with your team now. Spin up a developer edition org, practice the login flows, and get your plan in place.

Need Help? OpFocus Has You Covered.

MFA enforcement is one of those changes that's straightforward once you know what you're doing, but confusing enough that it's easy to miss something important. Whether you need a quick consultation or want hands-on support guiding your team through the transition, OpFocus can help. Reach out to the OpFocus team to get the conversation started. Don't let this one sneak up on you!