TL;DR
- Salesforce's June 2026 enforcement of phishing-resistant MFA for privileged users isn't a settings change — it's a permission audit you have to run on a deadline.
- "Privileged users" means anyone with System Admin, View All Data, Modify All Data, Customize Application, or Author Apex. In a mature org, finding them is multi-week work because those grants live across profiles, permission sets, and permission set groups.
- The enforcement cadence isn't a one-off. The audit muscle you build for June is the muscle you'll need every release.
*****
If you read Salesforce's June 2026 security announcement and your first thought was "okay, we'll turn on phishing-resistant MFA," you were reading the wrong sentence.
The harder sentence is the one before it. The one that says phishing-resistant MFA — physical security keys, biometric authenticators, none of the SMS or TOTP that worked last year — is mandatory for any user with System Administrator, View All Data, Modify All Data, Customize Application, or Author Apex.
Anyone. In your org.
That’s an audit you have to run. And in most Salesforce orgs, nobody can run it cleanly.
The deadline
Sandbox enforcement starts June 22, 2026. Production rolls July 1 for the privileged-user subset, with the broader employee MFA mandate hitting July 20. Sandbox enforcement starts June 22, 2026. Production rolls July 1 for the privileged-user subset, with the broader employee MFA mandate hitting July 20. Step-up authentication for report actions begins rolling into production June 10. Shield and Event Monitoring customers also get Transaction Security Policy changes around large report exports, including a default ReportEvent policy for UI exports over 10,000 records if they haven’t configured their own. Login IP restrictions, meanwhile, remain strongly recommended — especially for orgs without phishing-resistant MFA fully in place — but Salesforce appears to have pulled back from mandatory enforcement.
This is one of the most aggressive security enforcement waves Salesforce has run, and it is clearly responding to the same threat pattern behind recent Salesforce-adjacent breaches: identity compromise, social engineering, data exfiltration, and AI-powered phishing that regular MFA was never built to withstand.
But the cadence is the part Salesforce told you about. The need for an audit is the part the press release left out.
What the audit actually looks like
To enforce phishing-resistant MFA, you have to know who's covered. That means producing a list of every active user with at least one of: the System Administrator profile, View All Data, Modify All Data, Customize Application, or Author Apex.
A reasonable person reads that list and says: thirty admins, fine.
A reasonable person who has actually done this work knows the number is wrong by an order of magnitude.
In a mature org, those permissions are granted through profiles, permission sets, permission set groups, and muted permission sets. They're inherited. They're attached to "temporary" perm sets created during a 2022 implementation and never cleaned up. They're hiding inside permission set groups labeled "Sales Ops Power User" that nobody on the security team can interpret without forensics.
To produce the real list, you have to walk every grant path. Profile → user. Permission set → assignment → user. Permission set group → component permission sets → assignments → user. Muted exclusions on top of that. Cross-reference for active users. Filter out integration users — which is a whole other phishing-resistant MFA conversation, because you can't biometric-auth a service account. Then validate each remaining user against actual business need.
For a 500-seat org that's a couple of weeks of dedicated work. For a 5,000-seat org with a decade of accumulated metadata, it's a full quarter.
And that's just to produce the list. You haven't deployed anything yet.
The work nobody scoped
The reason this audit hurts is that it's exposing something every Salesforce team already knew but didn't have a deadline for: permission sprawl is real, and it compounds.
Every "just for this project" permission set group, every cloned profile with one tweak, every Customize Application grant given to a developer who left in 2023 — all of it sits in your org earning interest. The June enforcement is the first time it's been priced.
The cost shows up two ways. First, the audit itself. Second, the rollout — YubiKeys to procure, biometric enrollment to walk users through, exception handling for the contractor who has Modify All Data and is on PTO until August.
If you have Shield or Event Monitoring and haven't built your own Transaction Security Policy by June, Salesforce installs a default one. It may or may not match your operational needs. They're not asking.
Why this isn't a one-off
Salesforce has been clear that more enforcement is coming. They're publishing a roadmap. The pattern — security recommendations becoming enforced requirements with hard deadlines — is the new normal, driven by the same threat environment that made phishing-resistant MFA mandatory in the first place.
Which means the muscle you build for June is the muscle you'll need every release.
The orgs that handle this well will use a metadata layer that can answer "who has Modify All Data, and exactly which grant gives it to them" in seconds. Whether you build that visibility, buy it, or pull it out of a half-dozen SOQL queries every quarter — that's the call to make.
Just don't make it on July 19.
The shorter version, wrapped up
Salesforce told you to turn on phishing-resistant MFA for privileged users. They didn't tell you that "privileged users" is a metadata question your org can't answer without a multi-week audit. The compliance work is the audit. The MFA part is the easy part. And the audit isn't going away after June, because the enforcement cadence isn't going away.
If you don't know who has Modify All Data, Salesforce just made the deadline to find out July 1. Get digging. Or just get Sweep.
