What Is Phishing-Resistant MFA?
And Why Salesforce Is Now Requiring It

Imagine you get a fake text message from your bank. You click the link, enter your password, and then, prompted by the fake site, you type in the 6-digit SMS code or authenticator app code that just popped up on your phone. Even though you used Multi-Factor Authentication (MFA), the hacker just stole your password and your session code in real time.
Phishing-resistant MFA is designed specifically to stop this from happening. It is a type of authentication that cannot be compromised by a hacker tricking you, because it removes the human element of validating the site’s identity. Here is a breakdown of how it works, why it is becoming the gold standard for security, and what it means for Salesforce admins right now.
Why Traditional MFA Fails
Traditional MFA methods all share the same core weakness. SMS and email codes can be intercepted or typed into a lookalike phishing site just as easily as a password. Authenticator app codes (TOTP) are no safer; a 6-digit code can be copied and pasted into a fake site in seconds. And standard push notifications introduce a different vulnerability: hackers use “MFA fatigue” attacks, spamming your phone with login approval requests until you accidentally hit Approve.
In all these scenarios, your device does not actually know where it’s sending the authentication data. It just trusts that you are looking at the right website.
Salesforce has documented an active threat pattern where attackers call someone on the phone, pretend to be IT support, and walk them through logging into a fake Salesforce page. The fake page captures both the password and the MFA code in real time, then uses both to log into the real Salesforce org before the code expires. This is happening now, and it works against every traditional MFA method.
The Secret Sauce: Cryptographic Binding
Phishing-resistant MFA fixes this flaw by using asymmetric cryptography. Instead of you typing a code, your device talks directly to the website’s server. The process relies on a standard called FIDO2/WebAuthn, which uses a strict rule called origin binding:
- The Registration: When you set up phishing-resistant MFA, your authenticator device (like a hardware key) generates a cryptographic key pair specifically tied to that exact website domain (e.g.,
login.salesforce.com). - The Handshake: When you log in, the website sends a challenge to your device.
- The Block: If you are on a fake phishing site (like
login.sa1esforce.com), your device recognizes that the domain does not match the registered key. It refuses to sign the challenge. (Go back and read that domain again and see how convincing it is.)
The technology handles the verification. Therefore, you cannot be tricked into giving away your access, even if you completely fall for the fake website.
The Main Types of Phishing-Resistant MFA
There are two primary ways to implement this today.
FIDO2 / WebAuthn Credentials (Passkeys and Security Keys)
This is the most common and consumer-ready method.
- Hardware Security Keys: Physical USB or NFC devices like a YubiKey or Google Titan Security Key. You plug it in or tap it to your phone to authenticate.
- Passkeys (Platform Authenticators): This turns your phone or computer into the security key itself. It uses your device’s built-in biometric sensors (Face ID, Touch ID, or Windows Hello) to unlock a cryptographic passkey stored on your device’s hardware chip.
PKI / Certificate-Based Authentication (CBA)
This is mainly used in corporate and government environments. It involves installing a unique digital certificate onto a physical smart card (like a badge) or a managed device. The system checks for this specific certificate before granting access.
Which MFA Methods Don’t Qualify
This is where admins get tripped up. Regular TOTP apps like Google Authenticator and Authy, and push notifications including the Salesforce Authenticator app, do not qualify as phishing-resistant. These methods can be intercepted through MFA fatigue attacks or real-time phishing kits. For privileged users, those methods are no longer enough.
One emerging option worth watching: password managers that support FIDO2/WebAuthn passkeys, such as 1Password, Bitwarden, or iCloud Keychain, may qualify as phishing-resistant MFA. If your users are already using one of these tools, they may be closer to compliant than they think.
Why This Matters for Salesforce Admins Right Now
Starting June 22, 2026, in sandboxes and July 1, 2026, in production, Salesforce will require phishing-resistant MFA for all privileged users. Salesforce will lock the setting so it cannot be disabled, and users who have not registered a qualifying method will be blocked at the login screen. This applies to anyone with the System Administrator profile, or any of these permissions: Modify All Data, View All Data, Customize Application, or Author Apex.
Once in effect, users will be prompted to register their phishing-resistant MFA method on their next login. To audit your org, check all users with the System Administrator profile or one of those permissions using Salesforce Reports, User List Views, SOQL, or the User Access and Permissions Assistant. Also identify any users relying on the “Waive Multi-Factor Authentication for Exempt Users” permission. That exemption will no longer apply automatically. To restore it for valid use cases like automated testing tools, you will need to contact Salesforce Support for approval.
Is Your Salesforce Org Ready for Phishing-Resistant MFA Enforcement?
Before July 1, every Salesforce admin needs to understand the difference between MFA and phishing-resistant MFA. Traditional methods like SMS codes, TOTP apps, and push notifications can still be defeated by a convincing phishing attack. Phishing-resistant MFA closes that gap using cryptographic binding. It ties authentication to the exact domain of the legitimate site so a fake page can never intercept it. Qualifying methods include passkeys and hardware security keys. Standard authenticator apps and push notifications no longer meet the bar for privileged users.
Traditional MFA asks: Are you the person who owns this account?
Phishing-resistant MFA asks: Are you the person who owns this account, and are you actually trying to log into the legitimate website?
For Salesforce admins, the time to answer that second question is before June 22.
Explore related content:
How Salesforce Will Secure Your Org Against Hackers
Salesforce Is Tightening Security Across Every Org
How to Deploy Agentforce Right the First Time, Straight from the Experts
