Troubleshoot Issues with Passkey Prompts and Single Sign-On

Log In via SSO and Check Passkey Prompts

When you or a user logs in via SSO, check the passkey prompt, which can help you understand why the user sees this prompt.

Look for a message that says “Your account requires a passkey for enhanced security. Or, set up your single sign-on provider to meet Salesforce security requirements. Learn more.” Only privileged users—users with the System Administrator profile or the Modify All Data, View All Data, Customize Application, or Author Apex user permissions—see this message. This message means that Salesforce doesn’t receive a phishing-resistant authentication signal from the SSO identity provider. As a result, Salesforce requires the privileged user to create a passkey for phishing-resistant MFA.

Non-privileged users see this prompt, which doesn’t include a message about requiring a passkey for enhanced security. This prompt indicates that Salesforce doesn’t receive a phishing-resistant or standard authentication signal from the SSO identity provider. As a result, Salesforce requires the user to either create a passkey or set up another verification method, such as Salesforce Authenticator or a one-time password app.

Check the Login History

For SAML and OpenID Connect SSO, use the Login History to see what authentication signals your SSO identity provider sends.

Note For SAML SSO only, you can alternatively use the SAML Assertion Validator to check authentication method strength.

1. To reproduce the login that caused the passkey prompt, log in through SSO.
   You can skip this step if there’s an existing login history entry that you want to troubleshoot.
2. Log in to your admin account.
3. From Setup, in the Quick Find box, find and select Login History.
4. Edit your current view or create a view that includes these fields, and save the changes.
   • Authentication Context Class Reference
   • Authentication Method Reference
   
5. Find the row for your recent SSO login. Note the exact values for the Authentication Context Class Reference (ACR) and Authentication Method Reference (AMR).
6. Check the authentication method tier.
   

   Note Salesforce requires only one authentication signal, either ACR or AMR, that meets the MFA requirement for the type of user. If an SSO identity provider sends multiple values, Salesforce uses the strongest one to determine whether to prompt the user for a passkey. For example, if the SSO identity provider sends a mix of phishing-resistant and standard values, Salesforce accepts the login as phishing-resistant.

   Tier	SSO Authentication Method Reference (AMR) Signals	SSO Authentication Context Class Reference (ACR) Signals
   Phishing-Resistant MFA	cert, face, fido, fido2, fpt, hwk, iris, passkey, phr, pki, pop, pwlesspasskey, retina, sc, smartcard, smartcardpki, softwarepki, swk, tlsclient, x509	fido, fido2, fpt, hwk, passkey, phr, pki, pwlesspasskey, retina, smartcard, smartcardpki, softwarepki, swk, tlsclient, x509
   Standard MFA	mfa, mobiletwofactorcontract, okta_verify, pin, pgp, publickey, rsa, timesynctoken, user, vbm	mfa, mobiletwofactorcontract, okta_verify, pgp, publickey, rsa, timesynctoken, vbm
   Weak or no MFA	pwd, sms, tel, email

7. If an authentication signal doesn’t match what you expect from your SSO identity provider, review how Salesforce evaluates these signals.

   Protocol	Claim	Matching Strategy	Example
   OpenID Connect	AMR	Salesforce compares each value in an OpenID Connect AMR array, such as [hwk, mfa], for an exact match. This value is case-sensitive.	hwk matches ✓ HWK doesn’t match ✗
   OpenID Connect	ACR	Salesforce checks whether the ACR element contains the value, so short tokens like mfa match full Uniform Resource Names (URNs) such as urn:oasis:names:tc:SAML:2.0:ac:classes:mfa. This value isn’t case-sensitive.	urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard → lowercase → contains smartcard ✓
   SAML	AMR	Salesforce parses and evaluates attribute values in a semicolon-separated string (such as hwk;face;mfa). Comma-separated values aren’t evaluated. This value isn't case-sensitive.	hwk matches HWK ✓ (case-insensitive) urn:custom:auth:mfa → splits to segments → mfa matches ✓ https://example.com/auth/hwk → splits on / → hwk matches ✓
   SAML	ACR	Salesforce checks whether the ACR element contains the value, so short tokens like mfa match full URNs like urn:oasis:names:tc:SAML:2.0:ac:classes:mfa. This value isn’t case-sensitive.	urn:oasis:names:tc:SAML:2.0:ac:classes:MFA → lowercase → contains mfa ✓

Check the SAML Assertion Validator

1. Contact your SSO identity provider and obtain a SAML assertion in plain XML, base-64 encoded, or deflated and base-64 encoded format.
   

   Note If a user can’t log in to Salesforce, Salesforce automatically enters the invalid SAML assertion into the validator, if possible. Some errors prevent Salesforce from entering the assertion automatically.
2. From Setup, use the Quick Find box to find and select Single Sign-On Settings.
3. Click SAML Assertion Validator.
4. If the SAML assertion isn’t already entered from a failed login, enter the SAML assertion from your SSO identity provider and click Validate.
   

   Note If your org has multiple SAML SSO configurations, the validator tries to detect the right one. To select a configuration, click the dropdown arrow next to Auto detect config.
5. Check result number 2 for a list of all phishing-resistant, standard, and weak AMR and ACR values that Salesforce detected.

   In this example screenshot, Salesforce detected phishing-resistant, standard, and weak values. The SSO login in this example is phishing-resistant because it contains at least one phishing-resistant value. It doesn’t matter that it contains standard and weak values. With this SAML configuration, Salesforce doesn't prompt any employee users for a passkey.

   

Configure Your SSO Identity Provider to Send Supported Authentication Signals