Loading
Salesforce now sends email only from verified domains. Read More

Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins

Publish Date: May 5, 2026
Description

This article describes phishing-resistant MFA requirements for Privileged Users, including Admins. For users without the permissions articulated below, see Prepare for MFA Enforcement for All Employee Users.

For more info on the roadmap of upcoming targeted Security changes for the Salesforce Platform, see: Security-Related Product Updates to the Salesforce Platform.

What’s Changing

Salesforce is enforcing phishing-resistant Multi-Factor Authentication (MFA) for all users with the System Administrator profile, Modify All Data, View All Data, Customize Application, or Author Apex permissions). This applies to direct UI logins and Single-Sign-On (SSO) logins, across both production and sandbox orgs. 

Salesforce’s phishing-resistant MFA verification methods leverage WebAuthn-based Security Keys and Built-in Authenticators. We also refer to these methods as Passkeys. Salesforce recommends adopting passwordless login via passkeys for faster logins.

Why Is Salesforce Making This Change

To better protect your org’s most privileged accounts, Salesforce is adopting phishing-resistant standards that provide a stronger defense against sophisticated identity-based threats. This update aligns your org with industry best practices to ensure that privileged access remains exclusive to authorized users.

When This Change Takes Effect

  • Sandboxes: Starting June 22, 2026, staggered over approximately 7 days
  • Production: Starting July 1, 2026, staggered over approximately 30 days


Who’s Affected

This change affects all users logging into Salesforce (direct UI or SSO logins) in production or sandbox orgs who meet any of the following conditions:

  • Users assigned with the System Administrator profile,

  • Users assigned with any one of these privileged permissions: Modify All Data, View All Data, Customize Application, or Author Apex

Who’s Not Affected

Users who meet these criteria are already compliant or exempt, and will experience no change:

  • Users who are not assigned the System Administrator profile, or have Modify All Data, View All Data, Customize Application, or Author Apex permissions

  • Experience Cloud or Experience Site Logins are not forced to use MFA, and continue to be an optional setting configurable by org Admins.

  • Direct UI logins where users have a registered phishing-resistant MFA verifier already and either the user is assigned the "Multi-Factor Authentication for User Interface Logins" permission or where the org-wide MFA setting “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” is active.

  • SSO logins where users whose SSO IdP already successfully passes a phishing-resistant MFA signal (AMR/ACR) to Salesforce.

Note for SSO logins, we rely on the customer’s Identity Provider (IdP) sending industry standard signals: ACR (Authentication Context Class Reference) and AMR (Authentication Methods Reference, RFC 8176). 

What to Expect

Administrative & Policy Changes

  • Impact to MFA Exemptions: The "Waive Multi-Factor Authentication for Exempt Users" permission will no longer automatically exempt users from MFA. After this change, users with this permission will be prompted to enroll and use an MFA verifier at login. To restore this exemption for valid use cases (e.g., automated testing tools), you must contact Salesforce Support for approval.

  • Trial Org Transition: Trial Orgs converted to a subscription will no longer be given a 30 day grace period for the MFA requirement. 

User Login & Registration Experience

  • Direct UI Logins: Upon login, privileged users including Admins will be blocked from logging in to the org until they register a compliant phishing-resistant MFA method (Security Key or Built-in Authenticator), and for all subsequent logins complete the MFA challenge to login.

  • In-app Banner reminders will be shown to all users logging in with SSO, and in all orgs where:

    • Single-Sign-On (SSO) is configured or

    • “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” setting is disabled, or

    • “Waive Multi-Factor Authentication for Exempt Users" permission is assigned, or

    • Security Keys and Built-in Authenticators verifiers are not made available to users.

    Single Sign-On (SSO) & Integration Requirements

    • SSO Requirements: for privileged users including Admins logging in via Single Sign-On (SSO), Salesforce will now require specific signals to verify that a phishing-resistant MFA method was used at the Identity Provider (IdP) level, or the user will be prompted to enroll a compliant phishing-resistant MFA method in the Salesforce UI.

    • OAuth Web Server & Hybrid Token Flows: Connected Apps or External Client Apps using these flows require users to log in to the Salesforce UI to complete OAuth authorization, this login is subject to MFA enforcement. Apps using JWT Bearer or Client Credentials flows are unaffected, as no UI login is required.

    Determining Authentication Strength & The Evaluation Logic

    Authentication Strength Tiers

    Salesforce evaluates every login based on its strength. Whether you log in directly to Salesforce or use a Single Sign-On (SSO) provider, your authentication is categorized into one of three tiers: Phishing-Resistant MFA, Standard MFA, or Weak MFA / No MFA, based on the login method and what are the specific verifiers or signals present. The classification depends on whether you log in directly (Salesforce as IdP) or via SSO. 

    Tier

    Direct Salesforce Login (Salesforce MFA verifiers)

    SSO
    (AMR/ACR Signals from your Identity Provider)

    Result

    Phishing-
    Resistant MFA

    Security Keys (WebAuthn), Built-in Authenticators (Touch ID, Windows Hello)

    cert, fido, fido2, fpt, hwk, iris, pin, pki, pop, retina, sc, smartcard, swk, TLSClient, user, vbm, wia, x509

    Successful login.

    Standard MFA

    Salesforce Authenticator, TOTP Apps (Google/Microsoft Auth), and Admin-Generated Temporary Verification Codes

    face, mobiletwofactorcontract, multipleauthn, okta_verify, passkey, webauthn

    Login blocked until enrollment and use of phishing-resistant MFA verifiers.

    Weak / No MFA

    No MFA

    pwd, sms, tel, email

    Login blocked until enrollment and use of phishing-resistant MFA verifiers.

     

    These values are subject to change.

     

    Resolution

    Before Enforcement: How to Prepare

    1. Audit Users Impacted by the Change: 

      • Identify all users who are assigned the System Administrator profile or any of the following permissions: Modify All Data, View All Data, Customize Application, or Author Apex. You can use Salesforce Reports, User List Views, SOQL, or the User Access and Permissions Assistant.

      • Identify all users assigned the "Waive Multi-Factor Authentication for Exempt Users" permission. Because the effect of this permission will be disabled when the change is enforced, you must contact Salesforce Support to retain the exemption for valid use cases (e.g., automated testing tools).

    2. Set Up Org Verification Options - ensure Security Keys and/or Built-In Authenticators are enabled in your Org. Once you enable these methods in Setup, they will be available for all org users. There is no ability to restrict their use to only Admins or other privileged users. 

      • [Recommended] Activate Passkey login: For faster logins, allow passwordless login with passkeys. Users can satisfy the phishing-resistant MFA requirement by logging in with just their username and their passkey (built-in authenticator or security key). In your Identity Verification settings, toggle on "Allow passwordless login with passkeys." See Passwordless login using Passkeys.

    3. Configure SSO for MFA Compliance: You have two primary paths for SSO: either update your Identity Provider (IdP) to require phishing-resistant MFA authentication and transmit the necessary AMR/ACR signals, or you may enable Salesforce MFA for your SSO logins. If leveraging your IdP’s MFA service, confirm that the ID token (for OpenID Connect) or the SAML response includes the required AMR/ACR signals.

      • Confirm OIDC AMR signals by reviewing Login History.

      • As SAML ACR values are not yet recorded in Login History (planned for a future release), use a third-party SAML tracer to inspect responses. Note that while the Salesforce SAML Validator assesses AMR/ACR claims, it currently only classifies them as "strong" or "weak" and has not yet been updated to reflect the specific "weak," "standard," and "phishing-resistant" authentication signal strength tiers definitions introduced by this change.

    4. Test your Phishing-Resistant MFA implementation: In your test environment, enable MFA to ensure you can successfully enroll and use phishing-resistant MFA to login. See Test your MFA implementation.

    5. Pre-Register Users: Proactively communicate the timeline to all privileged users and encourage them to register their phishing-resistant MFA methods before the enforcement date to avoid login disruptions.  See Register an identity verification method.

    After Enforcement: Resolve Errors

    • SSO Signal Issues: If your SSO provider is using phishing-resistant MFA, but doesn't send corresponding signals, users will be required to enroll in Salesforce MFA. To prevent prompts within Salesforce, coordinate with your SSO provider to ensure the ACR or AMR signals are correctly transmitted.

    • Privileged User Lockouts: If a privileged user is completely locked out and cannot provide a phishing-resistant MFA factor, they must contact Salesforce Support to obtain a one-time login code.

    Additional Resources

    Common Questions

    How are API logins affected?

    This change targets UI-based employee logins only

    How are logins via the Salesforce mobile app on Salesforce Mobile SDK logins affected?

    1. “Login for Admins” button: In Mobile SDK version 13.2.0 and earlier, the default Mobile SDK authentication mode (WebView) cannot support phishing-resistant MFA. Admin users on this version will be blocked from logging in unless their organization pre-configures advanced authentication in the My Domain settings and uses the my domain as their login server. If advanced authentication is not configured, admins can use a new “Login for Admin” menu item that will be added in May 2026 with the release of Mobile SDK 13.2.1. This button forces advanced, browser-based authentication, which enables phishing-resistant MFA automatically. This applies to all the Salesforce internal and third party apps using Mobile SDK. Additionally, Salesforce Mobile App admins can use the "Login with Email" option.
    2. Login UX Change for all users: Accompanying the phishing-resistant MFA requirement, Salesforce is changing the login flow so that it displays the username field first, then the password or passkey field after the user clicks Log In. This change works with existing Mobile SDK apps, which means it does not require code changes. However, the two-step flow requires updates to existing automated tests that are configured to handle the previous flow.

    How do I check if the change has taken effect for my org or instance?

    Privileged users using Salesforce MFA will only be permitted to use security keys and built-in authenticators. They will no longer be allowed to use the Salesforce Authenticator or Third Party Authenticator Apps (TOTP) to complete required MFA.

    If using SSO to login, privileged users will see prompts to enroll and use Salesforce MFA if their SSO provider does not pass the required AMR or ACR signals that confirm phishing-resistant MFA was used. 

    Who is considered a "privileged user" for the phishing-resistant MFA requirement?

    A privileged user is any user with the System Administrator profile or any user granted one of the following permissions (including via permission sets): Modify All Data, View All Data, Customize Application, or Author Apex. 

    Can privileged users use TOTP apps as a valid MFA method?
    No. Mobile TOTP applications, including Salesforce Authenticator, do not meet the new phishing-resistant MFA requirement for privileged users including Admins. While these tools are classified as standard MFA, they remain susceptible to phishing. Privileged users facing technical or organizational barriers to adopting phishing-resistant hardware or biometrics should contact Salesforce Support or their account representative for guidance.

    Does the phishing-resistant MFA requirement apply to privileged user SSO logins too, or only direct username/password logins?

    It applies to both. Privileged users logging in via SSO must have their IdP send a recognized phishing-resistant MFA ACR/AMR signal. If no such signal is received, privileged users will be prompted to enroll in Salesforce phishing-resistant MFA. Prior to enforcement, users will see an in-app prompt to complete enrollment. 

    Does enabling phishing-resistant MFA change the enrollment process for all users or just privileged users?

    Upon enforcement of this change, any user prompted to set up a new MFA method will be directed to enroll a Passkey, such as a Security Key or Built-in Authenticator, to ensure phishing-resistant protection. For individuals who are not mandated to use a phishing-resistant MFA option, the option to select a third-party authenticator app will remain available.

     

    Which phishing-resistant MFA signal values are recognized by Salesforce from an SSO provider?

    Salesforce categorizes SSO MFA strength into three distinct tiers:

    • Phishing-Resistant MFA: cert, fido, fido2, fpt, hwk, iris, pin, pki, pop, retina, sc, Smartcard, swk, TLSClient, user, vbm, wia, X509

    • Standard MFA: Face, mobiletwofactorcontract, multipleauthn, okta_verify, passkey, webauthn

    • Weak MFA / No MFA (default): pwd, sms, tel, email

    If phishing-resistant MFA signals are detected, the user gains access immediately with no additional authentication requirements.

    However, if standard MFA, or Weak MFA / No MFA signals are received then the user will then be prompted via the Salesforce UI to select a verification method and link it to their Salesforce account.

    Can we still use the "Waive Multi-Factor Authentication for Exempt Users" permission?

    After the enforcement date, this permission will no longer automatically waive MFA requirements. Users with this permission will be prompted to enroll and use MFA in the Salesforce UI. To restore the exemption for valid use cases (e.g., automated testing tools), you must contact Salesforce Support for approval.

    What if the only Admin for an org gets locked out?

    If an Admin is locked out and no other org Admins can support them, contact Salesforce Support for a one-time login code.

     

    Does passwordless login with passkeys count as phishing-resistant MFA?

    Yes. Even without a password, passkeys (built-in authenticators and security keys) inherently use multiple factors for authentication.

     

    Change Log

     

    Date

    Change

    May 5, 2026

    Initial publication

     

    Knowledge Article Number

    005321563

     
    Loading
    Salesforce Help | Article