Salesforce Security Changes 2026: Deadlines and What To Do

Jump to a section

Overview

• Salesforce Security Overhaul 2026
• Why This Is Happening

Security changes (June 2026)

• Change 1: Email Domain Verification
• Change 2: MFA & Phishing-Resistant Authentication
• Configure & test MFA (Salesforce credentials) (part of Change 2)
• Change 3: Admin MFA Security
• Change 4: Login IP Restrictions on Profiles
• Change 5: Transaction Security Policy for Exports

Also in this guide

• Other Spring ‘26 Security Updates
• Execution Checklist
• Resources

FAQ

• FAQ — top of section

In-depth topics

• Experience Cloud & external users
• Reducing MFA friction (Authenticator)
• Should admins disable other MFA options?
• Risk-based authentication (SSO)
• Trusted devices, VPN, IP vs MFA
• SSO frequency & Salesforce’s role
• API, RPA, sandboxes & exemptions

More questions

• Does MFA still apply with SSO?
• What is phishing-resistant MFA?
• How do IP ranges affect remote teams?
• Who must satisfy the MFA requirement?
• Integration users, APIs, and automation
• SSO users and Salesforce logins together
• Authenticator or TOTP for non-admins?
• Trusted devices or VPN instead of MFA?
• What is step-up authentication?
• How many security keys for admins?
• What happens if we do not satisfy the MFA requirement?
• Unverified email domains
• Root domain vs subdomains for verification
• IP checks at login only vs every request
• Avoid locking out admins during rollout
• Shield / Event Monitoring and ReportEvent
• Can export controls block reporting users?
• Will Salesforce auto-create an export policy?

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 & Phishing-Resistant Authentication (June 2026)

Salesforce’s June 2026 security push sets a baseline security expectation for the platform:

• Email domain verification for outbound emails
• MFA for logins
• Expected login locations
• Data export policies & restrictions

Salesforce has long required MFA, but it is increasing its requirements in preparation for additional security upgrades.

What’s required around MFA:

• Internal users who open Salesforce through the browser or Salesforce mobile app will be required to use MFA in June 2026.
• Salesforce is strongly encouraging administrator accounts to go further and register phishing-resistant MFA options; see Phishing-resistant factors below, then Change 3: Admin MFA Security for requirement, recovery, SSO, and the administrator checklist.

Where is MFA not required at this time:

• Experience Cloud users are not required to use MFA for login; see FAQ: Experience Cloud & external users.
• Sandboxes do not require MFA at this time, though using MFA there is still recommended.
• API integrations: all API-based interactions are exempt from the MFA requirement, even once Require MFA is enabled for human UI login.

Automation (RPA / UI testing) is different—these are interactive identities, not API traffic. Prefer implementing MFA in the automation tool. If that is absolutely not possible, narrow exposure with Login IP Ranges on the user’s profile (and related controls), then consider a documented waiver. Read more about waiving MFA for RPA accounts.

When MFA truly cannot be used, always try to use a trusted device + network configuration to provide protection. See trusted device / network FAQ.

What does not count toward the Salesforce MFA requirement?

These methods have vulnerabilities and do not satisfy the MFA requirement:

• OTP via email, SMS, or voice
• Security questions
• VPN, trusted device, or trusted network

What counts toward the Salesforce MFA requirement?

For internal direct login, email, SMS, and voice OTP do not meet the bar above. External Experience Cloud users can differ when MFA is enabled for those sites—Experience Cloud FAQ.

Salesforce recommends registering more than one verification method per user.

Phishing-resistant factors (admins and privileged users)

Beyond the general MFA requirement, Salesforce is steering administrators toward factors that are hard to phish: hardware keys and device-based WebAuthn.

Fine for phishing-resistant posture

• Hardware security keys (WebAuthn / U2F), for example YubiKey or Google Titan, used with the real Salesforce login origin.
• Built-in platform authenticators (Touch ID, Face ID, Windows Hello) when used as WebAuthn, not as a convenience-only shortcut.

Not sufficient for phishing-resistant posture

These can still satisfy the general MFA requirement for many users; but highly privileged accounts should adopt more secure methods.

• TOTP apps (6-digit code can be typed into a fake site).
• Salesforce Authenticator push-to-approve (mistaken approvals can happen).
• Email, text, or similar

More detail: Salesforce Authenticator vs phishing-resistant MFA and Change 3: Admin MFA Security.

Admin checklist: where to configure

Configure and test MFA (Salesforce credentials)

Let’s review your org’s current settings and MFA usage.

1. Review Identity Verification (Setup)

In Setup, open Identity Verification and confirm the following.

• Verification Methods: Which factors are enabled? For a phishing-resistant–leaning rollout, ensure built-in authenticator and physical security key are allowed (alongside whatever else the org still needs during transition).
• Multi-Factor Authentication: Is it enabled? For June 2026 alignment, turn on Require MFA when the org is ready (exact wording can vary slightly by release). If it is not required yet, plan the date you will check that box.
• If people use a variety of MFA options, enable Show all verification method options on the identity verification page. If it is off, those methods still work but take users an extra click.
• Require identity verification during registration: keep this enabled
• General: skim the rest of the page in case your organization has anything else configured

2. Review current MFA usage

Now that we know what is allowed in the org settings, let’s see what users are actually using.

Open Identity Verification History (in production so you see real behavior).

• Scan recent events or create a list view filtered by team or profile to focus on administrators.
• Check which verification method each person actually used. If you see Email, that path is not meeting the strong MFA bar for direct login. For privileged users you generally want built-in authenticator or security key showing up in this history.

3. Enable MFA and preferred methods

To enable MFA, go to Identity Verification.

• Enable Require MFA if it is not already on (Salesforce is tightening enforcement toward June 2026).
• Enable built-in authenticator and/or physical security key as allowed methods
• You can enable the Salesforce authenticator option, but remember it is a more vulnerable method
• After you save, affected users are prompted to register MFA on their next successful login.

4. End-user registration (what users experience)

1. User logs in with Salesforce username and password.
2. Salesforce prompts them to register an MFA method. Possible options are:
   • Built-in authenticator: user enters device PIN or biometrics.
   • Physical security key: user inserts or taps the key.
   • Salesforce Authenticator: user pairs the mobile app and receives push notifications or codes.
3. They complete the on-screen wizard for the method they chose until registration finishes.
4. On later logins, after entering the correct username and password users will be prompted to verify with this second factor.

5. Review MFA exemptions

In profiles and permission sets, open System Permissions and search for Waive Multi-Factor Authentication for Exempt Users. Remove it except for documented automation. Most orgs never set this, but some orgs may have such permissions.

In production: Consider running a small pilot group before org-wide enforcement and keep MFA access recovery steps handy for anyone who loses a factor.

Change 3: Admin MFA Security

Step-by-step setup in Salesforce—Setup → Identity Verification, enabling built-in authenticators and physical security keys, Require MFA, Identity Verification History, end-user registration, exemptions, and pilot testing—is in Configure and test MFA (Salesforce credentials) in Change 2 above.

Requirement, recovery, and SSO

Highly privileged accounts should not rely on TOTP alone or on Salesforce Authenticator push-to-approve as the only factor. See this rationale post for why Salesforce is pushing stronger methods.

Phishing-resistant factors in Change 2 above lists what counts as phishing-resistant versus only meeting the general MFA requirement.

Plan for at least two phishing-resistant methods per person. You do not need to disable other authentication methods, but admins should begin to shift to the more secure methods.

So what is the MFA requirement for admins?

Phishing-resistant MFA for admins is not a hard requirement from Salesforce at this time, but it is strongly encouraged alongside the general MFA requirement. Whether to turn off weaker verification methods for the whole org (or only for admins) is a policy and lockout-risk decision—see Should admins have all other MFA options disabled?.

Admin access recovery

Salesforce recommends admin access recovery discipline:

Make sure your access recovery plan includes steps to help you and your fellow admins if you lose access to your regular verification method(s). Consider these best practices:

• Each admin should register at least two verification methods.
• Keep a backup security key in a secure place at work.
• Establish at least two accounts that have permissions to manage users and MFA settings. This way, if one account is locked out, you can use the other account to restore access.

If a user’s verification method stops working, disconnect it in admin tooling and have them re-register. If they lose access entirely, admins can issue temporary login codes; follow Generate Temporary Verification Codes for MFA.

Admins and SSO

Salesforce recommends that admins retain direct Salesforce login with username and password (with MFA in the product), rather than relying on SSO alone for break-glass access:

Admins should always be able to log in directly to your Salesforce products using their username and password. We don’t recommend enabling SSO for Salesforce admins because they won’t be able to log in if there’s an outage or other problem with your SSO implementation.

Enable MFA for administrator accounts directly in Salesforce instead of SSO-only for admins.

Administrator action checklist

• Follow Configure and test MFA (Salesforce credentials) in Change 2 to enable built-in authenticators and security keys in Identity Verification, require MFA for direct UI logins when ready, and validate the rollout (sandbox or pilot).
• Inventory all admin users and their MFA usage (Identity Verification History in production).
• Register at least two phishing-resistant methods per admin.
• Budget for hardware keys where needed.

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

Profiles should define approved login IP ranges.

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.
• By default, ranges are checked at login only. For stronger control, enable Enforce login IP ranges on every request in Session Settings.

Change 5: Transaction Security Policy for Exports - Shield and Event Monitoring customers only

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 in-scope users.

FAQ

Does this requirement apply to Experience Cloud MFA and external users?

MFA is not required for Experience cloud users. If you do enable MFA for them, Salesforce explicitly allows SMS as a verification method for external users in supported configurations so you can add friction without forcing the same factor mix as employee org access.

If you implement MFA for your customer or partner Experience Cloud sites, external users are able to log in using SMS text messages as a verification method. This option allows you to provide an extra layer of security for your sites while maintaining ease of access for users who don’t interact with business-critical data. See this topic in Salesforce Help for full details.

—Salesforce, SMS as a verification method for external Experience Cloud users

How can we reduce friction for users?

Question 3 — Reduce prompts when logging in from a trusted location: Salesforce recommends Salesforce Authenticator automation (trusted locations, repeated-location learning). See how to use it at Automate Multi-Factor Authentication with Salesforce Authenticator.

Should admins have all other MFA options disabled?

No, keep them as back-ups.

Verification methods in Setup → Identity Verification are configured at the org level. Turning off options such as TOTP or Salesforce Authenticator removes them for direct-login users broadly, not for administrators in isolation. If most employees still rely on those methods for legitimate MFA, disabling them without a full migration plan can cause outages and help-desk load.

For administrator accounts specifically, the security goal is to have phishing-resistant factors (hardware keys and WebAuthn platform authenticators) registered and used in practice. Salesforce’s own recovery guidance assumes multiple registered methods (for example, two keys, or a key plus a platform authenticator). If you disable every weaker option before every admin has two working phishing-resistant methods and a tested recovery path, you increase lockout risk.

A typical rollout is: inventory with Identity Verification History, require admins to add keys or built-in WebAuthn, audit until weak factors disappear from admin usage, then—only if the business accepts the tradeoffs—tighten which methods remain enabled org-wide. SSO-heavy customers may additionally constrain admin MFA at the identity provider.

Does MFA still apply with SSO?

Yes. Configure strong MFA at the identity provider for every SSO sign-in, align direct-login MFA for any remaining Salesforce credentials, and read the consolidated SSO guidance (every-login recommendation, Salesforce’s non-enforcement stance on your IdP today, disabling Salesforce logins for SSO users, admin break-glass) in SSO: every-login MFA, Salesforce’s role, disabling Salesforce credentials, admins.

Our SSO has risk-based rules, does this satisfy the MFA requirement?

Salesforce describes risk-based authentication as continuously analyzing risk from user, device, and access signals and requiring extra challenges when risk is high.

If you’ve already integrated a risk-based authentication system with your SSO solution, your implementation complies with the MFA requirement. If you’d like to consider this type of solution, there are a number of technology providers that you can work with.

—Salesforce, MFA FAQ

This is satisfied at the identity provider (and related security products), not by toggles alone under Salesforce Identity Verification.

Do Trusted Devices and IPs work on their own instead of MFA?

Device certificates, MDM-managed trust, VPN, ZTNA, trusted networks, and IP allowlists do not provide MFA-level protection on their own.

Profile Login IP Ranges and Org Trusted IP Ranges are still best practice for narrowing automation or service accounts, but they do not replace MFA for in-scope human interactive users.

Salesforce documents a combined trusted-device and trusted-network model that can provide equivalent protection only when MFA at the IdP or in Salesforce is not feasible—conditions are spelled out in the MFA FAQ

How often should SSO prompt for verification?

Salesforce strongly recommends requiring a strong verification method every time the user signs in to SSO.

Salesforce states it will not enable MFA on your SSO provider for you, and that it does not currently block Salesforce or force MFA challenges solely because SSO lacks MFA—that policy could change. Quote:

We won’t take action on your behalf to enable MFA for your SSO identity provider. Nor do we have plans to block access to Salesforce products or trigger MFA challenges if your SSO service doesn’t require MFA. This policy could change in the future.

—Salesforce, MFA FAQ

Non-admin SSO: Salesforce recommends disabling logins with Salesforce credentials for SSO users so they cannot bypass the IdP; see Help Disable Logins with Salesforce Credentials for SSO Users (linked from the same FAQ hub). Communicate the SSO entry URL.

Admins: Salesforce recommends against SSO-only for Salesforce admins; keep direct login plus MFA in the product for emergency use.

Admins should always be able to log in directly to your Salesforce products using their username and password. We don’t recommend enabling SSO for Salesforce admins because they won’t be able to log in if there’s an outage or other problem with your SSO implementation.

—Salesforce, MFA FAQ

What all is exempt from the MFA requirement?

API / integration: Salesforce states API-based interaction does not require MFA in the MFA-requirement sense; do not avoid turning on Require MFA for human UI out of fear for integrations. Still harden integration users (scoped OAuth, secrets rotation, monitoring)—MFA scope is a separate control.

RPA / UI automation / automated testing: Prefer MFA inside the tool. If not possible, use permission set with Waive Multi-Factor Authentication for Exempt Users, document the exception, and add Login IP Ranges on the automation user’s profile (and other host hardening).

Org types: Production sandboxes — MFA requirement not required for now. Scratch orgs, Trailhead Playgrounds — out of scope. Developer and Partner production orgs — not required, recommended if real data or IP. On-premises MuleSoft and Tableau Server — exempt from this Salesforce cloud product MFA requirement.

Mobile: Salesforce mobile app interactive login is in scope like browser UI.

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.

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. Remember that IP controls are not a substitute for MFA for users who must meet the MFA requirement.

Who must satisfy the MFA requirement?

Internal users with browser or Salesforce mobile app interactive access are the primary in-scope population for the standard MFA bar. Experience Cloud external users, API traffic, automation waivers, and non-production org types are covered in the dedicated FAQs: Experience Cloud and API / RPA / org types.

What about integration users, APIs, and automation?

See API, RPA, sandboxes, scratch orgs, dev/partner orgs, on-prem exempt, Waive Multi-Factor Authentication for Exempt Users—includes exact permission name, permission set versus profile Login IP Ranges, and sandbox/scratch/dev-partner scope.

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

Enforce MFA at the IdP for SSO users, and enforce MFA in Salesforce for direct logins. Validate both paths.

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

Non-admins: Salesforce Authenticator and TOTP apps appear on Salesforce’s acceptable-methods list for direct product MFA (MFA requirement table in Change 2). Admins: do not treat Authenticator push or TOTP alone as phishing-resistant—use WebAuthn keys or platform authenticators per Change 3: Admin MFA Security. Full split: Salesforce Authenticator vs phishing-resistant MFA. Email, SMS, and voice still do not satisfy the standard internal bar; Experience Cloud external SMS is separate: Experience Cloud FAQ.

Do trusted corporate devices or VPN satisfy MFA by themselves?

No—not alone. Combined models and unmanaged-device-on-VPN branches are summarized in Trusted devices, networks, VPN/ZTNA, and IP controls with pointers into the MFA FAQ.

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 we do not satisfy the MFA requirement?

Salesforce states that MFA for direct logins has been enforced since February 1, 2022, and that if SSO and/or product MFA does not meet the requirement, you are out of compliance with contractual obligations under the MSA and you assume the risk of access without MFA. See the MFA FAQ for the exact wording.

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.

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.

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

Resources

• Salesforce multi-factor authentication FAQ — authoritative Q&A on scope and methods for meeting the MFA requirement
• SMS as a verification method for external Experience Cloud users
• Generate temporary verification codes and MFA access recovery
• MFA Requirement Questionnaire
• Login IP ranges (Salesforce Help)

If you need help making these security upgrades, don’t hesitate to get in touch