how do i manage Salesforce MFA Enforcement 2026: Lessons from a Real-World Implementation
Published by Zon Projects | June 2026
If you've been tracking Salesforce's security roadmap for 2026, you'll know that MFA enforcement is no longer optional. Production enforcement for standard users begins 20th July 2026, with phishing-resistant MFA for privileged users already rolling out from 1st July. Over the past few weeks, we've been working through this with a client — and the experience surfaced a number of issues that aren't immediately obvious from reading Salesforce's documentation alone.
This post shares what we found, what we fixed, and what others should be aware of before enforcement hits their org.
The Setup
Our client is a mid-size organisation with a Salesforce org used across multiple internal teams. All users authenticate via Azure Entra ID SSO — no native Salesforce logins for standard users. A small number of external administrators (including ourselves) log in directly via Salesforce UI.
On the surface, this looked like a straightforward SSO + MFA story. In practice, it wasn't.
Issue 1: SSO Alone Doesn't Satisfy the MFA Mandate
The first thing to understand — and it catches a lot of people out — is that SSO without explicit MFA signalling does not satisfy Salesforce's requirement.
Salesforce relies on the identity provider (in this case Azure) passing AMR (Authentication Methods Reference) and ACR (Authentication Context Class Reference) claims in the SAML assertion. Without these, Salesforce treats every SSO login as unauthenticated, regardless of what Azure actually did during authentication.
The fix required two changes on the Azure side:
Adding ACR and AMR claims to the SSO Enterprise Application
Creating a Conditional Access Policy (CAP) scoped to the Salesforce SSO app and the relevant user group, enforcing phishing-resistant MFA for privileged users
We ran the CAP in Report Only mode for several days before switching to Enforce — a sensible approach that confirmed no unexpected issues before going live.
Issue 2: The Azure IP Whitelist Gap
This is the one that most organisations will miss.
Our client, like many, has IP whitelist rules in their Azure Conditional Access policies. Users inside the trusted IP range are not challenged for MFA when logging into Azure/Office 365. Reasonable enough — but it creates a critical gap for Salesforce.
If Azure doesn't challenge a user for MFA (because they're on a trusted IP), it doesn't generate an AMR/ACR signal. No signal reaches Salesforce. Salesforce sees an SSO login with no MFA confirmation and, under the new enforcement, will either prompt the user to enrol in Salesforce-native MFA or block them entirely.
In our client's case, the situation was more acute because native Salesforce login was disabled org-wide (isLoginWithSalesforceCredentialsDisabled: true). This means users can't fall back to Salesforce-native MFA enrolment — they would simply be unable to log in.
The fix: Either remove IP exclusions specifically for the Salesforce SSO Enterprise Application, or create a separate CAP scoped to Salesforce that enforces MFA regardless of IP location.
Issue 3: Privileged Users Need Phishing-Resistant MFA — Not Just Any MFA
For users with the System Administrator profile, or any of these permissions — Modify All Data, View All Data, Customize Application, Author Apex — standard MFA is not sufficient. Salesforce requires phishing-resistant MFA specifically.
This means:
✅ Built-in authenticators (Touch ID, Face ID, Windows Hello)
✅ Hardware security keys (YubiKey, FIDO2/WebAuthn)
✅ Cloud-synced passkeys in a FIDO2-compliant password manager (Bitwarden, 1Password, iCloud Keychain)
❌ Salesforce Authenticator push notifications
❌ Google Authenticator / TOTP codes
❌ SMS codes
For our external admin access, we registered a Bitwarden passkey directly against the Salesforce org — confirmed compliant and independent of the client's Azure SSO configuration.
Issue 4: Creating a Super User Profile Without Triggering High Assurance Requirements
One requirement that emerged was the need for a Super User profile — a group of internal power users who needed broad access but shouldn't be subject to phishing-resistant MFA requirements.
The solution was to clone the System Administrator profile and remove the specific permissions that trigger both the phishing-resistant mandate and High Assurance session requirements:
ManageAuthProviders
ManageLoginAccessPolicies
ManageCertificates
AuthorApex
ManageSandboxes
ModifyMetadata
ModifyAllData (dependent on ModifyMetadata)
ManageUsers
Packaging permissions
With these removed, the profile falls into the standard user MFA tier — Azure SSO with standard 2FA is sufficient, and users won't be prompted for phishing-resistant methods.
One dependency to watch: Salesforce enforces permission dependency chains. Removing ManageLoginAccessPolicies requires simultaneously removing ManageUsers, CreatePackaging, PublishPackaging, and others that depend on it. Removing ModifyMetadata requires removing ModifyAllData and InboundMigrationToolsUser. Plan these removals carefully.
Issue 5: The Temporary Verification Code Problem
An unexpected discovery: even with System Administrator profile and the ManageTwoFactor permission assigned via a permission set, generating Temporary Verification Codes for users requires a High Assurance session.
If skipSFAWhenMFADirectUILogin is set to true (which it was in our client's org), Salesforce skips the step-up authentication challenge at login — meaning the session never reaches High Assurance level, and the Temporary Verification Code option is visible but blocked.
This is an org-wide setting, so changing it requires careful consideration of the impact on other users. It remains an open item for us.
Key Takeaways
SSO is not a free pass — your IdP must pass AMR/ACR claims or Salesforce will not recognise the MFA as having occurred.
IP whitelists in Azure are a hidden risk — if users aren't challenged for MFA on trusted IPs, no signal reaches Salesforce.
Native login being disabled compounds the IP whitelist issue — users can't fall back to Salesforce MFA if Azure doesn't signal correctly.
Password managers count — provided they store a FIDO2/WebAuthn passkey, not just credentials alongside a TOTP code.
Profile design matters — removing the right permissions from a cloned profile keeps power users out of the phishing-resistant tier.
Run your CAP in Report Only first — a few days of monitoring before enforcing saved us from any unexpected user impact.
Enforcement Dates (Production)
User TypeEnforcement DatePrivileged users (Sys Admin, ModifyAllData etc.)1st July 2026 (staggered ~30 days)All standard employee users20th July 2026 (staggered ~30 days)
If you're working through Salesforce MFA enforcement and need a hand, get in touch with the team at Zon Projects.