Salesforce Security Changes 2026: Deadlines and What To Do

Jump to a section

• Salesforce Security Overhaul 2026
• Why This Is Happening
• Change 1: Email Domain Verification
• Change 2: MFA Required for All Users (June 2026)
• Change 3: Phishing-Resistant MFA for Admins (June 2026)
• Change 4: Login IP Restrictions on Profiles (June 2026)
• Change 5: Transaction Security Policy for Exports (June 2026)
• Other Spring ‘26 Security Updates
• Execution Checklist
• FAQ
• Resources

Salesforce Security Overhaul 2026

Salesforce is turning several security recommendations into hard requirements across Spring ‘26.

• What changed: Email domain verification, MFA for users, phishing-resistant MFA for admins, profile IP ranges, and export controls.
• Key deadlines: Email verification in April 2026; most remaining controls due by June 2026.
• If you delay: Emails will fail to send, users can be blocked from accessing Salesforce, and Salesforce may auto-enable default controls.
• Who is impacted: All Salesforce customers.

Why This Is Happening

Credential theft and phishing attacks are increasing, especially with AI-assisted social engineering. Salesforce has shared hacks that exploited these kinds of vulnerabilities and impacted real businesses.

Change 1: Email Domain Verification

Every domain that sends outbound email from Salesforce must be verified.

Unverified domains will be prohibited from sending emails from Salesforce.

For timelines, setup steps, DNS examples, and troubleshooting, use our dedicated guide:
Salesforce Email Domain Verification: Requirements, Deadlines, and Setup

Change 2: MFA Required for All Users (June 2026)

MFA must be active for employee-licensed users. Some sensitive actions can require extra verification after login.

Actions

• Review Salesforce’s checklist for MFA usage to understand how your users are currently accessing your org
• Roll out Salesforce Authenticator or supported TOTP methods.
• If using SSO (Okta, Azure AD, Ping, ADFS), enforce MFA there.
• Do not rely on SMS as a compliant method.

Change 3: Phishing-Resistant MFA for Admins (June 2026)

Admins should use stronger methods than standard MFA. For more details why, you can read our detailed rationale.

Accepted

• Built-in authenticators (Face ID, Touch ID, Windows Hello)
• Hardware security keys (for example, YubiKey)
• FIDO2/WebAuthn methods

Not accepted

• Basic TOTP apps alone
• Push notification methods that remain vulnerable to approval fatigue and mistakes

Actions

• Inventory all admin profiles and permission assignments.
• Enable built-in authenticators and security keys in Identity Verification settings.
• Register at least two phishing-resistant methods per admin.
• Budget for hardware keys where needed.

Requirement

Phishing-resistant MFA for admins is not explicitly required from Salesforce at this time, though it is a best security practice and is highly recommended to reduce attack vectors.

Change 4: Login IP Restrictions on Profiles (June 2026)

Profiles should define approved login IP ranges.

By default, ranges are checked at login only. For stronger control, enable Enforce login IP ranges on every request in Session Settings.

Actions

• Document office, VPN, and approved remote ranges. You can work with your IT team on this.
• Configure profile-level login ranges.
• Plan VPN access for mobile/remote users.
• Test to avoid accidental lockouts.
• Prohibit anonymizing proxy routes and anonymizing VPNs.

Change 5: Transaction Security Policy for Exports (June 2026)

For Shield/Event Monitoring customers, a ReportEvent Transaction Security Policy should trigger step-up authentication for large data downloads.

If no qualifying policy exists by deadline, Salesforce will auto-create a default policy.

Actions

• Confirm if you have Shield/Event Monitoring licensing, otherwise this is not relevant to your org.
• Create a custom ReportEvent policy aligned to your risk model.
• Validate user experience for valid reporting workflows.
• Notify heavy report-export users early.

Other Spring ‘26 Security Updates

• Connected Apps shift: New Connected Apps creation is being phased down in favor of External Client Apps.
• 3DES retirement in SAML: Move old encryption settings to SHA-256/AES.
• Faster certificate cycles: Improve certificate tracking and alerting.
• My Trust Center (beta): Assign ownership and plug into incident response.
• Experience Cloud file scanning: Test high-volume upload/download performance.

Execution Checklist

By end of April

• Complete domain verification for all emails used in production or your sandboxes.
• Finish allowlist domain verification.
• Complete an MFA analysis of existing methods in use and if any users are not using MFA currently
• Inventory admin accounts for phishing-resistant methods.
• Document approved IP ranges.

By end of May

• Deploy phishing-resistant MFA for admins.
• Apply profile Login IP ranges.
• Implement export TSPs (if using Salesforce Shield).
• Finish MFA rollout for remaining users.

FAQ

What are the required 2026 Salesforce security changes?

Salesforce is steering all customers toward five areas: email domain verification, MFA for employee-license users, stronger MFA for admins, login IP ranges on profiles, and transaction security for large exports (Shield/Event Monitoring orgs).

What is phishing-resistant MFA?

Authentication that is cryptographically tied to device/domain (for example, passkeys, platform authenticators, hardware security keys), reducing phishing and token theft risk.

See more details about this in our blog post explaining the rationale behind these security changes.

Does MFA still apply with SSO?

Yes. MFA must be enforced by your identity provider when SSO is used.

Will Salesforce auto-create an export policy?

For eligible Shield/Event Monitoring orgs, Salesforce can add a default policy if you do not create one in time.

How do IP ranges affect remote teams?

Without VPN or approved network paths, remote logins can be blocked once profile IP controls are enforced. You will either need to whitelist their specific IP or have them use a VPN with a set IP range.

Do these requirements apply to every license type?

Salesforce has emphasized employee license users for MFA expectations. Community, partner, and other external-facing licenses can have different login patterns. Treat Salesforce Help and your contract as the source of truth for which profiles and user types are in scope, and extend the same controls to any account that can access sensitive data.

What about integration users, APIs, and automation?

The 2026 security requirement announcement centers on interactive human login and org-wide controls (MFA, IP ranges, exports). Integration and headless patterns still need separate review—connected apps, OAuth flows, and service identities should follow least privilege and your IdP policies. Confirm behavior in sandbox before production cutovers.

We use SSO for some users and Salesforce logins for others. What do we do?

Split the work cleanly: enforce MFA at the IdP for SSO users, and enforce MFA directly in Salesforce for any username/password path. One weak path undermines the rest, so inventory both and close gaps.

Is Salesforce Authenticator or a TOTP app enough for non-admin users?

For many employees, strong MFA (not necessarily phishing-resistant) may still be the bar Salesforce describes—authenticator apps and supported methods are preferred over SMS. Admins are the group Salesforce calls out for phishing-resistant methods (keys, platform authenticators, WebAuthn-class options). See our rationale post for why that split matters.

What is step-up authentication?

Step-up is an extra verification prompt after login when a user hits a high-risk action (for example, sensitive data access). Salesforce may require it even when MFA at login is already satisfied, so plan communications and support around those flows.

How many security keys should admins register?

Plan for at least two phishing-resistant factors per admin (for example, two keys, or a key plus a platform authenticator). This way if you lose access to one key, you always have a backup.

What happens if email domains are not verified?

Messages from unverified domains will be dropped. Automation-based sends may fail without obvious user-facing alerts.

Do we verify only the root domain, or subdomains too?

Each sending domain and subdomain used in From addresses must be handled—example.com versus mail.example.com are not interchangeable. Our domain verification guide walks through the checklist.

What is the difference between IP checks at login only versus every request?

Login-only enforcement validates IP when the session starts; if IP rules change mid-session, behavior may not re-check until next login. Enforce login IP ranges on every request evaluates IP on ongoing requests and can end sessions when IP context changes—stricter, and important when phishing-resistant MFA is not universal.

How do we avoid locking out admins during rollout?

Pilot in sandbox first, document break-glass or emergency access, keep a non-production admin path tested, and widen IP ranges gradually. Communicate VPN requirements before you flip stricter profile IP settings.

We use Shield or Event Monitoring—what exactly belongs on ReportEvent?

Salesforce expects a Transaction Security Policy on ReportEvent that triggers stronger verification (for example, step-up) when report data is downloaded at volume. Tune thresholds to your business so legitimate reporting is not blocked—test with real report users.

Could export controls block normal reporting users?

Yes, if thresholds are too aggressive. Design policies around acceptable export patterns, monitor false positives, and announce changes early so your teammembers are not surprised when they go to do their next data export.

Should we validate in a sandbox before production?

Yes. Sandboxes enforce earlier or on their own schedule for several items (including domains). Use them to prove MFA methods, IP ranges, and any Transaction Security behavior before you touch production.

Where should we start?

Start with email domain verification (earliest hard deadlines), then MFA coverage and admin phishing-resistant readiness, then profile IP ranges, and finally export policies if Shield/Event Monitoring applies.

If you need help making these security upgrades, please get in touch

Resources

• MFA Requirement Questionnaire
• Setting up Login IP Ranges

If you need help making these security upgrades, please get in touch