Who must meet the phishing-resistant requirement
Salesforce defines the privileged population functionally rather than by job title. A user is in scope if any of the following applies, whether granted through a profile, a permission set, or a permission set group:
- The System Administrator profile.
- The Modify All Data permission.
- The View All Data permission.
- The Customize Application permission.
- The Author Apex permission.
Because these permissions are frequently distributed through permission sets (to integration owners, release managers, and report builders), the in-scope population is usually larger than the list of people the organization calls “admins.” An accurate inventory is the first implementation step, and an opportunity to apply least privilege: every elevated permission removed shrinks the population subject to the stricter requirement.
Out of scope: Experience Cloud (external community) users, and non-interactive API integrations using the JWT Bearer or Client Credentials OAuth flows. Interactive OAuth flows that present the Salesforce login UI (Web Server and Hybrid token flows) are subject to enforcement, which matters for third-party tools and managed-service providers that sign in as privileged users.
How Salesforce evaluates SSO authentication signals
For federated logins, Salesforce never observes the authentication ceremony at the IdP; it inspects two industry-standard claims carried in the SAML assertion or OpenID Connect (OIDC) ID token:
- AMR, or Authentication Methods Reference (RFC 8176): the specific methods used during sign-in, such as pwd (password), otp (one-time password), hwk (proof-of-possession of a hardware key), or fido2.
- ACR, or Authentication Context Class Reference: the overall assurance level of the authentication context.
Salesforce classifies the values it receives into tiers. Phishing-resistant values include fido, fido2, hwk, swk, wia, x509, cert, and smartcard; standard-MFA values include mfa, otp, and similar; anything else, or an empty claim, fails both checks. Any phishing-resistant value also satisfies the standard-MFA requirement, so a correctly configured IdP covers both tiers with one signal. Two evaluation details frequently cause surprises:
- Parsing rules differ by protocol. For SAML, Salesforce parses any attribute whose name contains amr or authn methods references; values must be semicolon-separated, and URN/URL values are split on “:” and “/” so urn:custom:auth:hwk resolves to hwk. For OIDC, the amr claim must be an array, matched exactly and case-sensitively. ACR values are lower-cased and matched with a contains() comparison.
- The accepted list evolves. In July 2026, Salesforce removed the generic multipleauthn value because Entra ID now emits granular per-method signals; organizations relying on it saw privileged users challenged mid-month with no change on their side.
The current value lists and parsing rules are maintained in the Salesforce Help article referenced at the end of this paper; treat it as the source of truth when configuring an IdP.
Why Entra SSO MFA can still trigger a secondary verification
The secondary prompt is not a malfunction; it is Salesforce’s fallback when the SSO token does not prove a phishing-resistant login for a privileged user (see figure below). The typical failing pattern is an Entra sign-in using password plus Microsoft Authenticator push or a TOTP code: genuine MFA, but standard MFA. The AMR claim reports values such as pwd and mfa, Salesforce classifies the login below the phishing-resistant tier, and the user must register and use a Salesforce-side passkey before the session is granted.
Figure 2. Evaluation of an SSO login against the phishing-resistant requirement.
Three configuration states produce the secondary challenge:
- The claims are absent. Before June 29, 2026, Entra ID did not consistently include AMR/ACR claims in SAML assertions. Entra now includes both automatically for SAML 2.0 and OIDC applications on the v2.0 endpoint; custom OIDC integrations still on v1.0 should be migrated.
- The claims show standard MFA. The user authenticated with password plus push or OTP, so the granular signal Entra now sends is truthful, and insufficient for the privileged tier.
- The claims show an unrecognized value. The authentication was genuinely phishing-resistant, but the transmitted value does not appear on Salesforce’s accepted list. Verifying the actual values received (see Validation and troubleshooting) resolves this class quickly.
The fix, therefore, is to make the Entra sign-in itself phishing-resistant for the privileged population, at which point the claim value changes and the challenge stops.
Target state: phishing-resistant authentication at Microsoft Entra ID
The recommended architecture keeps Microsoft Entra ID as the single authentication authority and satisfies Salesforce’s requirement at the point of federation. Four elements make up the target state:
- Credential enrollment. Privileged users register at least one phishing-resistant credential in Entra: a device-bound passkey, Windows Hello for Business, a FIDO2 security key, or a certificate. Registering two methods per user provides recovery headroom.
- Conditional Access enforcement. A Conditional Access policy scoped to the Salesforce enterprise application and an Entra security group containing the privileged users requires the built-in “Phishing-resistant MFA” authentication strength. The policy guarantees that these users cannot reach Salesforce with a weaker factor, and therefore that the token always carries an accepted value such as fido2, hwk, wia, or x509.
- Claim transmission. With the June 29, 2026 platform update, Entra automatically forwards granular AMR/ACR claims for SAML and OIDC tokens (including signals from an external MFA provider where one is configured), so no manual claim mapping is required for the standard Salesforce gallery application.
- Salesforce-side fallback. In Setup → Identity Verification, enable security keys and built-in authenticators, and have each administrator register a backup passkey directly in Salesforce, preserving break-glass access during an IdP outage and covering login paths that bypass SSO.
Non-privileged users require no change: their existing Entra MFA already meets the standard tier, and the same automatic claims now prove it to Salesforce.
Integration and test automation accounts
Enforcement is keyed to the login flow, not the account type. Integrations authenticating with the JWT Bearer or Client Credentials OAuth flows never present the Salesforce login UI, so MFA enforcement does not apply; this is the target state for machine-to-machine connections. By contrast, OAuth Web Server and Hybrid Token flows require an interactive login to establish tokens, and if that account is privileged, the login is now subject to phishing-resistant MFA. Three operational nuances deserve attention:
- Delayed failures via refresh tokens. An existing Web Server flow integration continues to operate on its refresh token until that token expires or is revoked; only the next re-authentication hits the new requirement. Interactive-flow integrations can therefore fail weeks after enforcement rather than on day one, so re-authentication must be exercised deliberately during sandbox validation.
- Shared accounts break. Phishing-resistant credentials are bound to a device or a passkey vault and cannot be circulated like a password. A shared “integration admin” login used by several people fails under this model; the interim remedy is a passkey held in a team-managed enterprise vault, and the target remedy is splitting the shared identity into individual accounts and a dedicated machine identity.
- Test automation. UI test suites and release-automation robots that sign in as privileged users are blocked once their org’s wave arrives. Options, in order of preference: run tests under least-privileged accounts scoped to the objects under test; bootstrap sessions through JWT Bearer where the tool supports it; or request an MFA exemption through Salesforce Support for the residual accounts; the “Waive Multi-Factor Authentication for Exempt Users” permission no longer applies automatically. Automated tests must also be updated for the new two-step login flow, which presents the username field before the password field.
The working pattern is inventory-and-migrate: list every integration login, identify its OAuth flow from the Connected App configuration and Login History, migrate interactive-flow integrations to JWT Bearer or Client Credentials where the vendor supports it, reduce each integration identity to a purpose-built permission set, and reserve exemptions for the few cases that genuinely require an interactive login, cleanly separating human administrative access from certificate-bearing machine identities.
Implementation roadmap
A four-phase approach fits most organizations and can typically be completed well within an enforcement wave.
Phase 1: Discover
- Inventory the privileged population: report on the System Administrator profile and the four privileged permissions across profiles, permission sets, and permission set groups.
- Rationalize access: remove elevated permissions that are not required; separate human admin accounts from integration identities (see previous section).
- Baseline the current signal: sample recent privileged SSO logins in Login History (Authentication Method Reference column) to see exactly which AMR values Salesforce is receiving today.
Phase 2: Configure
- Create the privileged-user security group in Entra and drive enrollment of phishing-resistant credentials, tracking completion per user.
- Deploy the Conditional Access policy in report-only mode first, confirm no unintended lockouts, then enforce.
- Enable security keys and built-in authenticators in Salesforce Identity Verification, and register Salesforce-side backup passkeys for administrators.
Phase 3: Validate in sandbox
- Sandboxes enforce ahead of production and are the natural proving ground: have pilot privileged users sign in via SSO and confirm the login is trusted without a secondary challenge.
- Inspect the raw assertion or ID token for at least one pilot login (via a SAML tracing tool or Login History for OIDC) and confirm the AMR value matches the accepted list.
Phase 4: Roll out and operate
- Enforce the policy for the full privileged group before the org’s production date, communicate the new sign-in experience, and staff the service desk for enrollment questions.
- Establish recovery procedures: a second administrator can issue a temporary verification code and reset methods for a locked-out colleague; document this path before it is needed.
- Add a periodic control: review the privileged inventory and spot-check AMR values quarterly, monitoring release notes for changes to the accepted lists.
Validation and troubleshooting
Salesforce provides two inspection points. Login History (Setup → Users → Login History) can display the Authentication Method Reference column, showing AMR values received per SSO login; for SAML, a browser tracing extension shows the full assertion, including AuthnContextClassRef and any authnmethodsreferences attribute. The table below maps common rollout symptoms.