July 7, 2026

Salesforce MFA Enforcement Update: What Was Paused, What Still Applies, and the Revised 2026 Dates

Salesforce paused its all-employee MFA enforcement over a security-key enrolment bug and revised the 2026 dates. Here is what moved and what still applies.

TL;DR

Salesforce paused enforcement of standard MFA for all employee users after a bug in the phishing-resistant enrolment flow, where users with existing security keys were wrongly prompted to register new ones.
The all-employee sandbox date, originally 22 June, was reset and restarted from 6 July. The production date remains 20 July 2026, now rolled out in a longer staggered wave.
Phishing-resistant MFA for privileged users and admins was not cancelled. It reached production on 1 July 2026 as planned, after a brief delay tied to the same bug.
The rest of the 2026 wave is unaffected: email domain verification, the report-export step-up and Transaction Security Policy controls, and the network controls that shipped earlier all stand.
A pause is not a reprieve. Use the extra days to verify enforcement actually applied, build a lockout recovery runbook, and move human logins off integration accounts before the exemption stops covering them.

What You'll Learn

Exactly which enforcement Salesforce paused, and which went ahead on schedule
The revised dates, and why a working login on the deadline still does not prove you are compliant
How to confirm enforcement actually took in an org, using Salesforce's own tools
A recovery runbook for locked-out admins, including the case where there is no second admin
Why integration and service accounts need attention now, because the old MFA exemption changed

The Problem

For weeks the message was that mid-2026 is when Salesforce stops asking and starts enforcing MFA. Then, days before the biggest date, the plan moved. Salesforce paused enforcement of standard MFA for all employee users, and a lot of admins read "paused" as "cancelled" and quietly closed the tab.

That is the risk. The pause is narrow, it is temporary, and it does not touch the tier that actually locks admins out. The phishing-resistant requirement for privileged users still landed in production on 1 July. Report-export controls are still coming. And the pause exists because of a real enrolment bug, not because Salesforce changed its mind about enforcement. An org that treats the pause as a reason to stop preparing is going to meet the rescheduled date in exactly the state it was in before, which is the state that made enforcement risky in the first place.

Common questions this article answers:

Did Salesforce delay MFA enforcement, and which part exactly?
What are the new dates, and is 20 July still real?
Did phishing-resistant MFA for admins get pushed back too?
What should I actually do with the extra time?

Quick Answer

Salesforce paused only one thing: enforcement of standard MFA for all employee users. Sandbox enforcement, first set for 22 June, was reset and restarted from 6 July 2026. Production remains 20 July 2026, now delivered over a longer staggered rollout. The reason was a defect in which users who already had a security key registered were incorrectly prompted to enrol a new one during phishing-resistant MFA setup. The phishing-resistant tier for privileged users and admins was not paused in substance; it reached production on 1 July 2026. Everything else in the 2026 security wave, email verification and the report-export controls in particular, is on track. Salesforce has been explicit that this is paused, not cancelled, and that MFA and phishing-resistant MFA remain required. Because the rollout is staggered and dates can move again, confirm the exact schedule on Salesforce's live enforcement articles before you plan around a specific day.

What Salesforce paused, and what it did not

It helps to separate the two enforcement tiers, because only one of them moved.

Standard MFA for all employee users is the broad requirement that every internal user completes multi-factor authentication. This is the tier that was paused. Salesforce placed the enforcement on hold, then republished a revised schedule rather than an open-ended delay. In Salesforce's own words, enforcement was "briefly delayed" while it "worked to resolve an issue in which users with existing security keys were incorrectly prompted to register new ones during the phishing-resistant MFA enrollment process."

Phishing-resistant MFA for privileged users and admins is the stricter tier: anyone with the System Administrator profile, or the Modify All Data, View All Data, Customize Application, or Author Apex permission, must use a security key, a built-in authenticator, a passkey, or certificate-based authentication. Authenticator apps and push approvals do not count. This tier was not cancelled. It reached production on 1 July 2026, after the same bug caused a short delay around the changeover.

So the headline is narrower than "MFA enforcement delayed." The admin lockout tier is live. The all-employee tier slipped by a couple of weeks in sandbox and is being rolled out more gradually in production.

The revised 2026 dates

Here is the current shape of the two MFA tiers, alongside the other controls that did not move. Treat the staggering as the important detail: each date is when a wave begins, not a single cutover.

Control	Sandbox	Production	Status
Phishing-resistant MFA for privileged users and admins	22 June 2026	1 July 2026	Enforced
Standard MFA for all employee users	Restarted 6 July 2026 (staggered)	20 July 2026 (staggered over a longer wave)	Paused, then rescheduled
Step-up authentication and default TSP on report exports	22 June 2026	13 July 2026	On track
Email domain verification	Earlier in 2026	Earlier in 2026	Already enforced
VPN, proxy, and high-risk IP blocking	Earlier in 2026	24 April 2026	Already enforced

The trap that catches people is the staggered rollout. Salesforce enforces in waves, so a login that still works on the morning of a date is not proof of compliance; your org may simply not have been reached yet. That was true before the pause and it is more true now that the all-employee production wave is spread over more days. Do not read "it still works" as "we are fine."

Because this situation is still moving, confirm the live dates before you act. The two enforcement articles to watch are "Prepare for MFA Enforcement for All Employee Users" (Salesforce Help 005321561) and "Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins" (005321563).

Why the pause happened

The cause matters, because it tells you where to look in your own org. The defect was in enrolment, not in policy: users who already had a security key registered were prompted, incorrectly, to register a brand-new one during phishing-resistant MFA setup. For an admin staring at that prompt on enforcement day, the experience is indistinguishable from being told their existing key no longer works, which is exactly the kind of confusion that turns a rollout into a flood of support tickets.

Salesforce paused the broad enforcement to fix that flow rather than push it onto every employee at once. The practical read for you is simple. If your admins registered keys early, confirm those keys still authenticate cleanly now that the fix is in, and do not let anyone re-register a second key in a panic and lose track of which one is real. Registering two deliberate methods per admin is good practice; registering a mystery third because a buggy prompt asked for it is not.

What is still on track

The pause was specific to the all-employee MFA tier. The rest of the 2026 wave did not move, and it is easy to lose sight of that in the noise about MFA.

Email domain verification and the network-level controls (VPN, proxy, and high-risk IP blocking) already enforced earlier in 2026. The report controls are the ones still ahead of most orgs: step-up authentication on report actions, step-up on anomalous exports, and a default Transaction Security Policy that challenges report exports above 10,000 records, all reaching production around 13 July 2026. If your org has no Transaction Security Policy of its own, Salesforce creates a default one for you on that date, and a default you did not design is more likely to surprise your users than one you wrote. It is better to define your own before the date than to inherit the default. We cover the full list and its logic in Salesforce Security Enforcement in 2026: Every Change, Date, and What Admins Must Do.

Do not down tools: verify, recover, and lock down

The right use of the extra days is not to wait. It is to close the three gaps that turn any enforcement date into an incident.

Verify that enforcement actually applied

Do not infer compliance from a working login. Check it directly. In Setup, open Identity Verification at [MyDomain]/lightning/setup/IdentityVerification/home. If the box "Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org" is selected and greyed out so you cannot deselect it, enforcement is active for that environment. If it is still editable, you are pre-enforcement and can turn it on yourself in a sandbox to rehearse. After a date passes, watch Login History for users still failing the second factor, and remember that a sandbox refresh wipes MFA verifiers, so a freshly refreshed sandbox can lock out every admin at once until someone re-enrols.

The lockout recovery runbook

Decide the recovery path before you need it, because the moment you need it is the moment nobody can log in to fix it.

If a privileged user is locked out and another admin is available, the second admin generates a temporary identity verification code, disconnects the old method, and has the user re-register a phishing-resistant method. This is the normal path and it takes minutes.
If there is no second admin, recovery runs through Salesforce Support, which is slower and is precisely why every admin should register at least two phishing-resistant methods in advance, a primary key and a backup, so one lost key is never a lockout.
The old exemption no longer saves you here. The "Waive Multi-Factor Authentication for Exempt Users" permission stops waiving interactive UI logins, and restoring any exemption now requires a Salesforce Support case rather than a checkbox. Do not plan around the waiver for human users.

Integration users and the exemption that changed

This is the quiet failure mode. The MFA requirement targets interactive UI and SSO logins, and API-only integration logins remain out of scope, but only if they are genuinely API-only. Two things bite here. First, the Waive-MFA permission now applies only to those API-only users, so any human who has been signing into a shared service account through the browser is in scope and will be blocked. Second, an integration user that a person occasionally logs into through the UI is not really API-only.

Find the accounts at risk. The Waive-MFA permission maps to the API field PermissionsBypassMFAForUILogins, so you can list who holds it:

-- Waive-MFA holders via permission sets
SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,
       Assignee.IsActive, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsBypassMFAForUILogins = true

For each holder, decide whether it is a true integration identity or a human in disguise. Move real integrations onto a dedicated integration user with no interactive UI login, authenticate them through named credentials and IP allowlisting rather than a shared password, and move the humans onto their own accounts with a registered verifier. If you would rather audit this from the command line, our own sf-audit plugin resolves privileged access and flags integration and service accounts across profiles and permission sets in one read-only command. The new guest and access-control work is covered in Salesforce Guest User Exposure: How sf-audit Grades It by Real Reachability, and the hands-on first run is in Catch Salesforce Security Gaps in One Command.

Frequently Asked Questions

Q: Did Salesforce cancel MFA enforcement?

A: No. It paused enforcement of standard MFA for all employee users and then published a revised schedule, resetting the sandbox date to 6 July 2026 and keeping the 20 July production date with a longer staggered rollout. Salesforce has been explicit that MFA and phishing-resistant MFA remain required. Treat it as a short delay to one tier, not a reprieve.

Q: Was phishing-resistant MFA for admins delayed too?

A: Not in substance. It reached production on 1 July 2026 as planned, after a brief delay tied to the same security-key enrolment bug. If your admins do not have a security key, built-in authenticator, passkey, or certificate registered, they are already in scope to be blocked, so this is the tier to act on first.

Q: Why did Salesforce pause it?

A: A defect in the phishing-resistant enrolment flow prompted users who already had a security key to register a new one, which would have caused widespread confusion at enforcement. Salesforce paused the broad rollout to resolve that flow rather than push it to every employee at once.

Q: Is the 20 July date still real?

A: Yes, as the start of a staggered production wave rather than a single cutover. Because the rollout spans several days and dates have already moved once, confirm the live schedule on Salesforce Help articles 005321561 and 005321563 before planning around a specific day.

Q: What happens to our API integrations on these dates?

A: API-only integration logins are not in scope for the MFA requirement, and the Waive-MFA exemption still applies to them. The risk is accounts that are not really API-only: a service account a person signs into through the browser is in scope and will be blocked. Move real integrations to a dedicated integration user with no UI login, and give the humans their own accounts.

Key Takeaways

Only the all-employee tier paused. Standard MFA for all employees was reset in sandbox to 6 July and rescheduled in production around 20 July, staggered. Nothing else in the wave moved.
The admin tier is live. Phishing-resistant MFA for privileged users reached production on 1 July 2026. If admins lack a qualifying method, they can be blocked now.
The pause was a bug fix, not a policy change. Existing security keys were wrongly prompted to re-register; the requirement itself stands.
A working login is not proof of compliance. The staggered rollout means your org may not have been reached yet. Verify enforcement directly in Setup and Login History.
Use the time to verify, recover, and lock down, especially the integration and service accounts that the changed exemption now leaves exposed.

What's Next?

Recommended Reading:

Action Items:

Confirm every admin has a working phishing-resistant method registered, and that early-registered security keys still authenticate after the fix.
Run the Waive-MFA query, then move real integrations to API-only users and humans onto their own accounts before the 20 July wave.
Write your own Transaction Security Policy for report exports before the 13 July default lands.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.