Salesforce MFA enforcement: the challenge is proving login strength, not merely enabling a factor

The calendar now depends on the release group

Salesforce began enforcement in sandboxes in July and divided production into instance release groups. Guidance published July 14 provides specific windows: R2a and R2b start August 10 and are scheduled to finish August 17 and August 13 respectively; Japan and Korea appear on September 1, and remaining unlisted instances on September 3. A generic start date is not enough. Each team must identify its org instance and check the corresponding group.

That precision matters because the rollout has already paused once. Salesforce Ben reported that enforcement was briefly halted after users with existing security keys were incorrectly asked to register new credentials. The rollout resumed under a revised schedule. The practical conclusion is not to distrust the control, but to abandon plans built around one date: monitor the official article, validate in a sandbox first, and keep communications ready for a changed window.

Standard and privileged users do not face the same rule

For internal users without elevated privileges, Salesforce accepts standard or phishing-resistant MFA. Direct-login options include Salesforce Authenticator and TOTP applications as well as compatible passkeys and security keys. Privileged users face a higher bar: the System Administrator profile or permissions such as Modify All Data, View All Data, Customize Application and Author Apex place an account within phishing-resistant MFA scope. TOTP and push approval remain useful for the standard population but do not satisfy the privileged requirement on their own.

The inventory cannot stop at profile names. Permission sets and permission set groups can grant a critical permission to people who have never been described as administrators. A safe review crosses active users, profiles and effective permissions, names an owner for every privileged account and removes temporary access that became permanent. This is OrbTrail analysis: reducing unnecessary privilege shrinks both the attack surface and the population that must adopt the strictest authentication method.

SSO is not an exemption: Salesforce must receive the evidence

In a federation, an identity provider may show that MFA completed while Salesforce still classifies the login as weak. The reason lies in the AMR and ACR signals carried in the SAML assertion or OIDC token. Salesforce documentation groups methods into three strength tiers—phishing-resistant, standard MFA, and weak or no MFA—and determines the result from a direct verifier or signals issued by the IdP. A correct policy in Entra, Okta or another provider is ineffective if the Salesforce application receives a generic, missing or incompatible assertion.

The decisive test is not a Conditional Access screenshot but a real authentication for each persona. Select one standard and one privileged user, run the complete sandbox flow, and confirm the method used, the signals Salesforce received and whether an extra registration prompt appeared. In Microsoft Entra ID, FIDO2 passkeys can be targeted by group with device-bound or synced credentials, attestation and AAGUID restrictions. Policy should reflect the group's risk and the signal the consuming application actually recognizes.

Passkeys reduce phishing but create device and recovery decisions

Passkeys and WebAuthn security keys remove the reusable secret that a fake page would try to capture. They still create operational choices. A device-bound credential provides strong control but depends on that hardware; a synced passkey improves continuity across devices while adding the sync provider to the trust model. For administrators and sensitive roles, the organization should decide whether to require attestation, restrict key models and provide a second registered credential before any device is lost or replaced.

Compatibility belongs in the design as well. Salesforce documentation says built-in authenticators cannot act as the MFA verifier in the Salesforce mobile app, Experience Cloud, API access or Data Loader OAuth login; those scenarios may need an alternate method. Recovery must not silently downgrade to a weak factor. Define who may disconnect a lost authenticator, how the person's identity is verified, when an administrator-generated temporary code is appropriate and how the event is audited afterward.

A rollout plan that avoids enforcement-day lockouts

First, determine scope. List active users, login path, primary device, mobile-app use, effective privileges and dependencies on shared accounts or automation. Separate human accounts from API-only users and validate legitimate exemptions against Salesforce guidance and, when required, Salesforce Support; the waiver permission should not become a shortcut for internal users. Then choose a standard by persona: standard MFA for the eligible population, a passkey or security key for privileged accounts, and SSO policies capable of issuing sufficient evidence.

Second, pilot the entire path. Register at least two methods for anyone who cannot lose access, then test direct login and SSO, mobile navigation, Data Loader and device recovery. Record completion time, browser or hardware failures and support cases. Third, publish short instructions before the instance window and prepare the service desk to distinguish passkey registration, standard MFA, device activation and step-up authentication; similar prompts can have different causes.

Finally, treat enforcement as a controlled change. Monitor failed logins, unenrolled users, temporary-code issuance and recovery tickets during the first hours. Maintain a protected break-glass administrator with independent credentials and a tested procedure without turning it into a daily account. Once stable, review elevated permissions and obsolete methods. The expected outcome is not only surviving enforcement, but emerging with an identity architecture that is clearer and recoverable.

Conclusion: MFA is now part of platform architecture

The 2026 requirement connects Salesforce configuration, identity design, device policy and support operations. Enabling MFA remains necessary but is no longer sufficient. An organization must demonstrate the right strength for each user, transmit that evidence correctly through SSO and recover access without reopening the door the control was meant to close. Teams that test personas and failure paths before their window turn a mandate into measurable risk reduction; teams that look only at the toggle may discover the architecture at the worst possible moment.