Phishing-resistant authentication is arriving.

What is phishing-resistant MFA?

Traditional MFA significantly improves security, but not every second factor provides the same protection. Codes from SMS, email, or authenticator apps can still be entered into a convincing phishing site. Push notifications can be exploited through prompt fatigue or social engineering.

Phishing-resistant authentication uses public-key cryptography and binds the authentication attempt to the legitimate website. A passkey created for Salesforce cannot simply be captured on a fake site and replayed against the real login page.

Salesforce identifies built-in authenticators and security keys using FIDO2 and WebAuthn as phishing-resistant methods. Common examples include:

• Windows Hello.
• Touch ID or Face ID used with a passkey.
• Device-bound or synchronized passkeys.
• FIDO2 hardware security keys.

The practical difference is origin binding: the credential is cryptographically tied to the legitimate service, making it substantially more resistant to adversary-in-the-middle phishing. Salesforce explains the supported methods in its privileged-user MFA guidance.

Who must use phishing-resistant MFA?

The stricter requirement applies to Salesforce administrators and other users with elevated access. A user is considered privileged when they have the System Administrator profile or any of these permissions:

• Modify All Data.
• View All Data.
• Customize Application.
• Author Apex.

Those permissions can come from a profile, permission set, or permission set group, so the affected population can extend beyond people formally identified as administrators. The requirement covers direct Salesforce UI and SSO logins in production and sandbox environments.

Salesforce's current schedule begins with sandboxes on July 10, 2026 and production release groups beginning July 20, 2026. The rollout is staggered by release group, so admins should confirm their instance-specific date in the Salesforce security roadmap.

Standard MFA is still enforced for other employees.

Employee users who are not considered privileged remain subject to Salesforce's general MFA enforcement, including users entering through SSO. A standard MFA method can satisfy this broader requirement, while privileged users must meet the higher phishing-resistant standard.

This creates a two-tier authentication model. Organizations need more than a general statement that “MFA is enabled.” They need to verify which users are privileged and which methods those users actually complete.

How Salesforce evaluates SSO.

Using SSO does not automatically satisfy Salesforce's MFA requirements. When a user signs in through an identity provider, Salesforce looks for authentication information in the SAML assertion or OIDC token.

That evidence is commonly represented through AMR, or Authentication Method Reference, and ACR, or Authentication Context Reference. These claims tell Salesforce how the identity provider authenticated the user—for example, with a password, push, one-time code, FIDO2 passkey, Windows Hello, or certificate.

Salesforce then evaluates the signal to determine whether the event satisfies standard MFA or phishing-resistant MFA. This is why SSO alone is not enough: Salesforce needs evidence that the identity provider required an acceptable method during that specific event. The platform's expanded signal support is documented in the Salesforce release notes.

Microsoft Entra now sends richer authentication signals.

The Microsoft Entra integration was initially a major area of uncertainty. Historically, Entra SAML assertions could expose a broad indication that multiple authentication occurred without clearly identifying whether the method was a passkey, Windows Hello, push, or one-time code.

Microsoft has updated the Salesforce integration. Beginning June 29, 2026, Entra ID automatically includes AMR and ACR claims in SAML 2.0 and OIDC tokens issued for Salesforce. Microsoft states that no custom Entra claim configuration is required for the standard Salesforce SSO integration.

The richer signal resolves the claim-transmission problem, but it does not automatically make every Entra login compliant. Microsoft's current implementation notes are available in its Salesforce SSO configuration guide.

Automatic claims do not equal automatic compliance.

The Entra update means Salesforce can receive the authentication information. It does not guarantee that the user was required to use a phishing-resistant method.

An Entra user may still be allowed to authenticate with Authenticator push, TOTP, SMS, or another standard MFA method. Entra will accurately report the method, but Salesforce can determine that it satisfies only standard MFA—not the phishing-resistant requirement for privileged users.

Organizations using Entra should create or update a Conditional Access policy that requires the built-in Phishing-resistant MFA authentication strength for the appropriate Salesforce users. Microsoft recommends evaluating a new policy in report-only mode before enforcement and maintaining carefully secured emergency-access exclusions to reduce lockout risk.

A typical policy design includes:

• The Salesforce enterprise application as the target resource.
• A group containing Salesforce administrators and privileged users.
• The Require authentication strength grant control.
• The Phishing-resistant MFA strength.
• Appropriate emergency-access exclusions.
• Report-only testing before enforcement.

Microsoft documents the available methods and policy behavior in its authentication-strength guidance. The policy determines what method the user must perform; AMR and ACR allow Salesforce to verify that the requirement was satisfied.

What happens when the SSO signal is insufficient?

If Salesforce does not receive an acceptable phishing-resistant signal for a privileged user, the SSO event may not satisfy the requirement. The user can be prompted to register and use a Salesforce-supported phishing-resistant method, and someone unable to complete the required challenge can be prevented from continuing into the org.

Administrators should not wait for enforcement to discover what the identity provider is sending. Test:

• A privileged user using a FIDO2 passkey or Windows Hello.
• A privileged user attempting Authenticator push or TOTP.
• A nonprivileged user completing standard MFA.
• A direct Salesforce login, where permitted.
• Both sandbox and production SSO configurations.
• The Salesforce SAML Assertion Validator and Entra sign-in logs.

The test should prove not only that SSO succeeds, but that Salesforce recognizes the authentication at the correct assurance level.

Report exports have their own authentication controls.

Salesforce is also adding verification at the point where users access or extract sensitive data. This is separate from the phishing-resistant login requirement.

After customer feedback during the initial rollout, Salesforce narrowed its periodic report step-up behavior to report exports rather than every report or dashboard view. Salesforce also added exemptions and fixes for several scenarios:

• Sessions covered by configured profile or org IP restrictions can be exempt.
• Sessions locked to their originating IP address can be exempt.
• Embedded dashboards no longer trigger unusable prompts.
• Background automation and scheduled jobs bypass the interactive challenge.
• Admins using “Login As” no longer send the challenge to the end user.
• Salesforce mobile app and Experience Cloud users are exempt from this enforcement.

Salesforce says those refinements are deployed without an administrator activation step. Current details and change history are maintained in the security-related product updates article.

Time-based and risk-based step-up are different.

Time-based step-up

The time-based control requires another identity-verification challenge when the configured verification window has expired and the user attempts to export a report. Salesforce supports a window between 2 and 120 minutes, with 120 minutes as the default.

Anomalous-behavior step-up

Salesforce can also use behavioral analysis to identify report activity that differs significantly from a user's normal behavior. When suspicious activity is detected, it can require another challenge on the next report export or sensitive action—even if the user recently completed a time-based challenge.

Production enforcement for anomalous report behavior began July 13, 2026. The distinction matters: time-based step-up is predictable and based on elapsed time; anomalous step-up is risk-based and can occur whenever Salesforce identifies unusual activity.

Additional protection for large exports.

Salesforce Shield and Event Monitoring customers also receive enhanced Transaction Security Policy protections. Salesforce's default ReportEvent policy can trigger when a user exports more than 10,000 records through the Salesforce UI and can require step-up authentication before the data leaves the org.

Salesforce is also introducing a dedicated Modify Transaction Security Policy permission to control who can manage these policies. Together, the platform can provide several layers of export protection:

1. Periodic step-up verification.
2. Behavioral anomaly detection.
3. Transaction Security Policies for high-volume exports.
4. Existing permissions controlling who can export reports.

The right factor, for the right user, at the right moment.

Salesforce's latest security changes are not simply another MFA rollout. The platform is moving toward authentication based on assurance level, user privilege, action sensitivity, and behavioral risk.

For organizations using Microsoft Entra ID, the integration is now clearer: Entra automatically sends the detailed AMR and ACR claims Salesforce needs. Organizations must still use Conditional Access to ensure privileged users actually authenticate with a phishing-resistant method.

The goal is not just to prove that a second factor occurred. It is to prove that the right factor occurred, for the right user, before access to sensitive Salesforce data is granted.