Salesforce Is Done Asking: Five Security Changes Coming in June 2026

05/13/2026 by Bobby Ray Hurd

Salesforce is tightening security on the platform, and that's a good thing, but there are actions you need to take to ensure the changes don't create any issues for your team.

Salesforce is tightening its security requirements. Some of these changes are already live. Some take effect in June and July. And for the ones that matter most, Salesforce is not asking. They are locking the settings so you cannot turn them off.

This is not a drill.

It is also not complicated.

But it does require attention, and sooner is better than later. These changes apply to both your production org and your sandboxes, so if you have active development work in progress, your team needs to be aware.

Here is what is changing, what it means in plain language, and what you need to do.

1. Multi-Factor Authentication Is Required for Everyone

If you have logged into any online banking or email service in the last few years, you have probably already used multi-factor authentication. MFA just means that logging in requires two things instead of one: your password, plus a second verification step from something you physically have, like your phone or a security key.

Salesforce has already made this mandatory for all employee license users. MFA has been enforced for direct UI logins since 2024, and it is a contractual requirement in the Salesforce Master Subscription Agreement. If your org has been operating with MFA enabled, you are already in compliance here. The June 2026 wave tightens enforcement further for any remaining gaps, including SSO configurations where the identity provider was not properly signaling that MFA occurred.

There are a few options for the second authentication step. The Salesforce Authenticator app sends a push notification to your phone that you approve with a tap. Third-party authenticator apps like Google Authenticator or Microsoft Authenticator generate a time-based code you type in at login. Physical security keys and built-in authenticators like Touch ID, Face ID, and Windows Hello work too. What does not count: text messages and email codes. Salesforce does not consider those strong enough.

To check where you stand, go to Setup, search for "Identity Verification," and confirm that MFA is enabled for all direct user interface logins. If your organization uses single sign-on (SSO) through a provider like Okta or Azure AD, make sure MFA is turned on at that level as well. SSO without MFA does not satisfy the requirement.

One more detail: if your org has users with the "Waive Multi-Factor Authentication for Exempt Users" permission, that permission will stop automatically exempting them after enforcement. Those users will be prompted to enroll like everyone else. If you have legitimate automation or integration users that need to bypass MFA, you will need to file a case with Salesforce Support to restore the exemption.

2. Privileged Users Need Phishing-Resistant MFA. This One Is Enforced

This is the big one, and it has hard dates.

Starting June 22, 2026 in sandboxes and July 1, 2026 in production (staggered by instance through late July), Salesforce will require phishing-resistant MFA for all privileged users. This is not a recommendation. Salesforce will lock the setting so it cannot be disabled, and users who have not registered a qualifying method will be blocked at the login screen.

This applies to anyone with the System Administrator profile OR any of these permissions, whether assigned through a profile, permission set, or permission set group: Modify All Data, View All Data, Customize Application, or Author Apex. If you have any of those, you are in scope.

Here is why Salesforce is drawing a harder line for these accounts. There is an active threat pattern that Salesforce has documented. Attackers call someone on the phone, pretend to be IT support, and walk them through logging into a fake Salesforce page. The fake page captures their password and their MFA code in real time, then uses both to log into the real Salesforce org before the code expires. This is not theoretical. It is happening right now, and it works against regular MFA methods like push notifications and authenticator app codes.

Phishing-resistant methods stop this attack cold because they are cryptographically tied to the real Salesforce login page. A fake page simply cannot intercept them. The methods that qualify are built-in authenticators (Touch ID, Face ID, Windows Hello) and physical security keys like YubiKey or Google Titan that support the FIDO2 or WebAuthn standard.

What does not qualify for privileged users after enforcement: regular authenticator apps (Google Authenticator, Authy), push notifications (including Salesforce Authenticator), and TOTP codes from any source, including password managers like LastPass. If you have been copying time-based codes out of LastPass to log into a client org as a System Administrator, that workflow will stop working after enforcement.

To set this up, go to Setup, search for "Identity Verification," and enable the setting that says "Let users verify their identity with a built-in authenticator such as Touch ID or Windows Hello." If your org was created after Summer 2025, this may already be on. Then make sure every user in the privileged scope has registered at least one phishing-resistant method before the enforcement dates. If you go the hardware security key route, budget around $25 to $50 per key, and get two per user so a lost key does not become a lockout.

One thing to be aware of: password managers like 1Password and iCloud Keychain can create synced passkeys that feel identical to built-in authenticators at the login screen. These may work for Salesforce logins today. However, Salesforce's own documentation defines phishing-resistant methods as "device-bound.” Whether Salesforce tightens enforcement against synced passkeys in the future is an open question, but the definitional language and the technical infrastructure to distinguish them are already in place. Register your device's built-in authenticator (Touch ID, Windows Hello) or a physical security key as your primary method. Do not rely on a synced passkey from a password manager as your only registered option.

If your organization uses SSO, your identity provider must pass AMR or ACR signals indicating that a phishing-resistant method was used. Salesforce will inspect those signals at login. Check with your IdP team to confirm this is configured correctly.

3. Login IP Address Restrictions

This one is going to require some coordination, but the concept is straightforward. And unlike phishing-resistant MFA, this is not being enforced at the platform level. Salesforce is strongly recommending it as a defense-in-depth measure, but they have not set a date to require it and Login IP Range enforcement was withdrawn from the Summer 2026 release.

An IP address is basically the internet equivalent of a return address on a piece of mail. By specifying which addresses are allowed on a profile, you are telling Salesforce to only let users with that profile log in from locations you trust. If someone tries to log in from an address that is not on the list, they get denied.

The value here is layered defense. If someone steals a user's credentials and tries to log in from halfway around the world, IP restrictions can stop them even if they somehow got past MFA. It is one more wall between your data and someone who should not have it.

There is one detail that catches people off guard. By default, Salesforce only checks your IP address when you first log in. If your address changes mid-session (say you disconnect from your office Wi-Fi and switch to a coffee shop), Salesforce will not notice. There is a setting called "Enforce login IP ranges on every request" in Session Settings that fixes this. Salesforce specifically recommends turning it on, especially if your org has not yet implemented phishing-resistant MFA.

Now, the question everyone asks: what about remote workers? If your team works from home, from the road, or from different locations, you will need to account for that. Organizations that use a VPN with a known, static IP address can add that address to the allowed list. The point is not to lock people out of doing their jobs. The point is to know where your approved access points are and only allow those.

To configure this, go to Setup, search for "Profiles," open each profile, and navigate to "Login IP Ranges." Add the ranges where your users legitimately work from. Your IT team or internet service provider can tell you what those ranges are. Worth noting: Login IP Ranges are a profile-only feature. You cannot assign them through permission sets. If your org follows the "minimum profile, maximize permission sets" pattern, this one is the exception. Users who need different IP rules will need different profiles. Then go to Session Settings and turn on "Enforce login IP ranges on every request." Test this in a sandbox first. You do not want to find out you forgot an IP range by getting locked out of production on a Tuesday morning.

4. Transaction Security Policies for Data Exports

There are actually two report-related changes here, and the first one applies to everyone.

Starting in June 2026, Salesforce will require step-up MFA authentication any time a user runs or views a report, even if they already logged in with MFA. This is not limited to exports. It is not limited to Shield customers. If someone on your team pulls up a report in Salesforce, they may be asked to verify their identity again before the results load. Sandbox enforcement begins June 3. Production enforcement rolls out June 10 through July 4.

This is separate from the Transaction Security Policy change below, which only applies to orgs with Shield or Event Monitoring. And so, the next one has a narrower audience, so let me save you some time: if your org does not have Salesforce Shield or the Event Monitoring add-on, skip this section. It does not apply to you.

Still here?

Ok.

Transaction Security Policies are automated rules that watch for specific user actions in real time. The one Salesforce cares about here is a policy on report exports. Reports are one of the easiest ways to pull large amounts of data out of Salesforce. Someone exports a report with 10,000 donor records to a spreadsheet, and suddenly that data is sitting on a laptop where Salesforce can no longer protect it.

A TSP on report exports can require the user to re-verify their identity before the download goes through, or it can block the download entirely and notify an administrator.

Here is the part that matters: if your org has Shield or Event Monitoring and you have not set up a qualifying TSP by June 22, 2026 (sandboxes) or July 13, 2026 (production), Salesforce will automatically create and enable a default policy that triggers on report exports exceeding 10,000 records. The problem with letting Salesforce do it is you do not get to choose the thresholds or the behavior. Their default may not match how your organization actually works. Power users who legitimately export large reports on a regular basis could find their workflow disrupted. It is better to set your own policy with thresholds that make sense for your team.

To set this up, go to Setup, search for "Transaction Security Policies," and create a new policy on the ReportEvent event type. You can use the Condition Builder for a simple, no-code setup, or write an Apex class if you need more complex logic. Set the action to require MFA step-up authentication for large exports, and test it in a sandbox before deploying to production.

5. Anonymizing Proxies and High-Risk IP Addresses

This last one is less about what you need to configure and more about what your users need to stop doing. And unlike the other items on this list, this one is already live. Salesforce began enforcing high-risk IP and anonymizing proxy blocking on April 24, 2026.

Salesforce monitors for and blocks connections that come from anonymizing proxies, Tor exit nodes, and IP addresses flagged as high-risk. An anonymizing proxy is a server that sits between you and wherever you are going on the internet, strips out anything that identifies you, and sends your traffic along so the destination cannot trace it back to you. These are services designed to mask where someone is really connecting from, which is exactly what an attacker would use.If someone on your team is connecting to Salesforce through a consumer VPN service that anonymizes their traffic, Salesforce may block or freeze their account. Practitioners have reported account freezes that required an admin to manually restore access. Salesforce has not published specific criteria for what triggers this action, and there is currently no documented mechanism for orgs to exempt trusted IP addresses from this monitoring (to date).

There has been some confusion about whether Salesforce is blocking all VPNs. They are not. What they are blocking are anonymizing services designed to hide a user's real location. Your organization's corporate VPN, which has a known IP address that you control, is perfectly fine. Just make sure it is configured in your Login IP Ranges as described above.

If any of your users work from locations or networks that might be flagged, coordinate with them to make sure their connection paths are clean and traceable.

6. Email Domain Verification

This one is already enforced and it is the quietest of the bunch. Starting in April 2026, Salesforce requires that any domain your org sends email from is verified through DKIM or Salesforce's authorized email domain process. If a sending domain is not verified, outbound emails from that domain are silently dropped. No bounce message. No errors. The email just never arrives.

This affects any org that sends email from Salesforce, which is most of them. If your users or automated processes send email from a custom domain and that domain has not been verified, those emails stopped being delivered in April.

To check where you stand, go to Setup and search for "DKIM Keys" to review your DKIM configuration. Your IT team will need to add DNS records to complete the verification if it has not been done. This is not a Salesforce-side configuration alone. It requires access to your domain's DNS settings.

What Happens If You Do Nothing

Some of these changes will wait for you.

Others will not.

If your privileged users have not registered a phishing-resistant MFA method by July 1, 2026, they will be blocked at the login screen. This is not a warning or a Health Check flag. It is a locked setting. Salesforce will not let them in.

If you have Shield or Event Monitoring and no TSP on report exports, Salesforce will deploy a default policy for you in July 2026 with a 10,000-record threshold. You may not like how it behaves.

Login IP Ranges are strongly recommended but not enforced. Nothing will break if they are not configured, but your org is less protected without them.

Anonymizing proxy blocking is already live. If users are being blocked today, this is likely why.

Where to Start

If you are not sure where your org stands, log into Salesforce, go to Setup, and check each of these:

Identity Verification: Is MFA enabled for all direct logins? Are built-in authenticators enabled? Have your privileged users registered a phishing-resistant method?
User Permissions Audit: Who has System Administrator, Modify All Data, View All Data, Customize Application, or Author Apex? All of those users need phishing-resistant MFA registered before July 1.
Profiles: Do your profiles have Login IP Ranges configured? (Recommended, not required.)
Session Settings: Is "Enforce login IP ranges on every request" turned on? (Recommended, not required.)
Transaction Security Policies: If you have Shield, do you have a TSP on ReportEvent?

If you can answer yes to all of those, you are in good shape. If not, now is the time to act. The phishing-resistant MFA enforcement is the most urgent item. Sandbox enforcement begins June 22. Production enforcement begins July 1.

At Arkus, we are ready to work with you to review your current settings and make sure everything is in place well before those dates. This is the kind of thing that takes a couple of hours to get right, but can cause real disruption if it is left until the deadline. Reach out to your project manager and we will schedule time to walk through your org together and confirm you are covered.

Additional Resources

Has your team worked through all the steps to address these changes? Anything you would add to the list? If you would like any help making these changes yourself, reach out to Arkus through our contact form or over on LinkedIn. Our team is here to support your team.

More by
Bobby Ray Hurd