MFA and Phishing-Resistant MFA Post-Enforcement Passkey Prompts and Extension Behavior

Passkey First MFA Registration Flow

It is important to note a key update to the login experience for all users: passkey registration is now prompted by default for ALL users upon login. Refer to the following Release Note for reference. 

If a user attempts to log in without having an MFA method registered, the system displays a prompt to “Create a Passkey”. Depending on the user type determined from their assigned privileges, they may also see an option to select Another Verification Method located immediately below the primary Create Passkey button.. 

User types are defined by their assigned privileged as follows:

1. Privileged Users (Including Administrators): Any user assigned to at least one of these privileged administrative permissions: 

   1. System Administrator profile (or custom profile cloned from it) OR

   2. Modify All Data (MAD) permission OR

   3. View All Data (VAD) permission OR

   4. Customize Application permission OR

   5. Author Apex permission

2. Non-Privileged User: Any user who does not have any of the following: System Administrator profile (or custom profile cloned), Modify All Data, View All Data, Customize Application, or Author Apex.

See below for the user login flow based on the user type:

Extension Use Cases & Expected Behavior

Note: For the Use Case Details below we refer to the Org-Wide MFA Setting [in Setup-> Identity Verification] “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” as: Org-Wide MFA setting "Require MFA" for brevity.

Use Case #1: Default: No Extensions

Configuration

• MFA For All Employees Extension:  Not Granted
• Phishing-Resistant MFA (Passkeys) Extension:  Not Granted
• Org-Wide MFA setting "Require MFA": (Not Controllable by org admins without the MFA For All Employees Extension): Force-Enabled by Salesforce

Behavior

• Non-Privileged Users: Must use at least Standard MFA (TOTP, Salesforce Authenticator, or  Phishing-Resistant MFA)
• Privileged Users: Must use Phishing-Resistant MFA (Passkeys, Security Keys, Built-in Authenticators)

Notes

• This is the highest security baseline and intended behavior enforced by Salesforce Platform
• Privileged Users cannot satisfy the Phishing-Resistant MFA requirement with TOTP or Salesforce Authenticator
• Org admins cannot disable the MFA requirement in Setup (toggle is greyed out/hidden) without the MFA For All Employees extension
• Non-Privileged users must use at least TOTP apps to meet the Standard MFA requirement, and are also prompted to register a Passkey by default.

Use Case #2: Phishing-Resistant MFA Extension Only

Configuration

• MFA For All Employees Extension: Not Granted
• Phishing-Resistant MFA (Passkeys) Extension: Granted
• Org-Wide MFA setting "Require MFA": (Not Controllable by org admins without the MFA For All Employees Extension): Force-Enabled by Salesforce.

Behavior

• Non-Privileged Users: Must use at least Standard MFA
• Privileged Users: Must use at least Standard MFA (Phishing-Resistant MFA no longer required)

Notes

• Privileged Users are temporarily downgraded from the Phishing-Resistant MFA requirement to Standard MFA requirement while the extension is in effect.
• Privileged Users will still see the option to Create Passkey. But will still have the option to Choose Another Verification Method.
• Org admins still cannot disable the MFA requirement in Setup 
• Non-Privileged users must use at least TOTP apps to meet the Standard MFA requirement, and are also prompted to register a Passkey by default.

Possible Scenario

Orgs that need Standard MFA for admins but cannot deploy Phishing-Resistant MFA yet

Use Case #3: MFA For All Employees Extension Only & Org-Wide MFA setting Enabled

Configuration

• MFA For All Employees Extension:  Granted
• Phishing-Resistant MFA (Passkeys) Extension:  Not Granted
• Org-Wide MFA setting "Require MFA":  Enabled (org admin chooses to keep it on)

Behavior

• Non-Privileged Users: Must use at least Standard MFA
• Privileged Users: Must use Phishing-Resistant MFA

Notes

• This scenario is functionally identical to Use Case # 1
• Difference: Org admin could disable the Org-Wide MFA setting "Require MFA", but chooses not to
• Privileged Users are still required to use Phishing-Resistant MFA

Possible Scenario

Org has the MFA For All Employees Extension Granted, giving them the option to disable the Org-Wide MFA setting "Require MFA" but chooses to maintain MFA enforcement

Use Case #4: MFA For All Employees Extension Only & Org-Wide MFA setting Disabled

Configuration

• MFA For All Employees Extension:  Granted
• Phishing-Resistant MFA (Passkeys) Extension:  Not Granted
• Org-Wide MFA setting "Require MFA": Disabled (Org admin turns it off)

Behavior

• Non-Privileged Users: No MFA required (password-only login allowed)
• Privileged Users: Must use Phishing-Resistant MFA

Notes

• Non-Privileged Users can use password-only authentication as org Admin chose to disable the Org-Wide MFA setting "Require MFA"
• Privileged Users are still required to use Phishing-Resistant MFA
• The Phishing-Resistant MFA requirement is independent of the Org-Wide MFA setting "Require MFA"
• Users with the Multi-Factor Authentication for User Interface Logins user permission will still be challenged for MFA even when extensions are granted and the Org-Wide "Require MFA" setting is disabled. This user permission is fully managed by org admins.

Possible Scenario

Orgs with SSO-based MFA for Non-Privileged users needing more time, but Phishing-Resistant MFA for Privileged users for direct logins to Salesforce is implemented. 

Use Case #5: Both Extensions Granted & Org-Wide MFA setting Enabled

Configuration

• MFA For All Employees Extension: Granted
• Phishing-Resistant MFA (Passkeys) Extension: Granted
• Org-Wide MFA setting "Require MFA": Enabled (org admin chooses to keep it on)

Behavior

• Non-Privileged Users: Must use at least Standard MFA
• Privileged Users: Must use at least Standard MFA
• All users will be prompted to register a Passkey by default, but will still have the option to Choose Another Verification Method. 

Notes

• Both groups require Standard MFA minimum; Phishing-Resistant MFA is not required

Possible Scenario

Org chose MFA enforcement to help validate their implementation of Standard MFA, but cannot deploy Phishing-Resistant MFA for admins yet

Use Case #6: Both Extensions Granted & Org-Wide MFA setting Disabled

Configuration

• MFA For All Employees Extension: Granted
• Phishing-Resistant MFA (Passkeys) Extension: Granted
• Org-Wide MFA setting "Require MFA": Disabled (org admin turns it off)

Behavior

• Non-Privileged Users: No MFA required (password-only login allowed)
• Privileged Users: No MFA required (password-only login allowed)

Notes

• Lowest security posture — no platform-enforced MFA
• Org may rely on SSO IdP-enforced MFA
• Users with the Multi-Factor Authentication for User Interface Logins user permission will still be challenged for MFA even when extensions are granted and the Org-Wide "Require MFA" setting is disabled. This user permission is fully managed by org admins.

Possible Scenario Customer needs more time to implement all requirements. This is not recommended as it means no level of MFA is being enforced for both Privileged and Non-Privileged users.