Complete Implementation Guide for Customers, Partners & Salesforce Administrators

Everything You Need to Know About Salesforce’s July 2026 Security Update

Executive Summary

Cybersecurity threats continue to evolve, and phishing remains one of the most successful techniques used to compromise enterprise applications. Even organizations that have already implemented Multi-Factor Authentication (MFA) are increasingly being targeted through sophisticated phishing attacks that trick users into approving login requests or entering one-time verification codes.

To strengthen the security of privileged accounts, Salesforce is introducing Phishing-Resistant Multi-Factor Authentication (PR-MFA) for users with elevated permissions while continuing to support standard MFA for regular employee users.

Unlike previous MFA requirements, this update primarily affects users who can administer or significantly modify a Salesforce organization. Beginning in July 2026, these privileged users must authenticate using phishing-resistant methods such as Passkeys, Windows Hello, Face ID, Touch ID, or FIDO2 security keys.

For many organizations, implementation is straightforward. However, small and medium-sized businesses (SMBs), consulting partners, and managed service providers often operate with shared administrator accounts or a limited number of administrator licenses. These organizations may face additional operational challenges during the transition.

This guide explains:

• What PR-MFA is and why Salesforce is introducing it
• The difference between traditional MFA and PR-MFA
• Which users are affected
• Supported authentication methods
• How to configure passkeys
• Salesforce’s recommended implementation approach
• Practical considerations for organizations using shared administrator accounts
• Perigeon’s implementation recommendations based on real-world customer scenarios

Salesforce Authentication Timeline

Salesforce has been progressively strengthening authentication requirements over the past several years.

Why Is Salesforce Introducing PR-MFA?

Traditional MFA significantly improves security compared to password-only authentication. However, cybercriminals have adapted their techniques.

Today, attackers commonly use phishing websites that imitate legitimate login pages. Users unknowingly enter their credentials and approve an MFA request or type a one-time password (OTP), allowing attackers to complete the login before the code expires.

Phishing-resistant authentication is designed to prevent this type of attack.

Instead of relying on reusable codes, PR-MFA uses cryptographic authentication tied to the legitimate Salesforce website and a trusted device. Even if a user accidentally visits a fake website, the passkey or security key won’t authenticate because it recognizes that the website is not Salesforce.

This significantly reduces the risk of credential theft, account takeover, and unauthorized access to privileged accounts.

Understanding Traditional MFA vs Phishing-Resistant MFA

Many administrators assume PR-MFA is simply another name for MFA.

It isn’t.

Traditional MFA and PR-MFA share the same objective—adding a second layer of authentication—but they work differently.

Traditional MFA

Traditional Multi-Factor Authentication requires users to verify their identity using an additional factor after entering their username and password.

Common methods include:

• Salesforce Authenticator
• Google Authenticator
• Microsoft Authenticator (TOTP)
• SMS verification
• Email verification

These methods verify that the user has access to a trusted device or communication channel.

While they provide strong protection against password-only attacks, they remain susceptible to certain phishing techniques where attackers relay authentication requests or trick users into sharing one-time codes.

Phishing-Resistant MFA (PR-MFA)

PR-MFA uses modern authentication standards such as FIDO2 and WebAuthn.

Instead of asking users to enter a verification code, PR-MFA uses cryptographic keys stored securely on a trusted device or hardware security key.

Examples include:

• Passkeys
• Windows Hello
• Face ID
• Touch ID
• FIDO2 Security Keys (e.g., YubiKey)

The authentication process verifies:

1. The user’s identity.
2. The trusted device.
3. The legitimacy of the Salesforce login page.

Because no reusable verification code is exchanged, phishing websites cannot capture or replay authentication.

MFA vs PR-MFA Comparison

A Simple Example

Traditional MFA

1. User enters username and password.
2. Salesforce requests a verification code.
3. User opens Salesforce Authenticator or another authenticator app.
4. User approves the request or enters the code.
5. Login succeeds.

If the user is interacting with a phishing website, an attacker may be able to capture or relay that verification.

Phishing-Resistant MFA

1. User enters username.
2. Salesforce requests a passkey.
3. Windows Hello, Face ID, Touch ID, or a FIDO2 security key verifies the user’s identity.
4. Authentication succeeds using cryptographic verification.

If the login page is fraudulent, authentication simply doesn’t complete because the passkey is bound to the legitimate Salesforce domain.

Regular Users vs Privileged Users

One of the biggest misconceptions surrounding this update is that every Salesforce user must switch to PR-MFA.

This is not the case.

Salesforce distinguishes between regular users and privileged users, applying stronger authentication requirements only where the potential business impact is greatest.

Regular Users

Regular users typically perform business operations within Salesforce but do not have permissions to administer or significantly modify the platform.

Examples include:

• Sales Representatives
• Customer Service Agents
• Marketing Users
• HR Teams
• Finance Users
• Operations Teams

These users can continue using supported MFA methods such as:

• Salesforce Authenticator
• Google Authenticator
• Microsoft Authenticator (TOTP)
• SMS verification (where supported)
• Email verification (where supported)

No immediate migration to passkeys is required solely because of this enforcement.

Privileged Users

Privileged users have elevated permissions that allow them to manage the Salesforce environment or access sensitive data.

Examples include users with permissions such as:

• System Administrator
• Modify All Data
• View All Data
• Customize Application
• Author Apex
• Manage Users
• Security Administrator
• Other administrative or development roles

Because these users can make significant changes to the Salesforce organization, Salesforce requires them to register a phishing-resistant authentication method.

Why Only Privileged Users?

Not every Salesforce account presents the same level of risk.

If a standard sales user’s account is compromised, the attacker may only gain access to records that user can see.

However, if a privileged account is compromised, an attacker could potentially:

• Create or delete users.
• Reset passwords.
• Modify security settings.
• Export large volumes of customer data.
• Deploy or modify Apex code.
• Change automation and integrations.
• Disable security controls.

For this reason, Salesforce is applying the strongest authentication methods to accounts with the highest level of access.

Which Authentication Methods Are Supported?

Is Salesforce Authenticator Still Relevant?

Yes.

Salesforce Authenticator is not being deprecated.

It remains a supported and effective MFA solution for regular employee users.

However, Salesforce Authenticator alone does not satisfy the Phishing-Resistant MFA requirement for privileged users.

Organizations do not need to remove Salesforce Authenticator from all users. Instead, they should identify privileged users and register an additional phishing-resistant authentication method such as a passkey or FIDO2 security key.