Salesforce started enforcing phishing-resistant MFA for privileged users in production orgs on July 1, 2026. The rollout is staggered over roughly thirty days, so if your org has not hit its enforcement date yet, it will soon. Once it does, every admin who has not registered a qualifying authentication method gets blocked at the login screen until they do.
Sandboxes went first, back on June 22. 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. This also covers internal users who reach the org through an Employee Community or Experience Cloud site. 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, Face ID, or Android biometrics.
- Cloud-synced passkeys. FIDO2 credentials stored in a password manager 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. Registration happens right in the login flow, 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 open a case with Salesforce Support and get it approved.
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 Okta, Entra, or other IdP configuration now, because the fix sits on their side.
Who Is Exempt
A few groups are out of scope: external Experience Cloud users (customers and partners), Chatter External and Chatter Free users, and non-paid environments like Developer Edition orgs, trials, and scratch orgs. API-only integration users authenticating with OAuth flows are not UI logins and are not blocked by this, though tightening those up is worth its own conversation given how many of last year’s breaches came through connected apps.
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. In Setup, under Identity Verification, allow security keys and built-in authenticators if they are not already on. Consider enabling passkey login while you are there; it makes daily sign-in faster, not slower.
- Have every affected user register now. Each user registers a security key or built-in authenticator from their own Advanced User Details. 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. File the support case 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. Sandboxes are already enforced, which makes them 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 tightens on July 20. Report exports 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 month 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.