The grace period is over. Starting July 20, 2026, Salesforce is enforcing phishing-resistant MFA (PR-MFA) for every privileged user in production. That means System Administrators and anyone holding Modify All Data, View All Data, Customize Application, or Author Apex permissions. Sandbox enforcement already kicked in on July 6. If your admins aren't enrolled in a compliant method by then, they're locked out. No warning prompt. No fallback. Blocked.
This isn't the 2022 MFA "requirement" that was contractual but never actually enforced. This time, Salesforce flips the switch at the platform level.
Here's what you need to understand, how to validate your setup, and where teams keep getting tripped up.
Standard MFA (push notifications, TOTP codes, SMS) is no longer sufficient for admin accounts. Salesforce has seen active phishing campaigns that intercept authenticator prompts and steal session tokens mid-flow. A standard MFA challenge can be socially engineered. A phishing-resistant one can't, because it's cryptographically bound to the origin domain.
The only methods that qualify as phishing-resistant:
SMS, email OTP, and basic authenticator app codes (including Salesforce Authenticator push) do not qualify for privileged users. They still satisfy the standard MFA tier for general employee users, but admins need the stronger factor.
This is where most orgs will stumble. If your admins log in via Okta, Entra ID (Azure AD), Ping, or ADFS, Salesforce never sees the actual authentication event. It only reads the SAML assertion (or OIDC token) your IdP sends back. Specifically, it evaluates two claims:
If your IdP performs phishing-resistant MFA but reports it as generic mfa or pwd in the assertion, Salesforce treats it as non-compliant. Your admin either gets prompted to enroll a Salesforce-native passkey, or gets blocked entirely after enforcement.
The mental model to internalize: Salesforce doesn't evaluate your factor. It evaluates the string your IdP writes into the assertion. If the string is wrong, it doesn't matter what actually happened on the IdP side.
This is the hands-on part. Don't assume your config is correct. Trace it.
In Salesforce Setup, go to Login History. Pull up a recent login for a privileged user who authenticated via SSO. Look at the AMR/ACR column values.
Passing looks like phishing-resistant values: hwk, fido2, fpt, face, wia, swk, or x509.
Failing looks like only pwd, mfa, otp, okta_verify, sms, or the column is blank.
One important caveat: as of now, SAML ACR values are not yet recorded in Login History (Salesforce has flagged this as a future release item). For SAML-based SSO, Login History alone isn't enough. You need a tracer.
Install the SAML-tracer browser extension (available for Firefox and Chrome). Then:
| Signal | Where It Lives | Passing Values |
| AMR | <AttributeStatement> → authnmethodsreferences | hwk, fido2, fpt, face, swk, wia, x509, pin, sc, pki |
| ACR | <AuthnContextClassRef> | Varies by IdP, but must indicate phishing-resistant context |
If your AMR only shows pwd and mfa, your IdP is reporting standard MFA. The factor itself might be phishing-resistant, but the claim isn't. And the claim is what Salesforce evaluates.
In Setup, search for SAML Assertion Validator. You can paste a raw SAML response here and Salesforce will parse it. Useful for debugging when Login History shows something unexpected. One note though: this tool currently classifies signals as "strong" or "weak" and hasn't been updated to reflect the three-tier model (weak, standard, phishing-resistant) yet. Don't rely on it as your sole validation.
If you're on Microsoft Entra ID, here's something that catches people off guard: Entra's AuthnContextClassRef stays on PasswordProtectedTransport by design, even when a FIDO2 key is used. The only claim that changes is authnmethodsreferences (AMR). Don't wait for the ACR to shift because it won't. Read the AMR. As of June 29, 2026, Microsoft automatically includes AMR/ACR claims in SAML and OIDC tokens, but you still need a Conditional Access policy requiring phishing-resistant authentication strength scoped to your Salesforce admin group.
For Okta, the SAML assertion won't include AMR/ACR unless you explicitly map them in the Salesforce app's Sign On settings and configure the Authentication Policy to require a FIDO2/WebAuthn factor.
Audit privileged users now. Run a SOQL query or report to identify everyone with the System Administrator profile or the four elevated permissions. Don't assume you know who has what. Permission set assignments drift over time and people forget.
Register at least two phishing-resistant methods per admin. If an admin loses their YubiKey and has no fallback biometric enrolled, they're locked out. Build in redundancy.
Test in sandbox first. Sandbox enforcement is already live. Use it. Run the full SSO flow with a real admin account, trace the assertion, and confirm the AMR values before production enforcement hits.
Don't rely on the MFA waiver permission. The "Waive Multi-Factor Authentication for Exempt Users" permission stops working after enforcement. If you have automated testing tools that depend on it, file a Salesforce Support case now for a formal exemption.
Document a lockout recovery playbook. Another admin can generate a temporary identity verification code for a locked-out colleague. If there's only one admin, you're calling Salesforce Support. Know the process before you need it.
Coordinate with your IdP team early. The most common failure mode isn't "we don't do MFA." It's "we do phishing-resistant MFA but report it as standard in the assertion." That's an IdP configuration issue, not a Salesforce one, and it takes cross-team coordination to fix.
Even if your SSO is performing well and passing the right AMR/ACR signals today, consider having your admins register a Salesforce-native phishing-resistant method like Windows Hello or a security key as a fallback. IdP configurations are not static. A Conditional Access policy change, a token update, or a provider upgrade can silently break the signal chain, and you won't know until someone gets locked out. Having a local method already registered means Salesforce can fall back gracefully instead of blocking your admins at the door. It also means the next time an industry mandate, a cyber insurance requirement, or an internal security initiative raises the bar on authentication, you're already there. You won't be back in a SAML tracer debugging why your assertions stopped qualifying.
Salesforce is done asking. The platform is going to enforce this at the login layer, and the burden is on you to make sure your assertions carry the right signals before that happens. The good news is the validation steps are straightforward. Install a SAML tracer, read the AMR values, and fix what's broken at the IdP. A couple hours of tracing now saves you from a Monday morning lockout in production.