Prepare for Salesforce Phishing-Resistant MFA: What Admins Need to Know

A Salesforce phishing-resistant MFA security upgrade will be delivered soon, affecting every Salesforce administrator and users with specific permissions starting this summer. Beginning June 22, 2026, for sandboxes and July 1, 2026, for production orgs, this new, mandatory multi-factor authentication will be enforced for all users with System Administrator profiles or elevated permissions.

This post explains what’s changing, who’s affected, what qualifies as a phishing-resistant MFA, and what you need to do before the enforcement dates.

What’s Changing

The Requirement

Salesforce is requiring phishing-resistant MFA for all users with elevated permissions:

• System Administrator profile
• Modify All Data permission
• View All Data permission
• Customize Application permission
• Author Apex permission

This applies to both direct logins and Single Sign-On (SSO) logins, in production and sandbox environments.

Methods That Qualify

Only these methods count as phishing-resistant:

• Security Keys: Physical USB or NFC devices (like YubiKeys)
• Built-in Authenticators: Touch ID on Mac, Windows Hello, Face ID on iPhone

Methods That No Longer Work for Admins

• Salesforce Authenticator mobile app
• Third-party authenticator apps (Google Authenticator, Microsoft Authenticator)
• SMS codes
• Email verification

These methods are still vulnerable to phishing attacks and no longer meet the security standard for admin access.

Enforcement Dates for the Salesforce phishing-resistant MFA

Sandbox Orgs

• Start Date: June 22, 2026
• Rollout: Staggered over 7 days
• Impact: Admins will be blocked from logging in without a compliant method

Production Orgs

• Start Date: July 1, 2026
• Rollout: Staggered over 30 days
• Impact: Production administrators will face the same enforcement

Your specific org will be enforced sometime during these windows.

Who This Affects

• System Administrator profile
• Modify All Data permission
• View All Data permission
• Customize Application permission
• Author Apex permission

This typically includes:

• All Salesforce administrators
• Power users with data management permissions
• Developers with Apex capabilities
• Integration users with View All or Modify All permissions who log into the UI

You are exempt if you:

• Don’t have the System Administrator profile or elevated permissions listed above
• Are an Experience Cloud or Community user
• Only use API logins (no UI access)

What Counts as Phishing-Resistant

Salesforce categorizes authentication into three levels:

Phishing-Resistant (Required for Admins)

• Direct Logins: Security Keys, Built-in Authenticators (Touch ID, Windows Hello, Face ID)
• SSO Signals: cert, fido, fido2, hwk, pki, smartcard, x509, and others
• Result: Successful login

Standard MFA (Not Sufficient for Admins)

• Direct Logins: Salesforce Authenticator, TOTP apps
• SSO Signals: face, okta_verify, passkey, webauthn
• Result: Login blocked for admins

Weak or No MFA (Not Sufficient for Admins)

• Direct Logins: No MFA, SMS, or email codes
• SSO Signals: pwd, sms, tel, email
• Result: Login blocked for admins

Important Policy Changes

MFA Exemption Permission No Longer Works

Users with the  “Waive Multi-Factor Authentication for Exempt Users” permission won’t be excluded after enforcement, and will be prompted to enroll in MFA. To restore the exemption for valid use cases (like automated testing tools), you must contact Salesforce Support.

Trial Org Grace Period Eliminated

Trial orgs converted to paid subscriptions will no longer receive a 30-day grace period. MFA enforcement applies immediately upon conversion.

Integration Users: What You Need to Know

This MFA requirement only affects UI logins. API-only access is not impacted.

Integration Users Are NOT Affected If They:

• Use API-only authentication (SOAP, REST, Bulk API)
• Use Connected Apps with JWT Bearer flow
• Use Connected Apps with Client Credentials flow
• Never log into the Salesforce UI

Integration Users ARE Affected If They:

• Have admin permissions AND log into the UI
• Use Connected Apps with OAuth Web Server or Hybrid Token flows (these require UI login for OAuth authorization)

Best Practice for Integration Users If you have integration users with admin permissions:

1. Audit their actual access needs. Do they truly need the System Administrator profile or can they function with specific permissions?
2. Separate human and system access. Create two accounts:
   • Service account for API/integrations (specific permissions only, no UI access)
   • Human admin account for UI work (with phishing-resistant MFA)
3. Use API-only authentication methods. JWT Bearer and Client Credentials flows don’t require UI login and aren’t affected by MFA enforcement.
4. Review Connected Apps. If you’re using OAuth Web Server or Hybrid Token flows, the authorization step requires UI login and is subject to MFA enforcement.

Example Scenario You have an integration user “api_integration@yourorg.org” with a System Administrator profile that runs nightly data syncs via API.

Problem: This user has admin permissions but only needs API access. If someone ever tries to log into the UI with these credentials (for troubleshooting, testing, etc.), they’ll be blocked by MFA enforcement.

Solution:

• Remove System Administrator profile from the integration user
• Grant only the specific permissions needed (e.g., Read and Edit on specific objects)
• Ensure the integration uses API authentication only
• Create a separate human admin account for any UI work

This approach improves security and avoids MFA complications for automated processes.

How to Prepare

Step 1: Find Who’s Affected

Identify all users who need phishing-resistant MFA:

• Users with System Administrator profile
• Users with Modify All Data, View All Data, Customize Application, or Author Apex permissions
• Users with “Waive Multi-Factor Authentication for Exempt Users” permission (this will stop working)

Use Salesforce Reports, List Views, or SOQL queries on the User object to find these users.

Pay special attention to:

• Integration users with admin permissions who occasionally need UI access
• Service accounts that might have been given System Administrator for convenience
• Developers with full sandbox access who also access production

Step 2: Enable the Right Methods

In Setup, go to Identity Verification settings and enable:

• Security Keys (WebAuthn)
• Built-in Authenticators

Note: Once enabled, these methods are available to all users in your org, and cannot be restricted to admins only.

We recommend also enabling passwordless login with passkey to allow users to log in with just their username and passkey (no password needed). In Identity Verification settings, turn on “Allow passwordless login with passkeys.”

Step 3: Set Up SSO Compliance (If You Use SSO)

If your organization uses Single Sign-On, choose one approach:

Option A: Update Your Identity Provider Configure your IdP (Okta, Azure AD, Ping, etc.) to:

1. Require phishing-resistant MFA at the IdP level
2. Send the required AMR or ACR signals to Salesforce

Salesforce recognizes these signals as phishing-resistant: cert, fido, fido2, fpt, hwk, iris, pin, pki, pop, retina, sc, smartcard, swk, TLSClient, user, vbm, wia, x509

Check your signals:

• OIDC: Review Login History for AMR signals
• SAML: Use a SAML tracer tool to inspect responses

Option B: Use Salesforce MFA for SSO Logins Let users enroll Salesforce-based phishing-resistant methods even when using SSO. This adds a step but ensures compliance without changing your IdP.

Step 4: Test in Sandbox

Before production enforcement:

1. Enable MFA requirement in a sandbox
2. Have admin test users enroll Security Keys or Built-in Authenticators
3. Verify successful login
4. If using SSO, confirm signals are passing correctly
5. Test any Connected Apps that require OAuth authorization
6. Document and fix any issues

Step 5: Notify Your Team

Don’t wait until the enforcement date. Tell your admin team now:

• Timeline: Sandbox June 22, production July 1
• Requirement: Security Keys or Built-in Authenticators only
• How to enroll: Share Salesforce documentation
• Deadline: Enroll before enforcement to avoid lockouts

Point users to the Salesforce Help article “Register an identity verification method.”

Special Situations

Salesforce Mobile App Admins using Mobile SDK version 13.2.0 or earlier will be blocked unless your org has advanced authentication configured in My Domain settings. Starting May 2026, Mobile SDK 13.2.1 adds a “Login for Admin” button that forces browser-based authentication. Salesforce Mobile App admins can use the “Login with Email” option.

The login flow is also changing: username first, then password or passkey after clicking Log In. This may require updates to automated tests.

Connected Apps Connected Apps using OAuth Web Server or Hybrid Token flows require UI login for OAuth authorization, so they’re subject to MFA enforcement. Apps using JWT Bearer or Client Credentials flows are not affected because they don’t require UI login.

API-Only Access This change only affects UI logins. API-only integrations using username/password authentication, API tokens, or certificate-based authentication are not impacted.

After Enforcement

Direct Logins Admins will be blocked until they register a Security Key or Built-in Authenticator and complete the MFA challenge on every login.

SSO Logins If your SSO provider doesn’t send phishing-resistant signals, admins will be prompted to enroll in Salesforce MFA. Coordinate with your SSO provider to send the correct signals and avoid this dual enrollment.

Banner Warnings Before enforcement, Salesforce will show banner reminders in orgs where SSO is configured, the org-wide MFA setting is disabled, or Security Keys and Built-in Authenticators aren’t enabled.

If an Admin Gets Locked Out If an admin cannot provide phishing-resistant MFA, they must contact Salesforce Support for a one-time login code. If your only admin is locked out, contact Support immediately.

Common Questions

Can admins still use the Salesforce Authenticator?
No. Salesforce Authenticator is standard MFA, not phishing-resistant. It no longer works for admins.

Does passwordless login with passkeys count as phishing-resistant?
Yes. Passkeys meet the requirement even without a password.

Do we need to buy hardware keys?
Not necessarily. Built-in Authenticators (Touch ID, Windows Hello, Face ID) are free and work on most modern devices. Security Keys are an option for devices without built-in authenticators.

How do we know when our org will be enforced?
Watch for in-app banners and check Login History. When enforcement starts, admins will only be able to use Security Keys and Built-in Authenticators.

What if a user is both an admin and a regular user?
If a user has any admin permission, they must use phishing-resistant MFA for all logins.

Do integration users need phishing-resistant MFA?
Only if they log into the UI. API-only integrations are not affected. If your integration user has admin permissions but only uses API access, they won’t be impacted. However, if someone tries to log in with those credentials through the UI, they’ll be blocked without a phishing-resistant MFA.

What about automated testing accounts?
If your automated testing requires UI login with admin permissions, you’ll need to either set up phishing-resistant MFA or contact Salesforce Support to request an exemption for the “Waive Multi-Factor Authentication for Exempt Users” permission.

Action Timeline

Now through May 31

• Audit affected users
• Review integration users and service accounts
• Enable phishing-resistant methods
• Plan communication strategy

June 1-21

• Test in sandbox
• Communicate to affected users
• Begin user enrollment
• Separate integration and human admin accounts

June 22

• Sandbox enforcement begins

June 23-30

• Monitor sandbox experience
• Fix any issues

July 1

• Production enforcement begins

Next Steps

Give your team time to enroll and test before the deadlines. Do not wait until the enforcement date. Organizations that delay risk admin lockouts and system disruption. 

For Fíonta Managed Services Clients
Your Solution Success Manager will help you audit affected users, plan the rollout, and ensure compliance before enforcement. Contact your SSM if you have questions about your specific environment.

For All Organizations
Start your preparation now. The more time your admin team has to enroll and test phishing-resistant methods, the smoother this transition will be..

If your team needs help assessing who’s affected, updating permission sets, or communicating the change to your users, Fíonta is here to help. Contact us today to learn more.