TL;DR
- Through the first half of 2026 Salesforce moves at least eight security controls from "recommended" to technically enforced across every paid org.
- The earlier ones already landed: device activation for SSO (January), email domain verification (April) and VPN/proxy/high-risk IP blocking (24 April).
- The headline cluster lands in July: phishing-resistant MFA for admins and report step-up authentication on 1 July, anomalous-export step-up and the default Transaction Security Policy on 13 July, and MFA for all employees on 20 July.
- Sandboxes are enforced first, generally from 17 to 22 June, so you can and should test there before production.
- Report step-up authentication dates were revised on 2 June, which is the "it got pushed" change some teams heard about. The current production date is 1 July.
- One preparation step covers most of it: make sure every user has a registered MFA method, a valid email, and where relevant a phishing-resistant verifier.
What You'll Learn
- Every Salesforce security control being enforced in 2026, grouped by what it protects
- The exact sandbox and production dates for each, and which ones moved recently
- Why "we already do MFA" does not mean you are covered for all of this
- The single preparation step that satisfies most of the cluster, and the few that need separate work
- Where each requirement is documented, so you can verify against the source
The Problem
Most teams are tracking one of these changes, usually MFA, and have missed that it arrives inside a wave. Salesforce spent years asking customers to turn on security settings. In 2026 it stops asking and starts enforcing, and it does so across login, reports, network and email at roughly the same time. The risk is not any single control; it is that an org prepares for the one it heard about and gets caught by the four it did not. A second problem is drift: some of these dates have already been revised once, so a plan built on a date you noted in May may already be wrong.
Common Questions This Article Answers:
- What is Salesforce actually enforcing in 2026, and when?
- Which dates changed recently, and what are they now?
- If we already use MFA, which of these still apply to us?
Quick Answer
In 2026 Salesforce enforces a cluster of platform security controls. Three already took effect: device activation for external SSO logins (20 January), email domain verification (April) and blocking of VPN, proxy and high-risk IP connections (24 April). Five more land in July, with sandboxes enforced first in mid to late June: phishing-resistant MFA for privileged users and step-up authentication on report actions on 1 July, step-up authentication on anomalous report exports and an auto-created default Transaction Security Policy on report exports over 10,000 records on 13 July, and standard MFA for all employee users on 20 July. Each date is the start of a staggered rollout, not a single cutover. The fastest way to be ready is to confirm every active user has a registered MFA method and a valid email, give admins a phishing-resistant verifier, and review your report-export policies before the July dates.
- 20 Jan 2026Device activation for SSOExternal identity-provider SSO logins must pass device activation on a new or unrecognised device or IP.
- Apr 2026Email domain verificationOutbound email from unverified domains fails to send. Apex, Flow and Workflow alert emails are dropped silently.
- 24 Apr 2026VPN, proxy and high-risk IP blockingConnections through anonymising VPNs, proxies or high-risk IP addresses are frozen and blocked.
- 01 Jul 2026Phishing-resistant MFA: adminsPrivileged users need a security key, passkey or built-in authenticator. Sandboxes 22 Jun.
- 01 Jul 2026Step-up auth on report actionsRe-verify identity to run, view or export a report, even when already logged in. Sandboxes 17 Jun. Dates revised 2 Jun.
- 13 Jul 2026Step-up auth on anomalous report exportMachine-learning detection of unusual export behaviour triggers a step-up challenge. Sandboxes 22 Jun.
- 13 Jul 2026Default Transaction Security PolicyA default policy on report exports over 10,000 records is auto-created if you have none. Shield and Event Monitoring orgs. Sandboxes 22 Jun.
- 20 Jul 2026MFA for all employeesEvery internal UI and SSO login needs MFA. The Waive-MFA exemption stops working for interactive logins. Sandboxes 22 Jun.
The login and MFA controls
Three of the changes are about who gets in and how.
Device activation for SSO took effect on 20 January 2026. Logins that come through an external identity provider now go through device activation, so an unrecognised device or IP can trigger an extra verification such as an email code. If your SSO users suddenly see verification prompts, this is usually why.
MFA for all employee users is enforced in sandboxes from 22 June and in production from 20 July 2026. Every internal user, whether they log in directly or through SSO, needs multi-factor authentication. The "Waive Multi-Factor Authentication for Exempt Users" permission stops exempting interactive logins, though it still applies to API-only integration users.
Phishing-resistant MFA for privileged users is enforced in sandboxes from 22 June and in production from 1 July 2026, three weeks ahead of the all-employees date. Admins and anyone with Modify All Data, View All Data, Customize Application or Author Apex must use a security key, a built-in authenticator such as Touch ID or Windows Hello, or a passkey. Mobile authenticator apps, including Salesforce Authenticator, do not qualify for this tier. We cover this one in depth, including how to verify your SSO signal, in the 2026 MFA enforcement guide.
The report controls
The newest and least-watched part of the cluster is about reports, because exfiltration through report exports has become a common attack.
Step-up authentication on report actions asks a user to re-verify identity when they run, view or export a report, even though they are already logged in with MFA. The challenge interval is configurable, defaulting to 120 minutes. It is enforced in sandboxes from 17 June and in production from 1 July 2026. These dates were revised on 2 June 2026, which is the change some teams heard described as the report requirement being "pushed out." The current production date is 1 July.
Step-up authentication on anomalous report export is a machine-learning control that watches for unusual export behaviour and challenges the user when it sees it. It rolls out in a report-only mode first, then moves to active challenges. Enforced in sandboxes from 22 June and in production from 13 July 2026.
The default Transaction Security Policy matters for Shield and Event Monitoring orgs. If you have not created a qualifying policy by the enforcement date, Salesforce auto-creates a default one that triggers on report exports over 10,000 records. Enforced in sandboxes from 22 June and in production from 13 July 2026. The catch is that an auto-created policy may not match how your business actually exports data, so it is better to define your own before the date than to inherit the default.
The network and email controls
Two controls already took effect earlier in the year and are easy to overlook because they do not announce themselves at the login screen.
Blocking of VPN, proxy and high-risk IP connections took effect on 24 April 2026. Users connecting through anonymising VPNs, proxies or addresses Salesforce rates as high risk are blocked, which mainly affects connected apps and API traffic. If an integration started failing in late April for no obvious reason, check the source IP.
Email domain verification took effect across March and April 2026. Outbound email from unverified domains fails to send. The quiet danger is that Apex, Flow and Workflow alert emails are dropped silently with no bounce, so an automation can look healthy while its notifications never arrive. Verify every sending domain in Setup.
What to actually do
Most of this cluster is satisfied by one piece of preparation. Make sure every active user has a registered MFA verification method, a current email address, and an SMS number where they rely on one. That single step covers standard MFA, the report step-up challenges and the anomalous-export control, because all of them fall back to a user's registered verifiers.
Then handle the few that need separate work. Give every admin and privileged user a phishing-resistant method, ideally two, and test an SSO login in a sandbox to confirm the asserted signal qualifies. Review your report-export Transaction Security Policies so you define your own rather than inherit the default. Verify your email sending domains. And confirm no integration depends on a VPN or proxy that the network control now blocks.
The first move there, knowing exactly who your privileged users are, is the one worth automating rather than eyeballing. Our open-source sf-audit plugin (sf plugins install @cclabsnz/sf-audit) lists every privileged user across profiles and permission sets and scores the wider security posture against checks that map onto this enforcement wave, all from one command. See Catch Salesforce security gaps in one command for how to run it.
Do all of this in a sandbox first. Sandboxes are enforced from mid to late June, ahead of production, precisely so you can find the breakages before your users do. Remember that a sandbox refresh wipes registered MFA verifiers, so do not refresh right before a deadline.
What this wave signals
Step back from the dates and a pattern shows. Every one of these controls is built as if the password is already stolen. Device activation, anomaly detection, mid-session step-up and IP blocking all check whether a session is still legitimate rather than guarding the login. Identity has become something Salesforce re-confirms throughout a session, not a gate you pass once. And half the cluster targets reports and exports rather than logins, because the damage in a modern breach is the bulk export after a legitimate sign-in, not the sign-in itself.
The other half of the pattern is about control. Auto-created default policies, MFA you cannot switch off, and the retired Waive permission all remove the customer's ability to be insecure. Salesforce is taking ownership of the security floor and importing the wider industry consensus to set it: phishing-resistant methods, assume-breach design, machine-learning anomaly detection. The practical conclusion for an admin is the reframe underneath all of it. Salesforce security has moved from a posture you configure when there is time to a standard enforced on a deadline, which means the job now looks less like hardening and more like running a compliance calendar.
Frequently Asked Questions
Q: Did the Salesforce report MFA requirement get delayed?
A: The dates for step-up authentication on report actions were revised on 2 June 2026, which is what some teams heard as a delay. The current dates are sandboxes from 17 June and production from 1 July 2026. The other report control, step-up authentication on anomalous exports, is enforced in production from 13 July. Always confirm against the live Salesforce article, since these dates have moved before.
Q: We already enforce MFA. Are we covered for all of the 2026 changes?
A: No. Standard MFA at login is only one control. Admins also need phishing-resistant MFA, which a mobile authenticator app does not satisfy. Reports get their own step-up challenges, exports get an anomaly control, and there are separate network and email requirements. Using MFA is necessary but not sufficient.
Q: What is the single most useful thing to prepare?
A: Make sure every active user has a registered MFA method, a valid email address, and an SMS number where relevant. Most of the cluster, including the report step-up challenges, falls back to those registered verifiers, so a user who has them set up will be challenged rather than blocked.
Q: What happens to API and integration logins?
A: Standard MFA targets interactive UI and SSO logins, and the Waive-MFA permission still applies to API-only integration users. The network control is the one most likely to affect integrations, because connections through blocked VPNs, proxies or high-risk IPs are refused regardless of credentials.
Q: Why are sandbox dates earlier than production?
A: Salesforce enforces in sandboxes first, generally from 17 to 22 June, so you can test and fix before the production dates in July. Use that window. Enable each control in a sandbox, attempt the affected logins and report actions, and resolve any breakage there.
Key Takeaways
- It is a wave, not a single change: at least eight controls move to enforcement across 2026, most landing between 1 and 20 July.
- The July dates are the ones to plan around: admins and reports on 1 July, exports and Transaction Security Policy on 13 July, all employees on 20 July.
- Dates have moved: report step-up authentication was revised on 2 June, so verify against the source rather than an older note.
- One step covers most of it: registered MFA method, valid email and SMS for every active user.
- Test in sandboxes first: they are enforced from mid to late June, before production, by design.
What's Next?
Recommended Reading:
- Salesforce MFA Enforcement in 2026: What Admins Must Verify and Do
- Mapping Salesforce Security to NZISM, the NZ Privacy Act and ISO 27001
- Why Salesforce Health Cloud Needs Its Own Security Review
- Summer '26: the SAML retirement and Apex secure-by-default changes
- Catch Salesforce Security Gaps in One Command (sf-audit)
Action Items:
- Confirm every active user has a registered MFA method, a valid email and an SMS number.
- Give each admin two phishing-resistant verifiers and test an SSO login in a sandbox before 1 July.
- Review your report-export Transaction Security Policies and verify your email sending domains.
Resources & References
- Security-Related Product Updates to the Salesforce Platform (005317465)
- Prepare for MFA Enforcement for All Employee Users (005321561)
- Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins (005321563)
- Prepare for the upcoming Step-up Authentication requirements on Report Actions (005321566)
- Prepare for Step-up Authentication in Anomalous Report Export (005321567)
- MFA Requirement Checker