Salesforce Phishing-Resistant MFA: What It Is, How to Validate It, and What Not to Sleep On

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.

What Changed and Why It Matters

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:

• Built-in authenticators like Touch ID, Face ID, and Windows Hello (device-bound biometrics)
• Hardware security keys like YubiKey, Titan, or any FIDO2-compliant key
• FIDO2/WebAuthn passkeys stored in a credential manager or on-device
• AMR (Authentication Methods References): a list of specific methods used, such as pwd, mfa, hwk, fido2, fpt, and so on.
• ACR (Authentication Context Class Reference): a summary label for the assurance level of the session.

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.

The SSO Trap: Your IdP Does MFA ≠ Salesforce Sees MFA

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.

How to Validate with a SAML Tracer

This is the hands-on part. Don't assume your config is correct. Trace it.

Step 1: Check Login History First (Quick Sanity Check)

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.

Step 2: Install and Run a SAML Tracer

Install the SAML-tracer browser extension (available for Firefox and Chrome). Then:

1. Open the tracer and clear previous captures.
2. Initiate an SSO login to Salesforce with a privileged admin account.
3. In the tracer output, find the SAML Response from your IdP.
4. Expand the <AttributeStatement> and look for an Attribute with Name containing amr or authnmethodsreferences.
5. Also check the <AuthnContextClassRef> element.

What You're Looking For

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.

Step 3: Salesforce SAML Assertion Validator (Secondary Check)

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.

The Entra ID Gotcha

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.

Best Practices

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.

One More Thing Worth Doing

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.

The Bottom Line

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.