Your Users Can Log In. That Is Not Proof Your Org Passed MFA Enforcement.

What changed with Salesforce MFA enforcement on July 20, 2026?

On July 20, 2026, Salesforce began enforcing multi-factor authentication for all employee users in production orgs. Enforcement rolls out in staggered waves, not a single cutover. Users without a registered second factor are prompted to enroll at next sign-in and cannot proceed until setup is complete. The exempt-user waiver shortcut is retired.

This is not a policy you opt into on your own timeline anymore. The "Waive Multi-Factor Authentication for Exempt Users" shortcut that admins leaned on for service accounts and edge cases is gone. If an automation or a specific user relied on that waiver, it stops working the moment your org's wave activates, and you find out when someone can't get in.

Why isn't a successful login proof of MFA compliance?

Because enforcement activates per org in waves, a user who logged in this morning may simply be in an org whose wave has not fired yet. A silent login proves nothing about compliance. The only reliable check is your org's MFA enforcement status in Setup, not whether people can currently sign in.

The trap is reasoning from the user experience backward. Everyone logs in, no one complains, so the assumption is the org is fine. Then the wave hits during a sprint, or worse during a release window, and the same users who were fine yesterday are now stuck at an enrollment screen. Check the state in Setup and treat the login experience as unreliable evidence.

Why do SSO orgs still get caught by Salesforce MFA?

Salesforce still enforces its own MFA when single sign-on handles authentication if the identity provider does not pass AMR/ACR signals confirming a second factor. Your users authenticate with MFA at Okta, Entra ID, or Ping, but Salesforce never sees the proof, so it prompts for its own second factor on top of the one they already completed.

This is the failure mode that bites large orgs. The security team is certain MFA is covered because the IdP enforces it, and they are right that the user did MFA. The problem is Salesforce cannot read intent, it reads the assertion. If the assertion does not carry an authentication-context value saying a second factor happened, Salesforce assumes single-factor and steps in. Best case your users get a confusing double prompt. Worst case, accounts without a registered Salesforce second factor get blocked mid-rollout.

How do you confirm AMR/ACR signals are actually reaching Salesforce?

Trigger a real SSO login into a test org and inspect the SAML assertion or OIDC token the identity provider sends. Confirm it carries an authentication-context value indicating MFA was performed, the AMR or ACR claim. If that value is missing, Salesforce treats the session as single-factor and enforces its own prompt regardless of what the user did at the IdP.

For SAML, look at the AuthnContextClassRef in the assertion. For OIDC, look at the amr and acr claims in the token. You want to see a value that signals multi-factor, not just a plain password authentication context. If your IdP admin has to add that claim or bump the authentication context, do it in a sandbox and test the full round trip before touching production. Reading a config screen is not the same as watching the assertion arrive.

What should a consultant check before a go-live during the enforcement waves?

Before any go-live during the enforcement window, verify four things: your org's wave status in Setup, that SSO assertions carry AMR/ACR MFA signals, that at least one working second factor is registered per active user, and that no automation or integration depended on the retired exempt-user waiver.

• Wave status: confirm the current MFA enforcement state in Setup for each org, sandbox and production, so a scheduled deploy does not collide with a wave.
• SSO signals: capture a live assertion and confirm the AMR or ACR authentication-context value is present, not assumed.
• Registered factors: check that active users have a usable second factor already enrolled, especially service-adjacent and rarely-used accounts.
• Retired waiver: search for anything that leaned on the exempt-user shortcut and give it a real path forward before it fails silently.

If you run a large org with years of legacy SSO config and forgotten users, this is where the enforcement lands hardest, because that is exactly where misconfigured assertions and un-enrolled accounts hide. The work here is not writing code, it is verifying that the signals you assumed were flowing are actually flowing before the wave forces the question.