For years, Salesforce security guidance came as recommendations. This summer it comes as enforcement. Between late June and the end of July 2026, a wave of changes lands on every org — and two of them can lock your own admins out if you haven't prepared.
1. Phishing-resistant MFA for privileged users — the big one
Starting June 22 in sandboxes and rolling through production from July 1 to July 31, Salesforce requires phishing-resistant MFA for privileged users: System Administrators and anyone with Modify All Data, View All Data, Customize Application or Author Apex.
"Phishing-resistant" is the key phrase. Standard authenticator apps and push notifications don't qualify — the credential has to be cryptographically bound to the device and the domain. In practice that means:
- Built-in platform authenticators — Touch ID, Face ID, Windows Hello
- FIDO2 / WebAuthn hardware security keys — budget roughly $25–50 per key
The failure mode here isn't abstract: an admin who hasn't registered a qualifying method before their org's enforcement window can't get in to fix it. Register methods for every privileged user now, in sandbox first, and keep at least two registered methods per admin so a lost laptop isn't a lockout.
2. Step-up MFA on reports
Rolling out from June 3 (sandboxes) through June 10–July 4 (production): users get re-challenged for MFA when running or viewing reports — even if they already authenticated with MFA at login. Expect tickets from confused users in the first week. A one-paragraph heads-up email before your org's window saves your help desk a bad Monday.
3. Default Transaction Security Policies on exports (Shield)
If you have Shield or Event Monitoring, Salesforce deploys a default Transaction Security Policy in July that blocks report exports exceeding 10,000 records. The default is blunt — it doesn't know your finance team legitimately exports 40,000 rows at quarter close.
If you create your own ReportEvent policy before mid-July, yours wins. If you don't, Salesforce's default does — and the first you'll hear of it is a blocked export at the worst possible time.
Write a custom policy that encodes your real rules: who may export at volume, from which IP ranges, with what notification. It's an hour of work that prevents a quarter-end fire drill.
4. Already live — and still catching people
- Anonymizing proxy blocking (since April 24): connections through Tor and consumer VPN/proxy services flagged as high-risk are refused. Remote workers on personal VPNs will report "random" login failures — point them to the corporate VPN.
- Email domain verification / DKIM (since April): if your org sends from a domain without proper DKIM, deliverability is already degrading. Verify your sending domains in Setup.
- MFA for all users: nominally long-standing, but June tightens SSO handling — confirm your identity provider actually signals MFA completion to Salesforce, or your "compliant" SSO users aren't.
5. Worth doing while you're in there: login IP ranges
Not enforced, but Salesforce is recommending it loudly: profile-level Login IP Ranges plus "Enforce login IP ranges on every request" in Session Settings. With credential-stuffing attacks against SaaS at an all-time high, it's the cheapest control you're not using. Test in sandbox first — the "every request" setting bites integrations with rotating egress IPs.
The one-afternoon checklist
- List every user with admin-grade permissions (don't forget integration users with Modify All Data)
- Register two phishing-resistant MFA methods per privileged user — sandbox first
- Order hardware keys this week if you need them; shipping eats your runway
- Send the step-up-MFA-on-reports heads-up email to all report users
- Shield orgs: write your own ReportEvent Transaction Security Policy before mid-July
- Verify DKIM on all sending domains and MFA signaling on SSO
- Schedule login IP ranges as a follow-up hardening sprint
None of this is exotic. It's exactly the kind of governance work that separates orgs ready for autonomous agents from orgs that should be nervous about them — the same foundation we covered in what Agentforce actually needs underneath it. Security debt and data debt get called in the same way: suddenly.
Sources
Frequently Asked Questions
When is Salesforce enforcing phishing-resistant MFA?
Enforcement begins June 22, 2026 in sandboxes and rolls through production from July 1 to July 31, 2026 for privileged users (System Administrators, Modify All Data, View All Data, Customize Application, Author Apex). Standard authenticator apps don't qualify — only FIDO2 hardware keys or built-in biometrics (Touch ID, Face ID, Windows Hello).
What counts as phishing-resistant MFA in Salesforce?
Phishing-resistant MFA uses credentials cryptographically bound to a specific device and domain. In practice: FIDO2/WebAuthn hardware security keys (YubiKey, etc.) or built-in platform authenticators like Touch ID, Face ID, and Windows Hello. Standard TOTP apps (Google Authenticator, Salesforce Authenticator) do not qualify.
What is the Salesforce Transaction Security Policy ReportEvent?
A ReportEvent Transaction Security Policy lets you control when report exports are blocked or require approval. In July 2026, Salesforce auto-deploys a default policy to Shield and Event Monitoring orgs that blocks exports over 10,000 records. If you write your own policy before mid-July, yours wins. The fix is less than an hour — and our managed services team handles it as part of every security sprint.
Need the checklist run for you?
We audit privileged access, MFA readiness and export policies as part of every managed-services engagement. One call and you'll know exactly where your org stands.
Book a strategy call →