Salesforce is rolling out phishing-resistant multi-factor authentication (MFA) for administrators and other privileged users, meaning accounts with broad access to your data or org configuration.
Once an org reaches its enforcement date, affected users will be blocked from logging into the org until they register a compliant phishing-resistant MFA method (Security Key or Built-in Authenticator). For all subsequent logins, they must also complete the MFA challenge.
At a glance:
- What: Salesforce phishing-resistant MFA required for privileged users
- When: Sandboxes June 22, 2026; production July 1, 2026 (each rollout staggered across several days)
- Who: Users with the System Administrator profile, or with Modify All Data, View All Data, Customize Application, or Author Apex
- Accepted methods: Passkeys, built-in authenticators (Touch ID, Face ID, Windows Hello), or hardware security keys such as YubiKey
- No longer sufficient: Salesforce Authenticator, SMS codes, email codes, TOTP authenticator apps, push notifications
What’s Changing with Salesforce MFA for Admins and Privileged Users
Salesforce has required MFA for a while now. What’s new is a higher bar for privileged accounts. Enforcement starts on June 22, 2026, in sandboxes and on July 1, 2026, in production. Each rollout is staggered over several days, so the exact day varies by org.
For these users, SMS codes, email codes, TOTP apps such as Google Authenticator or Salesforce Authenticator, and push notifications no longer count. Real-time phishing is the common case: an attacker redirects the user to a fake login page, captures the password and MFA code as they’re entered, and replays them into the real org before the code expires.
Push notifications have a second weakness, push bombing (also called MFA fatigue). An attacker who already has the password triggers repeated login attempts, flooding the user with approval prompts until they tap one to stop the notifications.
Phishing-resistant methods close both gaps. They tie the login to the real Salesforce domain through the FIDO2/WebAuthn standard, so credentials entered on a fake page are useless, and there’s no prompt to approve by mistake. Logging in requires the user’s own security key or device biometric.
Which Authentication Methods Qualify as Phishing-Resistant
Three kinds of authentication clear the bar:
- Passkeys, including ones stored in a FIDO2-compatible password manager like 1Password or Bitwarden
- Built-in authenticators: Touch ID, Face ID, Windows Hello
- Hardware security keys like YubiKey or Google Titan, over USB, NFC, or Bluetooth
What no longer works for these users: Salesforce Authenticator, SMS codes, email codes, TOTP apps, and push notifications.
Who’s Affected: Profiles, Permissions, and Permission Sets
A privileged user is anyone whose login can reach a large share of your org’s data or change how the org is built. Salesforce draws that line at the System Administrator profile and users with four specific permissions. A user qualifies if they have the System Administrator profile or any of the following: Modify All Data, View All Data, Customize Application, or Author Apex.
Each of those permissions is powerful on its own. Modify All Data and View All Data open every record regardless of sharing rules. Customize Application changes how the org is configured. Author Apex allows users to write and deploy code that runs with system-level access. That reach is what earns the higher login bar.
Those permissions can come through a permission set or a permission set group, not just the admin profile. So someone whose main job has nothing to do with administration can still be in scope. The affected list usually turns out longer than people expect, which is why a full audit is the only reliable way to catch everyone impacted by the new phishing-resistant MFA requirements.
How SSO Logins Are Affected (Okta, Microsoft Entra ID)
If your team signs in through an identity provider like Okta or Microsoft Entra ID, Salesforce never sees the actual login. It reads the authentication context your provider sends, the AMR/ACR values in the SAML assertion or OIDC token.
So if your provider reports a standard MFA method, like a password plus an authenticator push, Salesforce reads it as not phishing-resistant, even though MFA did happen. Those users will be treated as non-compliant and prompted to register a phishing-resistant method before they can continue.
Two ways to get SSO users compliant:
- Configure the identity provider to perform and assert a phishing-resistant method (FIDO2/WebAuthn) so the signal Salesforce gets qualifies.
- Let privileged users enroll in a Salesforce-native phishing-resistant method. This adds a step at login but leaves your identity provider untouched.
A setup that satisfies your internal MFA policy can still be read as standard to Salesforce, so check with whoever owns your identity platform to confirm what’s actually being sent today.
How to Prepare for the July 1, 2026, Salesforce Phishing-Resistant MFA Deadline
- Pull a list of everyone with the System Administrator profile, then everyone with Modify All Data, View All Data, Customize Application, or Author Apex granted through any permission set or permission set group.
- In Setup under Identity Verification, turn on either “Let users verify their identity with a built-in authenticator (passkey) such as Touch ID or Windows Hello” or “Let users verify their identity with a security key (U2F or WebAuthn),” depending on which method you are using. If these are off, affected users won’t be able to enroll at the step-up prompt and will get blocked.
- Next, register at least two phishing-resistant methods for each privileged user, so that a lost or dead device doesn’t lock anyone out.
- After that, check what authentication signals your identity provider sends for privileged users.
- Also, look at shared and integration accounts. Phishing-resistant methods tie to a device or vault, so they can’t be passed around. Where you can, split human admin access (with phishing-resistant MFA) from API-only service accounts.
Getting Help Before Enforcement
Most of this work is an audit: determining who’s in scope, confirming what your identity provider sends, and registering backup methods before your org hits its deadline. The technical fixes are quick once you know who needs them.
If you’d like a hand reviewing your setup before July 1, Coastal can run a readiness check with your team to identify who’s affected, where the gaps are, and what to fix first.
