A Salesforce login problem rarely starts with a dramatic outage. It starts with one user stuck at a verification screen. A sales manager can’t open an opportunity before a client call. A RevOps user can’t access a dashboard. An admin signs in through SSO, passes the company login page, and still gets asked to prove identity inside Salesforce. That is where Salesforce July authentication problems can hurt daily work. The password may be correct. The SSO setup may look fine. But if MFA enrollment, phishing-resistant MFA, identity verification, or step-up authentication isn’t ready, users can still get challenged, delayed, or blocked.
Salesforce’s 2026 authentication changes do not point to one single deadline for every user. Sandbox and production timelines differ, and privileged users face stricter phishing-resistant MFA rules than standard employee users. For admins, the real risk sits in the details: broad permission sets, old MFA waiver permissions, missing security keys, weak SSO signals, mobile SDK limits, API login assumptions, and users who never completed verifier setup.
This blog explains what is changing, who may be affected, why users may lose access, and what admins should fix before authentication changes reach their org.
What Is Actually Changing With Salesforce MFA in July 2026
Salesforce has been tightening MFA requirements in stages. The 2022 MFA requirement pushed orgs to make multi-factor authentication part of everyday login security. The 2026 change goes further for users with high-risk access. Salesforce’s current guidance says phishing-resistant MFA enforcement for privileged users starts in sandboxes on June 22, 2026, and in production orgs on July 1, 2026, with production rollout staggered over about 30 days.
For Salesforce admins, the word “privileged” matters. This group includes users with the System Administrator profile or permissions such as Modify All Data, View All Data, Customize Application, or Author Apex. Standard MFA methods may still work for standard employee users, but privileged accounts need stronger verification.
Why Salesforce Is Doing This Now
Attackers do not need to break Salesforce when they can trick a user into approving the wrong login or entering a one-time code on a fake page. That is the weakness phishing-resistant MFA is built to reduce.
Admins should pay attention to these points:
- SMS passcodes, TOTP apps, and push approvals can be phished or approved by mistake.
- Privileged users can expose data, metadata, automation, and security settings if their accounts are taken over.
- SSO alone may not satisfy Salesforce if the identity provider does not send the right MFA signals.
- Salesforce July authentication problems may start with users who already believe their login setup is complete.
What Counts as Phishing-Resistant MFA
Phishing-resistant MFA uses WebAuthn-based methods tied to the real login domain and the user’s device or security key. That makes it much harder for a fake login page to steal the verification step.
Supported options admins should review include:
- Built-in authenticators such as Touch ID, Face ID, and Windows Hello.
- Physical security keys that support FIDO2 or WebAuthn.
- Passkey-based login where Salesforce or the SSO provider supports the setup.
- Backup phishing-resistant methods for admins who lose a device or key.
Who Could Get Blocked If Admins Do Nothing
Many Salesforce teams start this audit with the System Administrator profile. That is useful, but it leaves gaps. Salesforce’s phishing-resistant MFA requirement applies to privileged users. That includes users with the System Administrator profile and users who have permissions such as Modify All Data, View All Data, Customize Application, or Author Apex.
Those permissions can sit in more places than admins expect. A user may have them through a profile, a Permission Set, or a Permission Set Group. So the affected list can include developers, senior analysts, RevOps users, release managers, and support leads who were given broad access years ago.
Core access risk
- A privileged user without a compliant phishing-resistant MFA method may be challenged or unable to complete login.
- An SSO user may pass the company login page but still face Salesforce verification if the IdP does not send the right MFA signal.
- A user with old, broad permissions may fall into scope even if their job title does not say “admin.”
It Is Bigger Than Your Named Admins
Do not rely on profile names alone. Run a permission-level audit.
Check users with:
- System Administrator profile
- Modify All Data
- View All Data
- Customize Application
- Author Apex
Then trace how each permission was granted. Profiles are only one path. Permission Sets and Permission Set Groups often carry the real access risk. A developer with Author Apex, an analyst with View All Data, or a RevOps user with Modify All Data can be treated as privileged for enforcement. If those users sign in directly, they need a supported phishing-resistant method. If they use SSO, Salesforce needs proof that phishing-resistant MFA happened at the identity provider.
What Happens to the MFA Waiver
The “Waive Multi-Factor Authentication for Exempt Users” permission needs a careful review. Do not use it as a broad shortcut to reduce login friction. Salesforce may require users with this permission to enroll or complete verification unless the exemption is approved for a valid use case.
Start by listing every user with the waiver permission. Keep it only where there is a real business reason, such as approved automated testing. For those cases, plan a Salesforce Support request early. Everyone else should move to a proper MFA setup before enforcement reaches the org.
Standard MFA vs. phishing-resistant MFA: why it matters
Many Salesforce organisations enabled standard MFA after the 2022 requirement. For regular users, that was a strong step. Authenticator apps, one-time codes, and push approvals added a second check after the password. Privileged Salesforce users now need a stronger setup. The risk sits in how standard MFA can be phished. A user may open a fake Salesforce login page, enter the correct password, then type a one-time code when prompted. The attacker can pass those details to the real login page in real time.
That is why phishing-resistant MFA matters for admin-level access. Security keys, built-in authenticators, and supported passkeys use WebAuthn or FIDO2-based checks tied to the real login domain. A fake login page cannot reuse the same proof.
Comparison: what each method offers
Method | Type | Phishing-resistant | Acceptable for privileged admins |
SMS OTP | Standard MFA | No | No |
TOTP app, such as Google Authenticator or Microsoft Authenticator | Standard MFA | No | No |
Push notification, such as Salesforce Authenticator | Standard MFA | No | No |
Physical security key | Phishing-resistant MFA | Yes | Yes |
Built-in authenticator, such as Face ID, Touch ID, or Windows Hello | Phishing-resistant MFA | Yes | Yes |
Supported passkey setup through Salesforce or the identity provider | Phishing-resistant MFA | Yes | Yes |
For admins, the safest plan is to register at least 2 phishing-resistant methods. One can be the daily method, such as a built-in authenticator. The second can be a backup security key kept in a secure place.
Do not treat Salesforce Authenticator, TOTP apps, or SMS as enough for privileged users after enforcement reaches the org. They may still work for standard employee users, but privileged users need a phishing-resistant method that Salesforce can verify directly or through the SSO provider.
The fixes admins need to make right now
Use this as your Salesforce admin MFA checklist before enforcement reaches your org. The work is simple on paper, but it needs clean ownership across Salesforce, IT, security, and SSO teams.
Step 1: audit who is actually affected
Start with every user who has the System Administrator profile. Then check users with Modify All Data, View All Data, Customize Application, or Author Apex. Use Salesforce Reports, User List Views, SOQL, or the User Access and Permissions Assistant. Old org notes can miss access granted through Permission Sets or Permission Set Groups.
Check these groups first:
- System admins
- Developers with Author Apex
- RevOps users with broad data access
- Analysts with View All Data
- Release or support users with admin-level permissions
Step 2: identify who has the MFA waiver permission
Pull a list of users assigned “Waive Multi-Factor Authentication for Exempt Users.” Treat this as a review item, not a shortcut. Salesforce’s 2026 MFA changes affect how this waiver works. Users who relied on it may need to enroll in MFA or go through an approved exception path. Keep the waiver only for valid cases, such as approved automated testing. For those users, prepare a Salesforce Support request early.
Step 3: choose and enable phishing-resistant methods
Enable supported phishing-resistant methods in Identity Verification settings.
Admins should review:
- Built-in authenticators, such as Touch ID, Face ID, and Windows Hello
- Physical security keys that support WebAuthn or FIDO2
- Passkey settings, if your org plans to use passwordless login
- Backup verification methods for every privileged user
Once these methods are turned on, users still need to register them. Give admins a clear setup path before the enforcement window.
Step 4: check your SSO configuration
SSO does not automatically prove that phishing-resistant MFA happened. If privileged users log in through Okta, Microsoft Entra, Ping, or another IdP, Salesforce needs the right authentication signals from that provider. The key signals are ACR and AMR.
Ask your identity team to confirm:
- Which MFA method admins use at the IdP
- Whether that method is phishing-resistant
- Whether the IdP sends the right ACR or AMR signal to Salesforce
- Whether Salesforce login testing shows the expected result
If the signal is missing, users may pass SSO and still face Salesforce verification.
Step 5: test in sandbox first
Use the sandbox rollout as your dry run. Test privileged users before production enforcement starts. Have each admin register a phishing-resistant method, log in through the normal path, test SSO, check backup access, and confirm support steps for lockout cases. Fix sandbox issues before July 1, 2026, when Salesforce’s production rollout for privileged-user phishing-resistant MFA begins.
Step 6: handle mobile app users separately
Mobile access needs its own check, especially for custom apps built with Salesforce Mobile SDK.
Mobile SDK 13.2.0 and earlier uses a default authentication mode that cannot support phishing-resistant MFA for admin users unless the org pre-configures advanced authentication in My Domain and uses the My Domain URL.
Mobile SDK 13.2.1 adds a “Login for Admin” path that forces browser-based authentication. Check SDK versions, My Domain settings, and admin login flows before mobile users hit enforcement.
The traps most teams walk into
Even well-prepared teams can trip on the details. These are the most common issues showing up in Salesforce admin communities right now.
Assuming the admin list is short: Most teams start by looking at users with the system administrator profile. But developers, senior analysts, and integration owners often carry elevated permissions through permission sets. The actual list is always longer than the first audit suggests.
Relying on SSO and assuming everything is fine: SSO compliance depends on what signal your Identity Provider sends to Salesforce. An admin who authenticates with push notification-based MFA at Okta or Entra today may still fail Salesforce’s check after July 1 because the IdP is not sending the right phishing-resistant signal. This needs a dedicated check with your identity team, not just an assumption.
Forgetting integration users with admin permissions: If you have integration users with admin permissions, audit their actual access needs. Integration users set up for automated processes often carry elevated permissions that were convenient at setup but never reviewed. These users are also in scope and may need their permissions reduced or their authentication method updated.
Waiting for the production date: Users who haven’t enrolled in MFA by the deadline may need to do verification steps to stay in Salesforce, or worse, not be able to log in. The rollout is staggered over 30 days, which means some production orgs will be onboarded before others. You do not know exactly when your org will be hit, so waiting until July 1 is cutting it too close.
Not budgeting for hardware keys in time: If you decide to go the security key route for your admins, budget approximately 25 to 50 USD per key and plan to register at least two phishing-resistant methods per admin as a backup. Shipping times matter. Order early.
Teams working with external consultants or managed services partners should also check whether those partners have updated their own admin access. If you work with a managed services provider or consulting firm that has admin access to your Salesforce environment, this affects them too, in ways most organizations haven’t thought through yet.
Conclusion
Salesforce July authentication problems can look like simple login errors on the surface. The real work sits across Salesforce MFA, phishing-resistant MFA, SSO signals, identity verification settings, mobile access, sandbox testing, and user permissions. Admins should treat the June and July 2026 enforcement windows as an access-readiness project. Start with privileged users; check how each person signs in, test the flow in the sandbox, and fix weak points before the production rollout reaches the org. A clean MFA setup protects users without slowing the business down on rollout day.
Keep these points close while preparing your org:
- Audit users with the System Administrator profile, Modify All Data, View All Data, Customize Application, or Author Apex.
- Check Permission Sets and Permission Set Groups, since privileged access often sits outside the profile.
- Confirm that admins and other privileged users have phishing-resistant MFA methods registered.
- Test SSO logins and verify that the identity provider sends accepted MFA signals to Salesforce.
- Review MFA waiver permissions and remove broad exceptions that no longer fit.
- Check Mobile SDK, My Domain, sandbox, and human login paths for integration accounts.
- Prepare backup verification methods for every privileged user.
- Monitor login history, identity verification reports, failed logins, and support tickets after rollout.
The safest plan is simple: find the affected users early, fix the authentication path, test it, and give users clear instructions before they need them.
