Salesforce Phishing-Resistant MFA 2026: Entra ID, AMR Signals, and How to Stay Compliant

If your privileged Salesforce users are completing MFA at Microsoft Entra ID and still getting challenged a second time inside Salesforce, the problem is in what your identity provider is asserting in the token it sends downstream. The fix sits at the identity provider.

Beginning in 2026, Salesforce enforces two authentication requirements simultaneously: multi-factor authentication on every login for all users, and phishing-resistant MFA for privileged users such as System Administrators and anyone with Modify All Data, View All Data, Customize Application, or Author Apex permissions, across direct logins and SSO alike. For organizations on Microsoft Entra ID, enforcement has surfaced a specific failure: privileged users who already completed MFA at Entra are being prompted again inside Salesforce because the token Entra sent did not carry a signal proving a phishing-resistant method was used.

What Salesforce Changed in 2026 and Why Entra ID Users Are Getting Challenged Twice

Salesforce has required MFA for internal users since 2022, but enforcement was never technically locked. In 2026, that changed. Salesforce now enforces two distinct authentication tiers with no opt-out at the org level.

The first tier covers every internal user. Standard MFA is required on every login, whether direct or through an SSO provider, across production and sandbox environments. 

The second tier applies specifically to privileged users, defined as anyone with the System Administrator profile or any of the following permissions: Modify All Data, View All Data, Customize Application, or Author Apex, whether those permissions come through a profile, a permission set, or a permission set group. 

For this group, TOTP apps, push notifications, SMS, and email codes no longer qualify. Salesforce requires phishing-resistant MFA enforcement for privileged users built on FIDO2 and WebAuthn standards. Enforcement is staggered by release group, with production rollout running from July 20 through September 3, 2026. To find the specific date for your org, identify your Salesforce instance and cross-reference it against the Release Group Enforcement Schedule. 

For organizations on Microsoft Entra ID, this is creating a specific problem. Privileged users complete MFA at Entra, the SSO flow completes, and Salesforce still issues a second challenge. The reason is in the token; Salesforce does not observe what happened at the identity provider. It reads the AMR and ACR values inside the SAML assertion or OIDC token, and if those values reflect standard MFA rather than phishing-resistant MFA, the login is treated as non-compliant regardless of what Entra actually performed.

How Salesforce Evaluates Your SSO Login 

When a user signs into Salesforce through an identity provider, Salesforce does not see the authentication itself. It reads two claims inside the token the identity provider sends: AMR and ACR.

ACR, or Authentication Context Class Reference, is a summary label. It tells Salesforce the overall assurance level of the authentication that took place. AMR, or Authentication Methods Reference, is more granular. It is a list of the specific methods the user actually used during sign-in, values like pwd for password, mfa for some form of multi-factor, otp for a one-time passcode, or hwk for a hardware key.

Salesforce takes those values and maps them to one of three tiers: phishing-resistant, standard MFA, or weak and non-compliant. For privileged users, only the phishing-resistant tier grants access without a secondary challenge. Values like fido2, hwk, face, and fpt clear that bar. Values like mfa, otp, and vbm land in the standard tier, which is insufficient for privileged users. If the claims are absent entirely, Salesforce treats the login as non-compliant.

The Configuration Gap Entra ID Users Are Running Into Right Now 

Most Entra ID environments are doing genuine multi-factor authentication. The problem shows up in what gets reported in the token after that authentication completes.

Here is what the failing flow looks like:

• User signs into Salesforce through Entra ID with a password and Microsoft Authenticator push
• MFA completes at the identity provider
• Entra puts a generic MFA value in the AMR claim of the SAML assertion
• Salesforce reads MFA, maps it to the standard tier
• User is privileged, standard tier is insufficient, Salesforce issues a secondary challenge

What Entra reported in the token did not reflect what the user actually completed. 

This played out at scale in July 2026 when Salesforce removed multipleauthn from its accepted signal list. Organizations relying on that generic Entra value to confirm multi-factor authentication saw privileged users blocked mid-month with no configuration change on their end. multipleauthn confirmed that multiple methods were used but never identified which ones, making it impossible for Salesforce to distinguish a phishing-resistant factor from a weaker one.

The second version of this problem is specific to organizations using an external MFA provider alongside Entra. Some external MFA integrations with Entra do not surface the authentication method in a form that gets forwarded to Salesforce. The user authenticates with a strong method at the external provider, but Salesforce receives either a generic claim or no AMR claim at all.

This is where the configuration of the external provider matters as much as the authentication method itself. Starting June 29, 2026, Microsoft updated Entra to automatically forward AMR signals from external authentication providers to downstream applications, including Salesforce, with no additional configuration required on the Entra side. The question is whether the external provider is sending the right signal in the first place.

What the June 29 Entra Update Means for External MFA Providers

Before June 29, 2026, Microsoft Entra ID did not consistently include AMR and ACR claims in SAML assertions. Organizations configuring external MFA providers had no reliable way to get those signals forwarded to downstream applications like Salesforce. That changed with a platform update Microsoft pushed on June 29, 2026. Entra now automatically includes AMR and ACR claims in tokens for SAML 2.0 and OIDC applications, and if an external MFA provider is configured and sending AMR signals, Entra forwards them to Salesforce with no additional configuration required.

Microsoft Entra supports a capability called External Authentication Methods, which allows organizations to register a third-party provider as the MFA layer inside Entra rather than relying on Microsoft Authenticator or a hardware key. OLOID Face registers as that external provider. When a user authenticates, OLOID performs a facial biometric verification and returns a face AMR signal to Entra, which Entra forwards downstream in the token it sends to Salesforce.

The flow looks like this:

• User initiates login to Salesforce via Entra SSO
• Entra triggers the OLOID Face challenge as the registered External Authentication Method
• User completes facial biometric verification through OLOID
• OLOID returns the face AMR value to Entra
• Entra includes face in the AMR claim of the SAML assertion sent to Salesforce
• Salesforce reads face, maps it to the phishing-resistant tier
• Login succeeds, no secondary challenge, no Salesforce-side enrollment required

face is on Salesforce's accepted phishing-resistant AMR value list. It satisfies the requirement for privileged users. Because the signal travels through Entra's standard token flow, there is no custom claim mapping, no rearchitecting of the identity stack, and no changes required on the Salesforce side. 

Choosing the Right Method for Your Environment 

Passkeys and hardware security keys are the right answer for a large portion of the privileged user population. A corporate administrator on a dedicated laptop can enroll a passkey or a FIDO2 key once and authenticate in a single gesture from that point forward. For that user, the approach works exactly as designed.

The model runs into specific problems in environments where the one-person-one-device assumption does not hold. Two specific problems come up: 

• Passkeys are device-bound. In environments where multiple workers share the same terminal across shifts, each worker needs their own enrolled credential on their own device. For frontline teams, that device often does not exist.
• Hardware security keys are physical objects. On a warehouse floor or a hospital ward, they get lost, forgotten, or damaged. Re-enrollment at scale across a shift-based workforce becomes an operational problem the identity team was never meant to own.

The privileged users who create this problem in frontline environments are not hypothetical. Clinical operations managers logging into Salesforce to pull patient data reports carry View All Data. Plant supervisors running production floor analytics carry the same. Field service leads with Customize Application permissions are managing org configuration from shared kiosks between calls. These are the accounts that get targeted precisely because they carry broad data access and sit outside the corporate laptop model. 

The stronger framing is that different environments need different methods. Passkeys for corporate admins on assigned devices. Biometric EAM for shared terminals and shift-based workforces. OLOID covers both populations through a single Entra integration, which means both methods earn their place depending on the environment. 

What Security Teams Ask About Facial Biometrics

Facial biometric authentication raises legitimate questions that any security buyer should ask before deployment. Here is how OLOID addresses the ones that come up most often.

On privacy and consent: OLOID Face is designed to comply with biometric privacy regulations including BIPA and GDPR. Biometric data is stored as a mathematical representation of facial geometry with no path back to the original image. Enrollment requires explicit user consent, and data retention policies are configurable to meet organizational and jurisdictional requirements.

On liveness and spoof resistance: OLOID Face uses active liveness detection to distinguish a live person from a photograph, video replay, or mask. The liveness check fires on every authentication, not just enrollment, which means a captured image of a worker cannot be used to pass the verification.

On the fallback path: When a face check fails, whether from lighting conditions, a physical change in appearance, or a device issue, OLOID keeps the user moving. A configurable fallback path allows a secondary verification method to be used, and administrators can issue temporary access while the primary method is restored. For shift-based environments where a 3 am lockout is a real operational problem, the fallback path is as important as the primary one.

How Entra SSO + OLOID Face Delivers a Phishing-Resistant AMR Signal to Salesforce

OLOID Face registers inside Microsoft Entra ID as an External Authentication Method. That registration is what puts it in the token flow. When a privileged user initiates a Salesforce login through Entra SSO, Entra triggers OLOID Face as the MFA layer. The user completes a facial biometric verification, OLOID returns the face AMR value to Entra, and Entra forwards it in the SAML assertion to Salesforce. Salesforce reads face, maps it to the phishing-resistant tier, and grants access. No secondary challenge, no Salesforce-side enrollment, no hardware to procure.

For frontline and shared-device environments, the signal flow is the same. The biometric travels with the worker. A user can authenticate on any shared terminal in the org without a pre-enrolled passkey or a hardware key in their pocket.

OLOID supports AMR and ACR signal values as part of its EAM integration with Microsoft Entra ID, giving Salesforce the exact claim it needs to confirm phishing-resistant authentication without any custom claim mapping or changes to your existing Salesforce SSO configuration.

How to Verify Your AMR Signal Is Landing in Salesforce

Once OLOID Face is configured as the External Authentication Method in Entra and a privileged user completes their first login, Salesforce gives you two ways to confirm the right signal is coming through.

The first is Login History. In Salesforce Setup, navigate to Users and open Login History. From there, add the Authentication Method Reference column to your view. For any SSO login where OLOID Face fired as the EAM, that column should show face. If it does, the login has been classified as phishing-resistant and no secondary challenge will fire for that user going forward.

The second is the SAML Assertion Validator, also in Salesforce Setup. This tool lets you inspect the raw SAML response your identity provider is sending and confirms how Salesforce is classifying each AMR and ACR value it receives. As of Summer 2026, the validator now classifies each signal as phishing-resistant, standard, or weak, replacing the previous two-tier model. If face is present in the assertion and classified as phishing-resistant, the configuration is working correctly.

What you are looking for in both tools:

• AMR value shows face in Login History
• SAML Assertion Validator classifies the signal as phishing-resistant
• No secondary MFA prompt appearing for privileged users after SSO login

If the AMR column is empty or showing a standard tier value, the issue sits upstream at the Entra EAM configuration. That is where to look first before adjusting anything on the Salesforce side.
If your privileged users are hitting the double-prompt today, the resolution runs through your identity provider, with no new hardware, no passkey rollout, and no changes to your Salesforce SSO configuration. OLOID Face delivers the signal through your existing Entra integration. 

Book a demo to see the configuration in your environment.