Salesforce’s 2026 Security Updates: Key Changes and How to Prepare
Salesforce recently published an updated security roadmap, outlining a series of changes related to authentication, email security, and sensitive data protection. Some of these changes are already in effect, while others will roll out in phases through the rest of Spring and Summer. The overall direction is consistent: Salesforce is continuing to raise its baseline security standards, and organizations that get ahead of the changes now will have a smoother experience as enforcement expands.
Here’s a breakdown of what’s changing and what preparation looks like for each area. Also keep an eye on Salesforce documentation since the enforcement dates can change.
Email Domain Verification
Salesforce now requires that any domain used to send email from the platform be verified. Verification can be set through an active DKIM key or an entry in the Authorized Email Domains list in Setup. Each domain and subdomain must be verified separately, and individual email address verification is not sufficient to meet this requirement.
Enforcement began rolling out to production orgs in April 2026. This includes any emails sent out through automation or integrated apps. Organizations that haven’t completed verification may be experiencing email delivery failures already, often without a visible error. The Deliverability page in Setup has a “Use a substitute email address for unverified domains” option that can serve as a temporary measure while DKIM is being configured. DKIM setup typically requires coordination with whoever manages your organization’s DNS.
MFA for All Employee Users
While MFA has been contractually required by Salesforce for some time, enforcement is beginning soon. Starting July 20th in Production (staggered over 30 days) and June 22nd in Sandboxes (staggered over 7 days), Salesforce will begin enforcing MFA for internal employee Users org-wide, with the “Require MFA for all direct UI logins” Setting locked on permanently. This applies to both direct UI logins and SSO logins, and notably, Sandbox orgs are included in enforcement.
SSO does not automatically satisfy this requirement. If your identity provider doesn’t pass a valid AMR or ACR signal confirming that MFA was used, users will be prompted to enroll in Salesforce MFA at login. The “Waive MFA for Exempt Users” permission also stops functioning at enforcement (contact Salesforce Support ahead of time if you have legitimate exemptions to preserve).
Acceptable methods for MFA include:
- Authenticator Apps like Salesforce Authenticator or Microsoft Authenticator
- A built-in Authenticator like Touch ID, Face ID or Windows Hello
- A physical security key like Yubikey or Titan security key
It’s important to note that Security Keys and Built-in Authenticators need to be enabled under Identity Verification in Setup, and then each User must register their MFA method. To avoid disruption on enforcement day, communicate the timeline to Users in advance and then make sure every user has at least one MFA method registered before the enforcement date.
Phishing-Resistant MFA for Admins and Privileged Users
This is the change that may require the most lead time. For System Administrators and any Users with Permissions such as Modify All Data, View All Data, Customize Application, or Author Apex, MFA rules will be more strict than for other Users. They will be required to use phishing-resistant MFA specifically. That means Security Keys such as YubiKeys, or Built-in Authenticators such as Touch ID, Face ID, or Windows Hello. Standard MFA methods including Salesforce Authenticator, Google Authenticator and Microsoft Authenticator apps will not satisfy the requirement for these users.
Be sure to identify all Users who have these special permissions, and make them aware of this higher standard of MFA. The User Access and Permissions Assistant app, available from Salesforce Labs for free on AgentExchange, is one way to easily find all Users who have the special permissions.
Timeline:
- Sandboxes: Starting June 22, 2026, staggered over approximately 7 days
- Production: Starting July 1, 2026, staggered over approximately 30 days
VPN/Proxy Blocking and Login Anomaly Detection
While Salesforce has been taking extra measures to protect against suspicious activities via anonymizing VPNs, proxies, or high-risk IP addresses for a while, Salesforce is now expanding those measures to Connected App and API traffic originating from those suspicious addresses. Any User account that connects from a suspicious source, including through a Connected App or API Usage, may be frozen. Salesforce will send an email to the affected User and to all Admins and Users with the Modify All Data permission. The email will include instructions on how to handle the situation.
Organizations with a legitimate business need for anonymizing proxies should open a support case with Salesforce to discuss alternatives.
These security measures are automatically applied and already in effect.
Step-up Authentication for Report Actions and Anomalous Report Step-Up Authentication
Salesforce is rolling out a new setting under Identity Verification that will require additional authentication for sensitive actions, beginning with running or viewing a Report. In Production, the new setting will start appearing at the end of May and will begin being enforced about two weeks later (roll out is staggered). In Sandboxes the setting will start appearing at the end of May and be enforced a week later.
When a User runs or views a report and a configurable period has elapsed since their last step-up challenge, they’ll be prompted to verify their identity before proceeding. The default period is 120 minutes, adjustable between 2 and 120 minutes by Admins. This applies to all Users regardless of login method, and being on a trusted IP or corporate network does not provide an exemption. Completing MFA at login does not satisfy the step-up requirement either.
Separately from the time-based step-up authentication for reports, Salesforce is also deploying detection for unusual report activity. When significant deviations from a User’s normal report behavior are detected, a step-up MFA challenge will be triggered on their next report action, even if they’ve recently passed a step-up challenge.
The Salesforce documentation lists additional information and steps for preparation.
Transaction Security Policy Enhancements for Shield and Event Monitoring Customers
For organizations with Salesforce Shield or standalone Event Monitoring licenses, Salesforce is deploying a default Transaction Security Policy on ReportEvent that triggers when a UI report export exceeds 10,000 records, requiring step-up authentication to complete. A new “Modify Transaction Security Policy” permission is also being introduced. Without it, Users will have read-only access to TSPs even if they have the Customize Application Permission. All TSP management actions will require step-up authentication going forward. The default policy will be available to review in sandboxes starting June 1 and in production starting June 15, with enforcement beginning June 22 in sandboxes and July 13 in production. It’s worth reviewing and testing the policy in Sandbox before enforcement arrives.
In Summary
Each of these changes has a Sandbox enforcement window before Production. Wherever possible, take the time to test these new policies out in the Sandbox before they begin being enforced in Production.
Salesforce indicates that these updates are part of a broader, long term roadmap to security enhancements. Taking the time to review and test these changes early will help ensure a smooth transition for both Admins and Users, and will help keep all organizations safer from evolving cybersecurity threats.