Salesforce Is Enforcing Phishing-Resistant MFA for Admins. Here Is What to Do

Correction (October 7, 2026): an earlier version of this post gave June 22 (sandboxes) and July 1 (production) as the enforcement start dates. Salesforce had moved those dates before we published. The dates below match the current Salesforce Help article.

Salesforce is enforcing phishing-resistant MFA for privileged users in production orgs starting July 20, 2026. The rollout is staggered by release group, with the last groups scheduled for September 1 and September 3, so check the Help article’s release group schedule for your org’s date. Once your org hits it, every admin who has not registered a qualifying authentication method gets blocked at the login screen until they do.

Sandboxes went first, starting July 10. If your admins have been logging into sandboxes fine since then, do not read too much into it; sandbox enforcement was staggered too, and production is its own wave. This post covers who is affected, what changed, and the shortest path to being ready.

What Is Actually Changing

Salesforce has required MFA for years, and most orgs settled into Salesforce Authenticator push notifications or a code from an authenticator app. Those methods stop counting for privileged users. The problem is not that they are weak in themselves; it is that a person can be talked out of them. An attacker on the phone can get an employee to read out a six-digit code or tap “approve” on a push notification, and at that point the MFA did nothing.

Phishing-resistant methods close that gap. A passkey or security key is cryptographically bound to the real salesforce.com domain, so a fake login page cannot capture and replay it, and there is no code or approval for a caller to socially engineer. After a year of vishing campaigns aimed squarely at Salesforce customers, Salesforce stopped recommending these methods and started requiring them.

Who Is Affected

The requirement targets privileged internal users, meaning anyone with:

The System Administrator profile
Modify All Data
View All Data
Customize Application
Author Apex

Any one of those is enough, whether it comes from the profile or a permission set. It applies to direct UI logins and SSO logins, and it also covers internal users who log in through your Employee Community or another Experience Cloud site. External users with Experience Cloud licenses are a different story (see the exemptions below). In practice, the affected list is usually longer than “our two admins.” Power users with View All Data for reporting, developers with Author Apex, and that one consultant profile from three years ago all count. Pull the list before enforcement pulls it for you.

Which Methods Qualify

Accepted phishing-resistant methods:

Security keys. Physical FIDO2/WebAuthn devices like a YubiKey.
Built-in authenticators. Device-bound passkeys using Windows Hello, Touch ID, or Face ID.
Cloud-synced passkeys. FIDO2 credentials stored in a password manager or cloud keychain such as 1Password, Bitwarden, or iCloud Keychain.
Certificate-based authentication. x.509 client certificates, mostly relevant to larger enterprises.

No longer sufficient for privileged users:

Salesforce Authenticator push notifications
TOTP codes from Google or Microsoft Authenticator
SMS and email codes

For most teams the practical answer is passkeys. Nearly every work laptop already has Windows Hello or Touch ID, so there is usually nothing to buy. Hardware keys still make sense for shared workstations, users who move between many devices, or teams that want a physical token they can inventory.

What Happens on Enforcement Day

When your org’s date arrives, affected users who lack a registered qualifying method are blocked from the UI login until they register one. Salesforce prompts them to create a passkey as part of login, so nobody is permanently locked out, but picture your whole admin team hitting an unexpected enrollment screen on a Monday morning with a deploy scheduled. Better to register ahead of time, on your schedule.

One more change that catches people off guard. The “Waive Multi-Factor Authentication for Exempt Users” permission stops automatically exempting anyone. Users carrying that waiver get prompted to enroll like everyone else. If you have a legitimate case for an exemption, such as an automated testing user that logs in through the UI, you now have to contact Salesforce Support.

If You Use SSO

Delegating login to an identity provider does not exempt you. Salesforce now expects the IdP to assert that the login used a phishing-resistant method, passed along as AMR or ACR claims in the SAML or OIDC response. If your IdP enforces passkeys or security keys for these users and sends the right signals, you are covered. If it does not, Salesforce prompts those users to enroll in Salesforce MFA on top of your SSO, which is exactly the double-prompt experience you built SSO to avoid. Loop in whoever owns your IdP configuration now, because the fix sits on their side.

Who Is Exempt

A few groups are out of scope: external users with Experience Cloud licenses (customers and partners), Chatter External and Chatter Free users, and non-paid environments like Developer Edition orgs, trials, and scratch orgs. Integrations that use the JWT bearer or client credentials OAuth flows are unaffected because no UI login is involved. Apps that use the web server or hybrid flows are a different case: the user still logs in to the Salesforce UI to authorize the app, and that login is subject to enforcement. Tightening up integrations is worth its own conversation anyway, given that the same vishing campaigns tricked users into authorizing a malicious connected app.

How to Get Compliant This Week

Pull the affected user list. Query for the System Administrator profile plus anyone granted Modify All Data, View All Data, Customize Application, or Author Apex through profiles or permission sets.
Enable the methods in your org. Make sure security keys and built-in authenticators are allowed as verification methods if they are not already on. Consider enabling passkey login while you are there; Salesforce recommends passwordless login with passkeys for faster sign-in.
Have every affected user register now. Each user registers a security key or built-in authenticator for their own account. Five minutes per person, and it beats doing it under pressure on enforcement day.
Audit the MFA waiver. Find everyone holding “Waive Multi-Factor Authentication for Exempt Users” and decide which ones genuinely need it. Contact Support for those; enroll the rest.
Fix SSO signals if applicable. Confirm your IdP requires phishing-resistant methods for privileged users and passes AMR/ACR claims to Salesforce.
Test in a sandbox. Sandbox enforcement started first, which makes sandboxes a safe place to walk through the enrollment flow before your production date lands.

This Is Part of a Bigger Wave

Phishing-resistant MFA is the headline, but it is one of several security changes Salesforce is rolling out this summer. MFA enforcement for all internal users was scheduled to tighten in production on July 20. Reports are getting step-up authentication, and orgs with Shield or Event Monitoring that have not built a qualifying transaction security policy by July 13 will have a default one created for them. Logins from anonymizing proxies have been blocked since April. The direction is clear, and it is the right one; the orgs that treat this as a prompt to review their whole access model, instead of a checkbox to clear, will get the most out of it.

If you want a second set of eyes on your user audit or your SSO configuration before your enforcement date hits, that is exactly the kind of short engagement we do.