Salesforce MFA Enforcement 2026: What Breaks & How to Prep

Sapphire Smith
10 hours ago
6 min read

Your admin logged in Monday and got hit with a “Create a Passkey” screen out of nowhere. A friend at another company, same size, same industry, still logs in the old way. Neither of you is wrong. Salesforce’s MFA enforcement isn’t landing on one date. It’s rolling out org by org, in waves tied to release groups, through early September. If you haven’t checked which wave you’re in, now’s the time.

Here’s the thing worth sitting with: the passkey prompt itself isn’t really the risk. It’s a two-minute setup. The risk is everything sitting around that prompt that a lean team might not be thinking about. The RPA bot that logs in every night. The SSO config that’s been “good enough” for three years. The exemption someone set up for a test account back when nobody thought it would matter. Treat this like revenue-system maintenance and you’ll be fine. Treat it like a formality, and you’ll find out the hard way what breaks.

Why Salesforce Is Forging New Locks

This isn’t Salesforce being precious about security theater. 2026 has been a rough year for the platform’s customer base. Attackers, including the group known as ShinyHunters, have spent much of the year exploiting overly permissive Experience Cloud guest-user configurations to pull data out of Salesforce orgs. The most recent high-profile example is Brinks Home. The residential security company confirmed unauthorized access to part of its systems after discovering the intrusion on July 20, and ShinyHunters claimed responsibility, alleging it stole more than 4.9 million Salesforce records. Brinks itself hasn’t verified that number, though the breach and the intrusion are confirmed.

That’s the backdrop. Credential theft is cheap, phishing kits are good enough to fool a tired employee at 4pm on a Friday, and a stolen password plus a bypassed MFA prompt is often all it takes to get into a CRM holding your entire pipeline, your customer contacts, and your support history. Salesforce forcing the issue isn’t overreach. It’s catching up to where the threat already is.

Two Waves, Two Bars

Here’s where it gets specific and where a lot of the confusion is coming from. Salesforce is running two separate enforcement tracks with two different bars.

Privileged users—anyone with the System Administrator profile or the Modify All Data, View All Data, Customize Application, or Author Apex permissions—have to use phishing-resistant MFA. Passkeys, hardware security keys, or built-in device authenticators like Touch ID or Windows Hello. Standard authenticator apps and TOTP codes, including Salesforce’s own Authenticator app, no longer satisfy the requirement for this group. If your admin is still logging in with a code from an authenticator app, that stops working the moment enforcement hits their org.

Everyone else gets standard MFA. TOTP apps and the Salesforce Authenticator app still count here. Lower bar, same idea: no logging in with just a password anymore.

The dates depend on which release group your instance falls into, and Salesforce has moved these dates more than once already. Sandboxes across both tiers went in enforcement on July 10, production was staggered with the first group going July 20, a second group following July 27–28, and then a third shortly after. For the “all employees” tier specifically, two more release groups just crossed into enforcement mid-August, with Japan, Korea, and everyone remaining scheduled for early September. Salesforce publishes the full release-group-to-instance mapping and lets you look up your own dates directly. Worth bookmarking rather than guessing.

Salesforce Enforcement Dates by Release Group

Salesforce publishes these as two separate Help articles, which is why the divergence is easy to miss. For most release groups both tiers land on the same day — one change window, one round of comms. But if you're on R2a or R2b, they don't: your admins were locked into passkeys one to two weeks before anyone else in the org had to do anything. That's two separate readiness deadlines, and if you planned around a single date you likely caught your admins by surprise. Note too that R1 moved: Salesforce shifted that window from July 21–22 to July 27–28 in a July 23 update, so any schedule you saved before then is out of date.

A few of the changes that come with enforcement are permanent, not temporary friction:

The org-wide MFA toggle locks on. Once enforcement hits, admins lose the ability to switch it back off.
The “Waive Multi-Factor Authentication for Exempt Users” permission stops working automatically. If you’ve been using it to keep RPA bots, integration accounts, or test automation logging in without MFA, that exemption goes quiet unless you’ve gotten it re-approved directly through Salesforce Support.
The underlying API field for that exemption is being pulled from the schema entirely. If any of your code or metadata still references it by name, that reference throws a compilation error and blocks package installs or upgrades until it’s cleaned up.
Trial orgs converted to paid subscriptions no longer get a 30-day MFA grace period.
SSO logins need to carry a verified signal (AMR or ACR) proving MFA happened at the identity provider level. If your IdP isn’t sending that signal correctly, users get prompted to enroll in Salesforce MFA directly, even if they technically completed MFA somewhere else.

It’s good to note: The service-account piece is where where the greatest possibility for damage lies. Maybe nobody notices a human admin needing to register a passkey–but everybody notices when the nightly data sync stops running because the integration user it logs in as suddenly can’t get past an MFA prompt.

Salesforce MFA Enforcement Readiness Check

Before enforcement reaches your org, run through this:

Find your instance, your release group, and your dates. Don’t assume. Look it up directly using Salesforce’s instance lookup and release-group mapping.
Audit your privileged users and anyone holding the Waive-MFA permission. Salesforce publishes SOQL queries for both, so this is a five-minute pull, not a research project.
Turn on phishing-resistant methods org-wide and get every admin registered with two. One passkey and one backup. If a device gets lost, you don’t want your only admin locked out with no recovery path.
If you’re on SSO, check the AMR and ACR fields in Login History. This tells you whether your identity provider is actually sending the signal Salesforce needs, or whether your “MFA-compliant” SSO setup is about to start prompting everyone anyway.
File exemption requests with Salesforce Support now for any automation or RPA accounts that genuinely need one. The old self-service waiver doesn’t cut it anymore, and support review takes time you don’t want to be racing against a deadline for.

The Axiss Take

We're watching this staggered release play out across client orgs in real time. In the same week, we might be closing out enforcement cleanup for one client while helping another prep for a release group that's still weeks out. That's disorienting if you're expecting a single hard cutover. It's just how Salesforce is running this rollout, and once you know that going in, it's easy enough to plan around.

This MFA rollout isn't happening in isolation. It follows Salesforce's retirement of legacy Connected Apps behavior earlier this year, and it's landing in the same stretch as Salesforce revising its plan to retire permissions from Profiles after admins flagged concerns with the original timeline. The through-line here isn't chaos. It's Salesforce tightening security in response to a genuinely active threat environment and adjusting the plan when admin feedback shows the plan needs adjusting. A platform willing to course-correct instead of pushing a flawed timeline through on principle is a good sign, even when the schedule shifts more than once. The tradeoff is that admins have to stay a little more alert to what's changing and when, and that's a fair trade for the security upside.

None of this is more than a lean team can handle. Know your release group, run the checklist above, and you'll be covered well before enforcement reaches your org. We've written before about what "AI-ready" actually requires under the hood, and the same idea holds here: the platform underneath your revenue systems is going to keep moving, and staying ahead of that is routine maintenance, not a fire drill.

If your team doesn't have the bandwidth to track every release-group date by hand, that's exactly where we come in.

Get Ahead of It

Not sure which release group your org falls into, or whether your service accounts are actually covered? Get a Salesforce MFA readiness check. We’ll walk through your admin exposure, service-account risk, and SSO signal setup together before enforcement finds the gaps for you.