Mandatory MFA in Salesforce arrives in 2026 and changes the game: what was once a recommendation for years becomes a permanent rule — and it brings changes that go far beyond a simple second factor. Admin access can be blocked, reports start asking for a fresh check, and older integrations risk stopping overnight. You can confirm the deadlines in the official Salesforce documentation.
This guide clearly explains the changes, when they occur, and what your team should do before the deadlines. No scaremongering: just a plan.
1. Identity: mandatory MFA for all UI users
Salesforce has removed the ability to turn MFA off. The “Require MFA for all direct UI logins” option in Setup > Session Settings is permanently set to on and locked for editing in both production and the sandbox. The requirement covers all internal (employee-license) users, on both direct and SSO logins, and now also includes sandboxes (previously excluded).
There are three practical consequences. First, the “Waive MFA for Exempt Users” permission stops working automatically — users who relied on it will be forced to register a method at first login. Second, the rule covers all UI logins, including mobile and desktop browsers; only API-only access remains exempt. Third, and critically for SSO, it isn’t enough for your identity provider (IdP) to require MFA — it must communicate this to Salesforce via the standard ACR/AMR signals in the OpenID Connect token or SAML response. If the signal doesn’t arrive, Salesforce intercepts the login and requires its own MFA.
2. Administrators: phishing-resistant MFA
For privileged users, the bar rises. The rule doesn’t apply only to the System Administrator profile: it covers any user with permissions such as Modify All Data, View All Data, Customise Application, Author Apex, or Manage Users.
For this group, only WebAuthn/FIDO2 methods are accepted: built-in device authenticators (Windows Hello, Touch ID, Face ID) or physical security keys (YubiKey, Google Titan). Methods based on shared codes or insecure channels are blocked: TOTP apps like Google or Microsoft Authenticator, SMS and voice calls (due to SIM-swapping risk), and email codes.
In practice, an admin who tries to sign in without a registered FIDO2 method is sent to a lock screen that requires immediate registration of a key or biometrics; previous TOTP methods are ignored. In SSO environments, the IdP must require FIDO2/WebAuthn and report the authentication strength; Salesforce denies access even if the IdP allowed it. That’s why we always recommend a break-glass account outside SSO, with a physical key stored in a safe, to guarantee access if the IdP fails.
3. Data: protection on reports, anomalies and exports
Reports and dashboards are prime targets for data exfiltration. Salesforce introduced time-based re-authentication (step-up authentication): whenever a user views, runs, or exports a report, the system checks how long it has been since they last validated their identity. The default window is 120 minutes, configurable between 2 and 120. If the user has no MFA method and the fallback code can’t be sent or verified, the action is blocked — the system prioritises data protection.
In parallel, an anomaly-detection model analyses each user’s historical behaviour (which reports they access, at what times, what volume and frequency). Faced with unusual manners — say, a massive customer-list download at an atypical hour — it triggers an immediate challenge and resets the remaining time window.
Finally, for customers with Salesforce Shield or Event Monitoring, a Transaction Security Policy (TSP) now requires re-authentication on exports above 10,000 records. Managing these policies requires the new Modify Transaction Security Policy permission, combined with the Customise Application permission. And connections from high-risk networks, anonymous proxies, or IP-masking VPNs result in the account being frozen and tokens being revoked, with an email alert sent to both the admin and the user.
4. The critical point: integration accounts with an Admin profile
This is where many teams will be caught off guard. Integrations and CI/CD tools — Jenkins, GitHub Actions, Copado, Bitbucket, MuleSoft — were often set up with the username-password flow and tied to an Administrator profile. Because that profile falls into the privileged category, it now requires phishing-resistant MFA in any UI flow. And a script can’t place a finger on a biometric reader or plug a physical key into a cloud server: the connection is rejected.
The impact is direct. Deploy service accounts require the Author Apex permission, which also makes them privileged, causing the pipeline to stall during authentication. And syncs that extract data by simulating UI navigation can be frozen by step-up, causing timeouts.
The fix is to remove the Admin profile from bots and adopt system-appropriate authentication: use Salesforce Integration Licenses (the first two are usually free and block UI login), migrate to OAuth 2.0 JWT Bearer or Client Credentials flows, which rely on certificates and tokens instead of passwords, and apply least privilege with integration-specific profiles.
5. Enforcement timeline
Rollout is phased.
6. Preparation checklist
We recommend four steps:
- 1. Audit and inventory: identify who still logs in without MFA and map profiles with critical permissions (using SOQL or the Optimiser); for legitimate exceptions such as RPA, open a support case before the deadline.
- 2. Equip and enable passkeys: distribute FIDO2 keys to admins and enable passwordless login with passkeys for standard users.
- 3. Define access recovery: prepare internal generation of temporary verification codes and the break-glass account.
- 4. Pre-register and test: communicate internally, ask users to register methods ahead of time, and migrate CI/CD pipelines to secure OAuth.
Conclusion
These changes are demanding, but the right perspective is positive: with proper preparation, your organisation becomes more resilient to attacks and better aligned with security best practices. The difference between a smooth transition and a complete loss of access lies in planning and in the time you still have left.
At Biz2People, we help you assess, equip your teams and migrate your integrations before the deadlines, without disrupting operations. Book a Salesforce security assessment and prepare your org with confidence.
