Salesforce Security Enforcement in 2026: MFA Everywhere and the Network You Connect From
The Year Advice Became Enforcement
Salesforce security guidance has historically been contractual rather than technical. MFA was "required" by the Master Subscription Agreement for years, but admins could still switch it off. Network hygiene lived in Trailhead modules nobody opened. In 2026 both stopped being optional.
Two changes matter most if you run an org today. The first takes the opt-out away from multi-factor authentication: the org-wide setting switches on, greys out, and the permission that used to waive it stops working. The second works one layer down, at the network level - it freezes accounts and kills OAuth tokens when traffic shows up from anonymizing VPNs, proxies, or IP addresses flagged as high-risk.
They are unrelated features with a shared characteristic: enforcement happens on Salesforce's side, automatically, with no configuration flag to postpone it. This article covers what actually changes for existing users, who gets locked out and why, and what the remediation path looks like when it happens.
Part 1: MFA Enforcement for All Direct UI Logins
What Actually Changed
The Session Settings checkbox labeled "Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org" has been sitting there for years as an optional control. Enforcement makes it permanent: the setting is ticked, greyed out, and admins can no longer turn it off. If you can't untick that checkbox in an environment, enforcement is already live there.
Two Layers, Not One
The enforcement wave contains two distinct requirements that are easy to conflate:
Standard MFA for all internal users: Every employee user logging in through the UI - direct login or SSO - must complete a second factor. There's no org-wide opt-out left.
Phishing-resistant MFA for privileged users: Anyone with the System Administrator profile, or with Modify All Data, View All Data, Customize Application, or Author Apex, needs a phishing-resistant method: a platform authenticator (Touch ID, Face ID, Windows Hello) or a FIDO2/WebAuthn security key. A TOTP app alone no longer satisfies the requirement for this group.
The Timeline (and Why It Moved)
Sandbox enforcement began on July 10, 2026 and production enforcement started on July 20, 2026, rolling out in waves by instance and release group into early September. The dates shifted more than once during the program - the original sandbox and production dates were both pushed back - which matters mainly as a lesson: announced enforcement dates for this program were guidance, but the end state was never in question. Orgs that treated the first published date as the deadline had breathing room; orgs that treated the delays as a reprieve did not.
Who Is In Scope (and Who Is Not)
In scope:
Internal employee users with standard Salesforce licenses
Both production and sandbox orgs
Direct UI logins through the standard login page
SSO logins - Salesforce inspects the identity provider's signals and challenges the user itself if MFA is not confirmed
Not in scope:
Experience Cloud external users (customers and partners)
Developer Edition, trial, and scratch orgs
Pure API logins that never render a login page
Headless OAuth flows - JWT Bearer and Client Credentials - because nobody logs in through a page
The line that trips people up: it is not "human vs. integration," it is "logs in through a page vs. doesn't." An integration user going through the OAuth Web Server flow still hits a login page, and that step counts. The same integration moved to JWT Bearer is unaffected. Exemption is determined by actual login behavior, not by a checkbox on the user record.
Who Gets Caught Out
SSO orgs whose identity provider stays silent
Salesforce reads standard authentication signals (AMR claims per RFC 8176 and ACR claims) from the SAML assertion or OIDC token to confirm MFA was performed upstream. An IdP that enforces strong MFA but never passes those claims gives you the worst of both: users authenticate properly at the IdP, then get challenged all over again by Salesforce. The fix is IdP-side configuration, not Salesforce-side. Orgs that relied on a generic "multiple authentication" claim value were caught out when it was retired mid-2026, producing prompts with no configuration change on the customer side.
Automated test suites driving the UI
Selenium, Provar, and similar tools that log in through the browser hit the MFA challenge like any user. Compounding this, the login page itself changed to a two-step flow - username first, then password or passkey on a second screen - which breaks selectors and page-object models written against the single-page form. Test automation typically needs both an authentication rework and a selector rework.
Accounts relying on the waiver permission
The "Waive Multi-Factor Authentication for Exempt Users" permission (API field PermissionsBypassMFAForUILogins) stops exempting anyone automatically. Users holding it are prompted to enroll like everyone else. The permission was also removed from the Profile and PermissionSet schema for orgs without an approved extension, which turns metadata deployments referencing it into deployment failures.
Privileged users with only a TOTP method registered
An admin who registered an authenticator app years ago and considers themselves covered is not covered under the phishing-resistant requirement. They are prompted to enroll a qualifying method, and in the enforced state a privileged user with no qualifying method registered is blocked at the login screen rather than warned.
Consultants, contractors, and partner developers
Anyone working across many client orgs now needs a registered method in each one. Shared credentials - already a bad practice - become unworkable, because the second factor is bound to a device or authenticator that one person holds.
Single-admin orgs
A sole administrator who loses access to their registered device has no colleague with Modify All Data to reset it. The recovery path runs through Salesforce Support and takes as long as Support takes.
How to Resolve MFA Problems
For SSO configurations:
Verify the IdP passes ACR or AMR claims confirming which authentication methods were used
For privileged users, ensure the claim specifically indicates a phishing-resistant method - a generic "MFA happened" signal is not sufficient for that group
Confirm the correct endpoint version is configured for custom OIDC integrations
Test with a privileged account in a sandbox before assuming production will behave the same
For integration and automation accounts:
Migrate interactive OAuth flows to JWT Bearer or Client Credentials wherever the tool supports it - this removes the account from scope entirely rather than seeking an exception
Run test suites under least-privileged accounts scoped to the objects under test, which also avoids the phishing-resistant requirement that attaches to privileged permissions
For the residual accounts that genuinely cannot avoid a UI login, request an exemption through a Salesforce Support case - this is an approval process, not a self-service toggle, and Support processing time is part of the schedule
Update page objects and login helpers for the two-step username-then-password flow
For user readiness:
Pull the list of privileged users by permission, not by profile alone - permission sets grant Modify All Data and Author Apex just as effectively
Cross-reference that list against registered verification method types to find anyone holding only TOTP or SMS
Register a backup method for every admin before it is needed, and ensure at least two people in the org hold administrative access
Audit metadata for references to the waiver permission before the next deployment fails on it
Part 2: Getting Blocked for the Network You Connect From
What Actually Changed
Since November 2025, Salesforce has been automatically shutting down suspicious activity coming from anonymizing VPNs, proxies, and high-risk IP addresses. In April 2026 that coverage expanded to all Connected App and API traffic. The behavior is not a warning or a step-up challenge - it is containment applied at detection time.
What Happens on Detection:
The affected user account is frozen
All OAuth refresh tokens granted to that user are revoked
A "Salesforce Security notification" email goes to the org's Security Contacts, the affected user, and - if no Security Contact is configured - every user with Modify All Data on the instance
The user can't fix this themselves - an admin has to step in
The part that catches teams out: containment kicks in the moment something is detected. Users lose access before any human reads the notification email. There's no grace window, no review queue, and no way to pre-approve a network range in setup. Trusted IP ranges and login IP restrictions are separate, admin-controlled features - they won't whitelist an address out of this.
Who Gets Caught Out
The detection goes after anonymizing infrastructure, but what sets it off overlaps heavily with how people normally work:
Developers and consultants on commercial VPNs
Consumer VPN services exist to anonymize traffic - that's the whole product. Leave one running out of habit while an IDE syncs metadata or a mobile app polls the API, and it produces exactly the pattern the detection looks for. A corporate VPN ending at a known company egress is a different story; a commercial anonymizer isn't.
Distributed and offshore teams
Teams spread across regions often route through VPNs for latency, access, or policy reasons. If those services share IP pools with anonymizing providers, the traffic looks identical to what the detection is hunting.
Middleware and CI/CD on shared cloud infrastructure
Integration platforms, ETL jobs, and pipeline runners on shared hosting can be assigned addresses from ranges with reputational history. The account being frozen here is the integration user, and the failure mode is a nightly job that stops running with no code change to explain it.
Mobile and packaged applications
Access through a mobile app counts as Connected App traffic. A packaged product whose mobile client routes through an intermediary inherits the risk on behalf of every customer using it.
Anyone with Tor or privacy tooling in the path
Browser-level privacy extensions and onion routing are unambiguous triggers.
The worst case: the org's only administrator is the one frozen. With no second account holding Modify All Data, nobody in the org can perform administrative actions, including unfreezing users, until Salesforce Support restores access. This single scenario is the strongest argument for maintaining more than one administrator account.
How to Restore Access
The remediation sequence:
Look before you unfreeze. In Setup, open Session Management and check the session origin, authentication method, and connected app details for that user. Watch for IP addresses from places the user has never worked from, connected apps nobody recognizes, or API calls at hours they don't work. Containment fires on network reputation, but the account may also be genuinely compromised - unfreezing a real intrusion is worse than the outage.
Check that the activity looks like this user's normal pattern. If it doesn't, treat it as an incident, not a false positive.
Unfreeze the account from the standard freeze/unfreeze screen.
Get the user to reset their password and log back in.
Get them to reauthorize every connected app - containment killed the refresh tokens, so anything tied to that user stays broken until it's re-consented.
Make sure they're off the anonymizing service before they reauthorize. Reconnect from the same network and the whole thing happens again from the top.
How to Not End Up Here
Configure a Security Contact for the org. Without one, the notification scatters to everyone with Modify All Data instead of reaching the people who handle incidents.
Inventory the egress path of every integration - middleware, ETL, CI runners, scheduled jobs - and confirm none traverse shared or reputationally questionable ranges.
Give integrations static, dedicated egress addresses where the hosting platform supports it, rather than shared pools.
Publish a clear internal rule that commercial VPN clients must be off when connecting to Salesforce, and explain why - most triggers are habit, not policy violation.
Keep at least two admin accounts, on separate devices and ideally separate networks.
Treat the security notification email as a real alert channel, not something that lands in a shared inbox nobody opens.
Where the Two Changes Compound Each Other
Handled separately these are two manageable projects. They intersect badly in a few specific situations:
Token revocation meets re-enrollment: A frozen user's refresh tokens are gone. If that user is also halfway through MFA enrollment, or their only registered method sits on a device they no longer have, that's two problems to fix one after the other - and both need someone with admin access.
The privileged user is the bottleneck in both: Phishing-resistant MFA applies to exactly the users who can unfreeze other accounts. An org that concentrates administrative permission in one or two people has concentrated both failure modes in the same place.
Integrations fail for two different reasons that look identical: A nightly job stopping could be an interactive OAuth flow now blocked by MFA, or an integration user frozen for network reasons with its tokens revoked. The symptom - authentication failure at 2am - is the same. Diagnosis starts with checking whether the user record is frozen, which distinguishes them immediately.
Remote admins hit both at once: An administrator working from a commercial VPN who has not yet registered a phishing-resistant method can be frozen for the network and blocked for the method in the same session, with no path forward that does not involve another person or Support.
Where Teams Get It Wrong
Treating SSO as automatic compliance: Strong authentication at the IdP means nothing to Salesforce if the claims never arrive. Check the signals, don't assume them.
Auditing privileged users by profile only: Permission sets hand out Modify All Data and Author Apex just as effectively as a System Administrator profile. A profile-based audit misses people.
Assuming integration users are exempt by category: Exemption follows login behavior. An integration authenticating through a UI flow is in scope regardless of what the account is called.
Leaving the exemption request until the deadline: Support approval is a process with a queue. Filing after enforcement means the account is already blocked while the case is open.
Ignoring the login page redesign: The two-step username-then-password flow breaks UI automation independently of MFA. Two separate fixes, often discovered as one confusing failure.
Running a single administrator: Both changes have failure modes whose only remedy is another administrator. One admin is a single point of failure for the entire org.
No Security Contact configured: The containment notification is the only signal that an account was frozen. Without a designated recipient it reaches a group that may not act on it.
Unfreezing without investigating: Containment sometimes fires on genuine compromise. Restoring access reflexively hands the org back to whoever triggered it.
Restoring access without reauthorizing connected apps: Unfreezing the user does not restore revoked refresh tokens. The user logs in fine and every integration stays broken.
Documenting nothing: These events recur. An org without a written runbook for "user frozen by automated containment" re-solves the same problem every time, usually under time pressure.
Readiness Check
Questions worth answering before an incident rather than during one:
Is the MFA setting greyed out in this org?
If yes, enforcement is already active here. If not, it will be.
Does every privileged user have a phishing-resistant method registered?
Check by permission, not profile. Check for a second method as well as a first.
Does the identity provider pass authentication claims Salesforce can read?
Verify for a privileged user specifically - the bar is higher for that group.
Which accounts still log in through a UI flow that could be headless?
Each one migrated to JWT Bearer is one fewer exemption to justify.
Does the org have more than one working administrator?
On separate devices, with separate registered methods.
Is a Security Contact configured?
This determines who learns that an account was frozen.
What is the egress IP path for every integration?
Unknown answers here are the ones that surface at 2am.
The Reality Check
Enforcement Is Not a Feature to Evaluate
Most platform changes come with a decision attached: adopt now, defer, or skip. These do not. The MFA setting cannot be unchecked, and network containment has no configuration surface at all. The only real decision is whether the org discovers the consequences on its own schedule or on the platform's.
What Actually Reduces Risk:
Move every integration that can be headless off interactive login flows - this shrinks the exposed surface rather than managing it
Distribute administrative access across at least two people, devices, and networks
Verify identity provider claims rather than assuming upstream MFA is visible to Salesforce
Know the egress path of every system that talks to the org
Write the recovery runbook before it is needed, because it will be needed while someone is locked out and under pressure
The Broader Shift:
Both changes reflect the same underlying move - from perimeter and contract toward identity and network reputation as the enforced controls. The practical consequence for teams is that authentication and connectivity are no longer environment setup handled once during onboarding. They are operational concerns with their own failure modes, their own alerting requirements, and their own recovery procedures.
Orgs that treat these as one-time compliance exercises will handle each incident as a novel emergency. Orgs that treat them as permanent operational surface - monitored, documented, with recovery paths rehearsed - will handle them as routine. The difference shows up not when the changes take effect, but on the first ordinary Tuesday when an integration user is frozen and the person who knows how to fix it is on holiday.
The platform stopped asking. What remains within any team's control is whether the resulting lockouts are a recurring surprise or a documented procedure - and that is decided well before the first account is frozen.
