Your Salesforce Admins Have a Hard Deadline: What IT Leaders Need to Know Before July 1

A wave of sophisticated attacks targeting Salesforce environments over the past year has forced the company’s hand. Starting this summer, Salesforce is mandating a new, higher standard of identity security for its most privileged users — and for the first time in the platform’s history, this change is being enforced outside of the regular release schedule.

If you have a Salesforce org, this affects your team. And if you work with a managed services provider or consulting firm that has admin access to your Salesforce environment, it affects them too — in ways most organizations haven’t thought through yet.

Here’s what IT leaders and CTOs need to know, and what needs to happen before July 1, 2026.

Why Salesforce Is Acting Now

The threat landscape has fundamentally shifted. Attackers are no longer relying on brute force — they’re using MFA fatigue attacks, where malicious actors spam push notification requests until an exhausted user simply approves one. They’re combining sophisticated phishing kits with voice-based social engineering. They’re bypassing SSO to steal session tokens.

Standard multi-factor authentication — the kind most organizations implemented over the last few years — is no longer strong enough for your most powerful accounts.

Phishing-resistant MFA is different at a technical level. Methods like security keys (YubiKey) and built-in biometric authenticators (Windows Hello, Touch ID) use cryptographic verification tied to a specific device. There is no push notification to approve, no code to intercept, and no way for a remote attacker to replicate the authentication. The key is physically in your hand or your fingerprint is on the sensor — and that’s the only way in.

Salesforce has documented active campaigns specifically targeting admin-level Salesforce accounts using phishing to bypass SSO. This mandate is a direct response to real attacks on real organizations.

What’s Changing — and When

Beginning June 22, 2026 for Sandboxes and July 1, 2026 for Production orgs, Salesforce will enforce phishing-resistant MFA for all privileged users. Users who don’t comply will be blocked from logging in until they enroll in a compliant method.

This is not a warning. It is not a grace period. It is a hard enforcement date.

Acceptable phishing-resistant methods are:

• Security Keys — physical hardware devices such as YubiKey ($25–50 each)
• Built-in Authenticators — biometrics like Windows Hello or Touch ID
• Passkeys — Salesforce’s recommended path, combining passwordless login with phishing-resistant verification

Who Is Actually Affected — More People Than You Think

This is where many organizations will be caught off guard. The requirement applies to any user with:

• The System Administrator profile, or
• Any of the following permissions (including those granted via permission sets):
  • Modify All Data
  • View All Data
  • Customize Application
  • Author Apex

That means this isn’t limited to your designated “Salesforce admins.” It includes developers with elevated permissions, power users, and integration accounts that were granted broad access for troubleshooting. Many organizations have more privileged users than they realize — and they won’t know until they run the audit.

Your action item: Direct your team to run a Salesforce Report, User List View, or SOQL query against the User object to identify every user who falls under any of these conditions before the enforcement date.

The MFA Exemption You’re Relying On Is Going Away

Many Salesforce organizations — particularly those with automated processes or testing tools — have been using the “Waive Multi-Factor Authentication for Exempt Users” permission to exclude certain accounts from MFA requirements. This workaround is ending.

After the enforcement date, this permission will no longer automatically waive MFA. Any user with this permission will be prompted to enroll in phishing-resistant MFA at their next login. To retain the exemption for legitimate use cases such as automated testing tools, you must contact Salesforce Support for explicit approval.

If your team has relied on this permission without actively tracking it, you need to find those accounts now.

Your SSO Provider Doesn’t Automatically Protect You

This is one of the most common assumptions we hear from IT leaders: “We use SSO, so our MFA is handled at the identity provider level.”

Not necessarily — at least not anymore.

For privileged users logging in via SSO, Salesforce will now require specific technical signals (AMR/ACR values) to verify that a phishing-resistant MFA method was actually used at the IdP level. If your identity provider is using standard MFA methods — even robust ones — but isn’t transmitting the correct phishing-resistant signals to Salesforce, your privileged users will be prompted to enroll in Salesforce MFA anyway.

The specific phishing-resistant signal values Salesforce recognizes include: cert, fido, fido2, fpt, hwk, iris, pin, pki, pop, retina, sc, smartcard, swk, TLSClient, user, vbm, wia, x509.

If you’re using Okta, Azure AD, or another enterprise IdP, your team needs to verify that the correct AMR/ACR signals are being transmitted. This is not a Salesforce configuration — it’s an identity provider configuration that requires coordination between your Salesforce admin and your IT security team.

The Managed Services Blind Spot: What to Ask Your Provider Right Now

If you work with a managed services provider, a Salesforce consulting firm, or any external partner that has admin-level access to your Salesforce org — this requirement applies to them too.

Think about what that means operationally:

• Device binding: Phishing-resistant MFA methods like FIDO2 hardware keys are tied to physical devices. If a consulting firm’s engineer has admin access to your org, they need a hardware key registered to your org’s environment — not just their own company’s SSO.
• Key management: What happens if the engineer who holds the registered key leaves the firm? Who manages re-enrollment? Is there a backup registered?
• Multi-org complexity: A managed services firm supporting dozens of customer Salesforce orgs needs a phishing-resistant MFA strategy that scales across all of them. This is not a trivial problem.
• Connected App authentication: Managed services providers that access your Salesforce data via Connected Apps using OAuth Web Server or Hybrid Token flows will have those login flows subject to MFA enforcement. Providers using JWT Bearer or Client Credentials flows are unaffected — but it’s worth confirming which approach your provider uses.

The question every IT leader should ask their Salesforce managed services provider this week: “What is your compliance plan for the July 1 phishing-resistant MFA enforcement, and how does it apply to your access to our org?”

A responsible provider should already have an answer.

The Mobile App Blind Spot

If your Salesforce admin team uses the Salesforce Mobile App or any app built on the Mobile SDK, there is an additional consideration.

Mobile SDK versions 13.2.0 and earlier use a default WebView-based authentication mode that cannot support phishing-resistant MFA. Admin users on these versions will be blocked from logging in unless one of the following is true:

• Your organization has pre-configured advanced authentication in My Domain settings, or
• Users upgrade to Mobile SDK 13.2.1 (releasing in May 2026) and use the new “Login for Admins” option, which forces browser-based authentication and supports phishing-resistant MFA automatically

If your organization uses any mobile Salesforce access for admin users, confirm which SDK version is in use and plan accordingly.

The Lockout Risk: Business Continuity You Need to Plan For

Here’s the scenario no one wants to face on the morning of July 2nd: an admin is blocked from logging in because they haven’t enrolled in phishing-resistant MFA, and they’re the only admin in the org.

If a privileged user is completely locked out and cannot provide a phishing-resistant MFA factor, the resolution is to contact Salesforce Support for a one-time login code. This works — but it takes time, and it’s entirely avoidable with preparation.

We’ve already seen this play out in the wild. Admins using VPNs have had their access revoked under Salesforce’s new risk-based controls. Solo admins in sandbox environments have faced lockouts with no internal path to recovery. These situations are disruptive and, in some cases, have required hours of support escalation to resolve.

The fix is straightforward: every privileged user should register at least two phishing-resistant MFA methods before the enforcement date — a primary and a backup. Budget time and, if necessary, hardware to make that happen now.

Your Five-Step Action Plan Before July 1

1. Audit your privileged users. Run a SOQL query or use the User Access and Permissions Assistant to identify every user with System Administrator profile, Modify All Data, View All Data, Customize Application, or Author Apex permissions. You will likely find more than you expect.
   
2. Identify MFA exemptions in use. Find every user assigned the “Waive Multi-Factor Authentication for Exempt Users” permission. Determine which are legitimate automated accounts requiring a Salesforce Support exemption, and which should be enrolled in phishing-resistant MFA.
   
3. Coordinate with your SSO provider. Confirm whether your identity provider is transmitting phishing-resistant AMR/ACR signals to Salesforce. If not, work with your IdP vendor to configure this before the enforcement date.
   
4. Enable and test phishing-resistant methods. Enable Security Keys and Built-in Authenticators in your Salesforce Setup under Identity Verification. Test in your Sandbox — which enforces first on June 22 — before Production goes live July 1. Procure hardware security keys for any users who will need them.
   
5. Ask your managed services provider for their compliance plan. If you have external partners with admin access, they need a phishing-resistant MFA strategy for your org. Get confirmation in writing before the deadline.
   

The Bottom Line for IT Leaders

Salesforce has made it clear: the era of standard push-notification MFA for privileged users is over. The threat level has escalated to a point where cryptographic, device-bound authentication is now the minimum standard for accounts that can touch your most sensitive data.

The good news is that this is entirely manageable with advance preparation. The hardware is inexpensive, the technology is mature, and the steps are well-documented. The organizations that will struggle are those that assume this doesn’t apply to them, or that their current setup is already compliant without verifying it.

At XTIVIA, we’ve been helping organizations prepare for this change as part of our Salesforce managed services and security advisory work. If you’d like a Salesforce security readiness assessment — covering privileged user audits, SSO signal validation, Connected App authentication review, and MFA enrollment planning — complete the form on the page, and we’re happy to help.

The deadline is real. The preparation is straightforward. Start now.