---
schema_version: "1"
id: d9852de2578271d8ac8293ed2aa89ef9bc5d6e0a82bcfcadf41df296d29ca68a
title: Troubleshoot Issues with Passkey Prompts and Single Sign-On
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/mfa_passkey_sso_prompt_after_mfa.md
canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.mfa_passkey_sso_prompt_after_mfa.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 2f66f642363866c459c53cf39dc1b124c83d61aaf260fb3f56be1531603313c2
description: A user logs in through a single sign-on (SSO) identity provider, such as Okta or Microsoft Entra ID, and completes multi-factor authentication. Before the user can access Salesforce, another prompt asks them to create a passkey. Troubleshoot the authentication signals that cause this issue. This guide includes troubleshooting steps for both Security Assertion Markup Language (SAML) and OpenID Connect.
products:
  - Security
release: "264"
---
# Troubleshoot Issues with Passkey Prompts and Single Sign-On

A user logs in through a single sign-on (SSO) identity provider, such as Okta or Microsoft Entra ID, and completes multi-factor authentication. Before the user can access Salesforce, another prompt asks them to create a passkey. Troubleshoot the authentication signals that cause this issue. This guide includes troubleshooting steps for both Security Assertion Markup Language (SAML) and OpenID Connect.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition">
        <colgroup>
          <col>
        </colgroup>
        <tbody>
          <tr class="">
            <td class="slds-cell-wrap" style="vertical-align:top;">Available in: both Salesforce Classic and Lightning Experience</td>

          </tr>
          <tr class="">
            <td class="slds-cell-wrap" style="vertical-align:top;">
              <p>Federated authentication is available in: <strong>All</strong> Editions</p>
              <p style="margin-bottom:0;">Authentication
                Providers are available in: <strong>Professional</strong>, <strong>Enterprise</strong>, <strong>Performance</strong>,
                <strong>Unlimited</strong>, and <strong>Developer</strong> Editions
              </p>
            </td>

          </tr>
        </tbody>
      </table> <table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small permission">
        <colgroup>
          <col style="width:50%">
          <col style="width:50%">
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="colgroup" class="slds-cell-wrap" colspan="2" style="text-align:center;vertical-align:top;" id="d61186e78">User Permissions Needed</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e78 ">To monitor logins:</td>

            <td class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e78 ">
              <p>Monitor Login History</p>
              <p>OR</p>
              <p style="margin-bottom:0;">Manage Users</p>
            </td>

          </tr>
          <tr class="">
            <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e78 ">To use the Security Assertion Markup Language (SAML) Assertion Validator:</td>

            <td class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e78 ">
              <p>View Setup and Configuration</p>
              <p>AND</p>
              <p>Customize Application </p>
              <p style="margin-bottom:0;">AND</p>
              <p style="margin-bottom:0;">Modify All
                Data</p>
            </td>

          </tr>
        </tbody>
      </table>

To bypass this passkey prompt, Salesforce requires SSO identity providers to send authentication signals during login to prove that they meet MFA requirements. If a user sees a passkey prompt after completing MFA, it means that Salesforce doesn’t receive accepted signals from the SSO identity provider. For an overview of how SSO identity providers send authentication signals, see [MFA with an SSO Identity Provider](https://help.salesforce.com/s/articleView?id=xcloud.mfa_sso_thirdparty_idp.htm&release=264.0.0&type=5 "With single sign-on (SSO), users log in to Salesforce from another site, like Google (the SSO identity provider). To help prevent unauthorized access to Salesforce accounts, you're required to use multi-factor authentication (MFA) when logging in via SSO. You can set up an SSO flow where users log in to the identity provider and complete MFA before they're redirected to Salesforce. To use this option, Salesforce requires your identity provider to send specific authentication signals that indicate the MFA method.").

Salesforce requires [phishing-resistant MFA for privileged users](https://help.salesforce.com/s/articleView?id=005321563&type=1&language=en_US). Employee users who don’t have these permissions (non-privileged users) can satisfy [their MFA requirement](https://help.salesforce.com/s/articleView?id=005321561&type=1&language=en_US) with either phishing-resistant or standard MFA. For more information about phishing-resistant and standard MFA verification methods, see [MFA Verification Method Tiers](https://help.salesforce.com/s/articleView?id=xcloud.mfa_security_tiers.htm&release=264.0.0&type=5 "The multi-factor authentication (MFA) login process requires users to provide an identity verification method in addition to their username and password. Salesforce supports several types of verification methods, including passkeys (built-in authenticators and security keys) and authenticator apps. Some verification methods are stronger than others. Salesforce requires users with privileged permissions, such as admins, to use more secure methods.").

## 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](https://help.salesforce.com/s/articleView?id=005321563&type=1&language=en_US).” 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.

![Create a Passkey prompt for privileged users when the SSO provider doesn’t send a phishing-resistant authentication signal](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/security/images/mfa/troubleshooting_passkey_prompt_admin_sso.png)

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.

![Create a Passkey prompt for non-privileged users when the SSO provider doesn’t use an accepted MFA method (either phishing-resistant or standard)](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/security/images/mfa/troubleshooting_passkey_prompt_nonadmin_choice.png)

## 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_note.png)

Note For SAML SSO only, you can alternatively use the [SAML Assertion Validator](https://help.salesforce.com/s/articleView?id=xcloud.mfa_passkey_sso_prompt_after_mfa.htm&release=264.0.0&type=5) 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
    
    ![Login History edit view with Authentication Context Class Reference and Authentication Method Reference fields highlighted](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/security/images/mfa/troubleshooting_sso_login_history.png)
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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_note.png)
    
    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.
    
    <table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
              <colgroup>
                <col style="width:33.33333333333333%">
                <col style="width:33.33333333333333%">
                <col style="width:33.33333333333333%">
              </colgroup>
              <thead class="slds-text-title_caps ">
                <tr class="">
                  <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d61186e312">Tier</th>
                  <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d61186e315">SSO Authentication Method Reference (AMR) Signals</th>
                  <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d61186e318">SSO Authentication Context Class Reference (ACR) Signals</th>
                </tr>
              </thead>
              <tbody>
                <tr class="">
                  <td data-label="Tier" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e312 ">Phishing-Resistant MFA</td>

                  <td data-label="SSO Authentication Method Reference (AMR) Signals" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e315 ">cert, face, fido, fido2, fpt, hwk, iris, passkey, phr, pki, pop, pwlesspasskey,
                    retina, sc, smartcard, smartcardpki, softwarepki, swk, tlsclient, x509</td>

                  <td data-label="SSO Authentication Context Class Reference (ACR) Signals" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e318 ">fido, fido2, fpt, hwk, passkey, phr, pki, pwlesspasskey, retina, smartcard,
                    smartcardpki, softwarepki, swk, tlsclient, x509</td>

                </tr>
                <tr class="">
                  <td data-label="Tier" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e312 ">Standard MFA</td>

                  <td data-label="SSO Authentication Method Reference (AMR) Signals" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e315 ">mfa, mobiletwofactorcontract, okta_verify, pin, pgp, publickey, rsa, timesynctoken,
                    user, vbm</td>

                  <td data-label="SSO Authentication Context Class Reference (ACR) Signals" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e318 ">mfa, mobiletwofactorcontract, okta_verify, pgp, publickey, rsa, timesynctoken,
                    vbm</td>

                </tr>
                <tr class="">
                  <td data-label="Tier" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e312 ">Weak or no MFA</td>

                  <td data-label="SSO Authentication Method Reference (AMR) Signals" class="slds-cell-wrap" colspan="2" style="vertical-align:top;" headers="d61186e315 d61186e318 ">pwd, sms, tel, email</td>

                </tr>
              </tbody>
            </table>
7. If an authentication signal doesn’t match what you expect from your SSO identity provider, review how Salesforce evaluates these signals.
    
    <table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
              <colgroup>
                <col style="width:25%">
                <col style="width:25%">
                <col style="width:25%">
                <col style="width:25%">
              </colgroup>
              <thead class="slds-text-title_caps ">
                <tr class="">
                  <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d61186e386">Protocol</th>
                  <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d61186e389">Claim</th>
                  <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d61186e392">Matching Strategy</th>
                  <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d61186e395">Example</th>
                </tr>
              </thead>
              <tbody>
                <tr class="">
                  <td data-label="Protocol" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e386 ">OpenID Connect</td>

                  <td data-label="Claim" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e389 ">AMR</td>

                  <td data-label="Matching Strategy" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e392 ">Salesforce compares each value in an OpenID Connect AMR array, such as
                    <code>[hwk, mfa]</code>, for an exact match. This value is case-sensitive.
                  </td>

                  <td data-label="Example" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e395 ">
                    <p><code>hwk</code> matches ✓ </p>
                    <p style="margin-bottom:0;"><code>HWK</code> doesn’t match ✗</p>
                  </td>

                </tr>
                <tr class="">
                  <td data-label="Protocol" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e386 ">OpenID Connect</td>

                  <td data-label="Claim" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e389 ">ACR</td>

                  <td data-label="Matching Strategy" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e392 ">Salesforce checks whether the ACR element contains the value, so short tokens like
                    <code>mfa</code> match full Uniform Resource Names (URNs) such as
                    <code>urn:oasis:names:tc:SAML:2.0:ac:classes:mfa</code>. This value isn’t
                    case-sensitive.
                  </td>

                  <td data-label="Example" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e395 "><code>urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard</code> → lowercase →
                    contains <code>smartcard</code> ✓</td>

                </tr>
                <tr class="">
                  <td data-label="Protocol" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e386 ">SAML</td>

                  <td data-label="Claim" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e389 ">AMR</td>

                  <td data-label="Matching Strategy" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e392 ">Salesforce parses and evaluates attribute values in a semicolon-separated string
                    (such as <code>hwk;face;mfa</code>). Comma-separated values aren’t evaluated. This
                    value isn't case-sensitive.</td>

                  <td data-label="Example" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e395 ">
                    <p><code>hwk</code> matches <code>HWK</code> ✓ (case-insensitive)</p>
                    <p><code>urn:custom:auth:mfa</code> → splits to segments → <code>mfa</code>
                      matches ✓</p>
                    <p style="margin-bottom:0;"><code>https://example.com/auth/hwk</code> → splits on / → <code>hwk</code>
                      matches ✓</p>
                  </td>

                </tr>
                <tr class="">
                  <td data-label="Protocol" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e386 ">SAML</td>

                  <td data-label="Claim" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e389 ">ACR</td>

                  <td data-label="Matching Strategy" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e392 ">Salesforce checks whether the ACR element contains the value, so short tokens like
                    <code>mfa</code> match full URNs like
                    <code>urn:oasis:names:tc:SAML:2.0:ac:classes:mfa</code>. This value isn’t
                    case-sensitive.
                  </td>

                  <td data-label="Example" class="slds-cell-wrap" style="vertical-align:top;" headers="d61186e395 "><code>urn:oasis:names:tc:SAML:2.0:ac:classes:MFA</code> → lowercase → contains
                    <code>mfa</code> ✓
                  </td>

                </tr>
              </tbody>
            </table>

## Check the SAML Assertion Validator

For SAML SSO only, you can use the SAML Assertion Validator to see whether a value is phishing-resistant, standard, or weak.

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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_note.png)
    
    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](https://help.salesforce.com/s/articleView?id=xcloud.basics_nav_setup.htm&language=en_US&type=5), 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_note.png)
    
    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.
    
    ![SAML Assertion Validator results with weak and phishing-resistant values](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/security/images/mfa/troubleshoot_saml_validator.png)

## Configure Your SSO Identity Provider to Send Supported Authentication Signals

Work with your SSO identity provider to send supported authentication signals for the Salesforce MFA requirement. For high-level setup steps, see [Set Up MFA with an SSO Provider](https://help.salesforce.com/s/articleView?id=xcloud.mfa_sso_use_thirdparty_steps.htm&release=264.0.0&type=5 "With single sign-on (SSO), users log in to Salesforce from another site, like Google (the SSO identity provider). Salesforce requires multi-factor authentication (MFA) when logging in via SSO. Here's how you can use your SSO identity provider's MFA service to satisfy the requirement. With this SSO flow, users log in to the identity provider and complete MFA before they're redirected to Salesforce.").

If you can’t update your SSO identity provider immediately, temporarily use the Salesforce MFA service in addition to your SSO identity provider’s MFA.

#### See Also

- [Troubleshoot Passkey Issues](https://help.salesforce.com/s/articleView?id=xcloud.mfa_supported_verification_methods_bia.htm&release=264.0.0&type=5 "When employee users log in and register for multi-factor authentication (MFA), passkeys are the default option. Identify and resolve issues with passkey prompts, setup, login, and more.")