阿里云上的Salesforce 关于全员员工强制 MFA 的变更及准备工作

本文适用于不具备特权或管理员权限的用户，如“受影响对象”部分所定义。对于特权用户和管理员，必须使用抗钓鱼 MFA，请参考：阿里云上的Salesforce 关于特权用户（含管理员）强制抗钓鱼 MFA 的变更及准备工作；同时，Salesforce 强烈建议所有用户都采用抗钓鱼 MFA 方式（Security Keys 和 Built-in Authenticators），以获得针对身份类威胁的最高级别防护。

有哪些变化

Salesforce 将对所有员工用户登录强制执行多因素身份验证（MFA），包括直接 UI 登录和 单点登录（SSO），并适用于生产组织和沙盒组织。

Salesforce 支持的 MFA 验证方式按安全强度分为以下类别：

• 抗钓鱼 MFA（推荐）：最安全、最顺畅的体验。包括 Built-in Authenticator（例如 Touch ID、Face ID、Windows Hello ），以及 Security Keys（例如 Yubico 的 YubiKey、Google 的 Titan Security Key）。我们强烈建议采用基于 Passkey 的无密码登录（文档中的 remember me 功能在阿里云上的Salesforce 暂不支持），为用户提供最快速、最安全的认证流程。

• 标准 MFA：第三方 TOTP Authenticator Apps。

Salesforce 为什么要做出此变更

为了提升安全性并更好地保护您的组织，Salesforce 正在通过技术手段强制所有员工使用 MFA，以建立更强的安全基线。此变更有助于降低因凭据被盗、凭据填充（credential stuffing）以及钓鱼攻击而引发的账户接管（ATO）风险。

此变更何时生效

• 预览沙盒环境（CHN5S）：2026 年 8 月 31 日当周

• 非预览沙盒（CHN3S） + 生产环境（CHN1 & CHN20）：2026 年 10 月 12 日当周

受影响对象

此变更会影响在生产或沙盒组织中登录 Salesforce（直接 UI 或 SSO 登录）且满足以下条件的所有用户：

• 不具备以下任一权限的用户：System Administrator profile、Modify All Data、View All Data、Customize Application 或 Author Apex。注意：拥有这些权限的用户将适用更严格的抗钓鱼 MFA要求。

  • 注意：

    • 此要求适用于登录贵公司 Employee Community 或其他 Experience Cloud 站点的内部用户（即持有标准用户许可证的任何人）。

    • Chatter Plus 用户被视为内部用户，需遵守此要求。

不受影响对象

满足以下条件的用户已符合要求或属于豁免范围，不会有变化：

• Experience Cloud 或 Experience Site 登录不会被强制要求使用 MFA，仍然是由组织管理员可配置的可选设置。此豁免适用于持有 Experience Cloud User Licenses的外部用户。

• Chatter External 和 Chatter Free 用户不受 MFA 要求约束。

• 对于已注册 MFA 验证器的直接 UI 登录用户，若其被分配了 “Multi-Factor Authentication for User Interface Logins” 权限，或组织设置 “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” 已启用，则不受影响。

• 对于 SSO 登录，如果用户的 SSO 身份提供商（IdP）已成功向 Salesforce 传递标准 MFA 或抗钓鱼 MFA 信号（AMR/ACR），则不受影响。

关于 SSO 登录说明：Salesforce 依赖客户的身份提供商（IdP）在 ID token 或 SAML 响应中发送行业标准信号：ACR（Authentication Context Class Reference）以及 AMR（Authentication Methods Reference，RFC 8176）。

预期行为

管理与策略变化

• 组织级 MFA 设置强制生效：
  “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” 设置将被启用，且管理员将无法再取消选择或禁用它。
  

• 对 MFA 豁免的影响：
  “Waive Multi-Factor Authentication for Exempt Users” 权限将不再自动豁免用户的 MFA 要求。变更生效后，具有该权限的用户在登录时将被提示注册并使用 MFA 验证器。若要为合法用例（例如自动化测试工具）恢复豁免，必须联系 Salesforce on Alibaba Cloud 技术支持团队获得批准。
  

用户登录与注册体验

• 直接 UI 登录：如果用户尚未注册，系统将提示其注册受支持的 MFA 验证器；此后每次登录都需要完成 MFA 验证。

• 增强的“无密码”登录：login.sfcrmproducts.cn 和 My Domain 页面将更新，允许用户在不输入密码的情况下先输入用户名。此变更简化了使用 passkey（Built-in Authenticator 或 Security Key）登录的用户体验。使用 UI 登录的测试自动化可能需要更新。

• 默认采用抗钓鱼方式：当用户需要注册新的 MFA 方法时，系统将提示其注册 passkey（Built-in Authenticator 或 Security Key，属于抗钓鱼选项）。不强制要求使用抗钓鱼 MFA 的用户仍可选择第三方验证器应用。

• 应用内横幅提醒：在以下情形中，会向所有用户显示：

  • 已配置 Single-Sign-On（SSO），或

  • 关闭了 “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” 设置，或

  • 分配了 “Waive Multi-Factor Authentication for Exempt Users” 权限，或

  • 未向用户提供 Security Keys 和 Built-in Authenticators

单点登录（SSO）与集成要求

• SSO 要求：如果 SSO 用户的身份提供商未传递有效的 AMR（Authentication Methods Reference）或 ACR（Authentication Context Class Reference）信号，则需要在 Salesforce UI 中注册 MFA 验证器。

• OAuth Web Server & Hybrid Token Flow：使用这些流程的 Connected App 或 External Client App 需要用户在 Salesforce UI 中登录以完成 OAuth 授权，此登录也受 MFA 强制策略约束。使用 JWT Bearer 或 Client Credentials 流程的应用不受影响，因为这些流程不需要 UI 登录。

认证强度的判定与评估逻辑

认证强度级别

Salesforce 会根据每次登录的强度进行评估。无论您是直接登录 Salesforce，还是使用单点登录（SSO）提供商登录，您的认证都会被归类为以下三种等级之一：Phishing-Resistant MFA（抗钓鱼 MFA）、Standard MFA（标准 MFA）、Weak MFA / No MFA（弱 MFA / 无 MFA），分类依据是登录方式（Salesforce 作为 IdP 或其他 SSO IdP）以及所使用的具体验证器或信号。该分类取决于您是直接登录（以 Salesforce 作为 IdP）还是通过 SSO 登录。

这些值可能会变更。

Salesforce 如何根据 SSO IdP 的 AMR 和 ACR 信号判断是否满足标准 MFA 或抗钓鱼 MFA 要求

Salesforce 会根据您使用的是 OIDC 还是 SAML，以及信号是 AMR 还是 ACR，以不同方式评估来自 SSO 身份提供商（IdP）的信号。AMR 和 ACR 分别有独立的可接受信号值（请参见上方表格）。要满足要求，SSO IdP 至少必须发送一个与所需等级对应的 AMR 或 ACR 列中匹配的值。抗钓鱼列表中的任意值也会自动满足标准 MFA 要求。

其他评估规则：

SAML AMR

• Salesforce 会解析并评估任何属性名中包含 amr 或 authnmethodsreferences 的 IdP 属性值，将其作为 AMR 信号

• 以分号分隔的字符串中的属性值会被解析和评估（例如 hwk;face;mfa），逗号分隔值不会被评估

• URN/URL 值会按 : 或 /  拆分，因此 urn:custom:auth:hwk 和 https://example[.]com/auth/hwk 都会解析为 hwk

OIDC AMR

• OIDC AMR 是一个数组，（例如 [hwk, mfa]），采用精确值比较进行匹配

ACR（OIDC 与 SAML 均适用）

• 使用对小写字符串的 contains() 检查，因此像 mfa 这样的短令牌可以匹配完整 URN，例如 urn:oasis:names:tc:SAML:2.0:ac:classes:mfa

解决方案

强制执行前：如何准备

1. 审核 MFA 配置和用户：

   1. 确认 “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” 设置状态，并通过 Profiles/Permission Sets 识别具有相关 MFA 权限的用户。

   2. 确认所有分配了 “Waive Multi-Factor Authentication for Exempt Users” 权限的用户。由于该权限的效果在强制执行后将被禁用，因此如需保留合法豁免（例如自动化测试工具），必须联系 Salesforce on Alibaba Cloud 技术支持团队。

2. 设置组织验证选项：定义允许用户使用的 MFA 方法，并明确他们在初始注册期间如何选择方法。

   1. 注意：Salesforce 要求包括管理员在内的特权用户使用抗钓鱼 MFA，这意味着必须启用 Built-in Authenticators 或 Security Keys。一旦在 Setup 中启用这些方式，它们将对所有组织用户可用。无法将其限制为仅管理员使用。

   2. [推荐] 启用 Passkeys：
      在 Identity Verification 设置中打开 “Allow passwordless login with passkeys”，即可启用更快、抗钓鱼的登录体验。用户只需使用用户名和 passkeys（例如 Built-in Authenticator 或 Security Key）即可满足此要求。详见：基于 Passkey 的无密码登录（文档中的 remember me 功能在阿里云上的Salesforce 暂不支持）。
      

3. 建立访问恢复流程：

   为管理员定义内部流程，以处理登录问题（例如生成临时身份验证代码），避免日常重置都依赖 Salesforce on Alibaba Cloud 技术支持团队。详见：解决用户的 MFA 访问问题。

4. 配置 SSO 以满足 MFA 合规要求：SSO 有两条主要路径：更新身份提供商（IdP），要求其执行标准 MFA认证并传递必要的 AMR/ACR 信号；或为 SSO 登录启用 Salesforce MFA。如果使用 IdP 的 MFA 服务，请确认 OpenID Connect 的 ID token 或 SAML 响应中包含所需的 AMR/ACR 信号。

   1. 通过查看 Login History确认 OIDC AMR 信号。

   2. 由于 SAML ACR 值尚未记录在 Login History 中（计划在未来版本支持），请使用第三方 SAML tracer 检查响应。请注意，虽然 Salesforce SAML Validator 会评估 AMR/ACR 声明，但目前只将其分类为 “strong” 或 “weak”，尚未更新为反映本变更中引入的 “weak” “standard” 和 “phishing-resistant” 等认证信号强度等级定义。

5. 预先为用户注册：

   主动向用户沟通时间表，并鼓励他们在强制执行日期之前注册 MFA 方法，以避免登录中断。详见：注册身份验证方法。

6. 测试您的 MFA 实现：

   先在沙盒中启用 MFA，以便在变更到达生产环境前验证您的配置以及用户注册流程。详见：测试 Salesforce 组织中的 MFA 实现。

强制执行后：如何解决错误

以下步骤可用于修复因该变更引起的错误。

1. 识别被阻止的用户：
   监控登录历史，找出无法注册 Salesforce MFA 或无法完成 MFA 验证的用户。结合您的 MFA 支持与访问恢复流程（例如，管理员可为被锁定用户生成一次性登录代码），并参考常见多因素身份验证（MFA）故障排查获取更多帮助。
   

2. SSO 信号问题：
   如果您的 SSO 提供商使用的是抗钓鱼 MFA 或标准 MFA，但没有传递所需信号，用户将被要求在 Salesforce 中注册 MFA。为避免 Salesforce 中的提示，请与 SSO 提供商协调，确保正确传递 ACR 或 AMR 信号。
   

3. 用户锁定：
   如果用户被锁定，您的组织管理员可以生成临时身份验证代码、断开旧验证方法，并协助重新注册。详见：解决用户的 MFA 访问问题（Salesforce 组织）。
   

常见问题

API 登录会受影响吗？

此变更仅适用于基于 UI 的员工登录。

通过 Salesforce mobile app / Salesforce Mobile SDK 登录会怎样？

1. 在 Mobile SDK 13.2.0 及更早版本中，默认 Mobile SDK 身份验证模式（WebView）无法支持例如 Security Keys 之类的抗钓鱼 MFA机制。选择 Security Keys 作为 MFA 方式的用户将被阻止登录；此时，组织必须在 My Domain 设置中预先配置 advanced authentication，并使用 My Domain 作为登录服务器。此规则适用于所有使用 Mobile SDK 的 Salesforce 内部和第三方应用。此外，Salesforce Mobile App 用户可以使用 “Login with Email” 选项。

2. 所有用户的登录体验变更：
   配合抗钓鱼 MFA 要求，Salesforce 正在更改登录流程：先显示用户名字段，用户点击 Log In 后再显示密码或 passkey 字段。此变更可与现有 Mobile SDK 应用兼容，因此不需要代码修改。不过，两步式流程需要更新现有的自动化测试，因为这些测试原本是针对旧流程配置的。
   

如何检查此变更是否已对我的组织或实例生效？

当 “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” 处于激活状态且为灰色不可编辑时，说明该变更已生效。

MFA 现在是否也适用于沙盒组织，而不仅仅是生产环境？

是的。随着此变更，Salesforce 将对所有登录到生产环境和沙盒组织的员工（内部）用户强制要求 MFA。这与之前排除沙盒的 MFA 要求不同。

MFA 是否适用于 Experience Cloud / 社区用户？

不适用。MFA 登录要求仅适用于员工（内部）用户。登录 Experience Cloud 的外部用户和社区用户不受同样的 MFA 登录强制要求约束。

我们已经通过 SSO 提供商（例如 Okta、ADFS、Entra）强制执行 MFA，还需要配置 Salesforce MFA 吗？

SSO 登录可以满足 Salesforce MFA 要求——但前提是您的身份提供商（IdP）发送有效的 AMR（Authentication Methods Reference）或 ACR（Authentication Context Class Reference）信号，证明已使用 MFA。默认情况下，所有 SSO 登录都会被视为没有 MFA，直到收到可识别的抗钓鱼 MFA 或标准 MFA 信号。如果 Salesforce 无法从您的 IdP 检测到有效信号，系统会提示用户在 Salesforce 中注册 MFA。

Salesforce 可识别哪些来自 SSO 提供商的 MFA 信号值？

可接受值列表请参见上方认证强度级别表格。

如果检测到抗钓鱼 MFA 或标准 MFA 信号，用户将立即获得访问权限，无需额外认证。
但是，如果收到的是 弱/无 MFA 信号，则用户将通过 Salesforce UI 被提示选择一种验证方式并将其绑定到 Salesforce 账户。

还能使用 “Waive Multi-Factor Authentication for Exempt Users” 权限吗？

在强制执行日期之后，此权限将不再自动豁免 MFA 要求。具有该权限的用户将被提示在 Salesforce UI 中注册并使用 MFA。若要为合法用例（例如自动化测试工具）恢复豁免，必须联系 Salesforce on Alibaba Cloud 技术支持团队获得批准。

如果用户或管理员被锁定怎么办？

如果用户被锁定，其组织管理员可以生成临时身份验证代码、断开旧验证方法，并协助重新注册。详见：解决用户的 MFA 访问问题（Salesforce 组织）。

MFA for All Employees 要求是否适用于 Developer Edition、scratch org 或其他非付费组织？

不适用。MFA for All Employees 要求仅适用于付费的 Production 和 Sandbox 组织。Developer Edition、scratch org 以及其他非付费组织类型不在强制范围内。

是否有 SOQL 可用于审核拥有 “Waive Multi-Factor Authentication for Exempt Users” 用户权限的用户？

方案 1：通过 PermissionSetAssignment 查询（查找通过权限集拥有该权限的用户）

SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,
Assignee.IsActive, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsBypassMFAForUILogins = true

方案 2：通过 Profile 查询（查找已启用该权限的 profile）

SELECT Id, Name, PermissionsBypassMFAForUILogins
FROM Profile
WHERE PermissionsBypassMFAForUILogins = true

注意：关键 API 字段名 PermissionsBypassMFAForUILogins 对应 UI 中显示为 “Waive Multi-Factor Authentication for Exempt Users” 的用户权限。

This article addresses MFA requirements for users without privileged or admin permissions, as defined in "Who's Affected"). While privileged users and admins are required to use phishing-resistant MFA, please refer to: Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins in Salesforce on Alibaba Cloud. Salesforce strongly recommends that all users adopt phishing-resistant MFA methods (security keys and built-in authenticators) to ensure the highest level of protection against identity-based threats.

What's Changing

Salesforce is enforcing Multi-Factor Authentication (MFA) for all employee logins, including direct UI and Single Sign-On (SSO), across both production and sandbox orgs.

Supported MFA verification methods in Salesforce are categorized by their security strength:

• Phishing-Resistant MFA (Recommended): The most secure and seamless experience. This includes Built-in Authenticators (e.g.,Touch ID, FaceID, Windows Hello) and Security Keys (e.g.,YubiKey from Yubico and the Titan Security Key from Google). We highly recommend adopting Passwordless login via Passkeys (the "Remember Me" function in this document is not supported by Salesforce on Alibaba Cloud) to provide users with the fastest and most secure authentication flow available.

• Standard MFA: Third-party TOTP Authenticator Apps.

Why Is Salesforce Making This Change

To increase security and better protect your org, Salesforce is moving toward a stronger baseline by technically enforcing MFA for all employees. This change helps to mitigate account takeover (ATO) risks stemming from stolen credentials, credential stuffing, and phishing.

When Does This Change Take Effect

• Preview Sandboxes(CHN5S): Week of August 31, 2026

• Non-Preview Sandboxes(CHN3S) & Production(CHN1&CHN20): Week of October 12, 2026

Who's Affected

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

• Any user who does not possess any one of these privileges: System Administrator profile, Modify All Data, View All Data, Customize Application, or Author Apex. Note: Users with these privileges are subject to stricter Phishing-Resistant MFA requirements.

  • Note:

    • This requirement applies to internal users (that is, anyone with a standard user license) who log in to your company's Employee Community or other Experience Cloud sites.

    • Chatter Plus users are considered internal users and are subject to this requirement.

Who's Not Affected

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

• Experience Cloud or Experience Site Logins are not forced to use MFA, and continue to be an optional setting configurable by org Admins. This exclusion applies to external users with Experience Cloud User Licenses.

• Chatter External and Chatter Free users are excluded from MFA.

• Direct UI logins where users have a registered MFA verifier already and either the user is assigned the "Multi-Factor Authentication for User Interface Logins" permission or where the org 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 standard MFA or 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 in the ID token or SAML response: ACR (Authentication Context Class Reference) and AMR (Authentication Methods Reference, RFC 8176).

What to Expect

Administrative & Policy Changes

• Enforcement of Org-Wide MFA Setting: "Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org" setting becomes active, and Admins will no longer have the ability to deselect or disable it.

• 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 on Alibaba Cloud Support Team for approval.

User Login & Registration Experience

• Direct UI Logins: users will be prompted to enroll a supported MFA verifier if they haven't previously enrolled, and for all subsequent logins complete the MFA challenge to log in.

• Enhanced "Passwordless" Login: The login.sfcrmproducts.cn and My Domain pages will be updated to enable users to enter their username without a password. This change streamlines the user experience for users who log in with a passkey (built-in authenticator or security key) instead of a password. Test automations that use UI logins may need to be updated.

• Phishing-Resistant Defaults: When users are required to register a new MFA method, they will be prompted to register a Passkey (Built-in Authenticator or Security Key which are phishing-resistant options). Users that do not require a phishing-resistant MFA option will have the option to choose third party authenticator apps.

• In-app Banner reminders will be shown to all users 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: SSO users whose identity provider does not transmit a valid AMR (Authentication Methods Reference) or ACR (Authentication Context Class Reference) signal will be required to enroll an MFA verifier 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 (Salesforce as IdP or other SSO IdP) and what are the specific verifiers or signals present. The classification depends on whether you log in directly (Salesforce as IdP) or via SSO. 

These values are subject to change.

How Salesforce evaluates AMR and ACR signals from an SSO IdP to determine if Standard MFA or Phishing-Resistant MFA requirements are met

Salesforce evaluates signals from your SSO Identity Provider (IdP) differently depending on whether you use OIDC or SAML, and whether the signal is an AMR or ACR value. AMR and ACR have separate accepted signal values (refer to list of values in the table above). To satisfy the requirement, the SSO IdP must send at least one value that matches an entry in the appropriate AMR or ACR column for the required tier. Any value in the Phishing-Resistant list automatically satisfies the Standard MFA check as well.

Additional evaluation criteria:

SAML AMR

• Salesforce parses and evaluates any IdP attribute value whose attribute name contains amr or authnmethodsreferences as an AMR signal

• Attribute values in a semicolon-separated string (e.g., hwk;face;mfa) will be parsed and evaluated, comma-separated values are not evaluated

• URN/URL values are split on : or / so urn:custom:auth:hwk and https://example[.]com/auth/hwk both resolve to hwk

OIDC AMR

• OIDC AMR is an array (e.g., [hwk, mfa]) matched with exact value comparison

ACR (both OIDC and SAML)

• Uses a contains() check on the lowercased string, so short tokens like mfa match full URNs like urn:oasis:names:tc:SAML:2.0:ac:classes:mfa

Resolution

Before Enforcement: How to Prepare

1. Audit MFA Configurations and Users: 

   1. Verify the "Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org" setting status, and identify users with direct MFA permissions (via Profiles/Permission Sets). 

   2. 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 on Alibaba Cloud Support Team to retain the exemption for valid use cases (e.g., automated testing tools).

2. Set Up Org Verification Options: Define the allowed MFA methods for your users and establish how they choose a method during initial registration.

   1. Note: Salesforce requires Privileged Users including Admins users to use phishing-resistant MFA, which means that you must enable built-in authenticators or security keys. 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. 

   2. [Recommended] Activate Passkeys: Enable faster, phishing-resistant logins by toggling on "Allow passwordless login with passkeys" in Identity Verification settings. Users can fulfill this requirement by logging in with just their username and a passkey, such as a built-in authenticator or security key. See Passwordless login using Passkeys (the "Remember Me" function in this document is not supported by Salesforce on Alibaba Cloud).

3. Establish Access Recovery Procedures: Define internal processes for Admins to resolve login issues (e.g., generating temporary identity verification codes) to prevent reliance on Salesforce on Alibaba Cloud Support Team for routine resets. See Resolve MFA Access Issues for Your Users.

4. Configure SSO for MFA Compliance: You have two primary paths for SSO: either update your Identity Provider (IdP) to require standard 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.

   1. Confirm OIDC AMR signals by reviewing Login History.

   2. 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.

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

6. Test Your MFA Implementation: Enable MFA in a sandbox first to validate your configuration, and the user registration flow before the changes reach production. See Test Your MFA Implementation for Salesforce Orgs.

After Enforcement: Resolve Errors

The steps below resolve errors caused by the change.

1. Identify Blocked Users: Monitor login history for users unable to enroll in Salesforce MFA or complete their MFA challenge. Utilize your MFA Support & Access Recovery Procedures (e.g., for locked-out users, Admins can generate a one-time login code), and reference the Common Multi-Factor Authentication (MFA) Troubleshooting for additional help.

2. SSO Signal Issues: If your SSO provider is using phishing-resistant MFA or standard MFA authentication, but doesn't pass required signals, you 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.

3. User Lockouts: if a user is locked out, a customer org Admin can generate a temporary identity verification code, disconnect old verification methods, and assist with re-registration. See Resolve MFA Access Issues for Your Users (Salesforce Orgs).

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. In Mobile SDK version 13.2.0 and earlier, the default Mobile SDK authentication mode (WebView) cannot support Phishing resistant MFA mechanisms such as Security keys. Users who choose security keys as their MFA option will be blocked from logging in and it is required that their organization pre-configures advanced authentication in the My Domain settings and they use the my domain as their login server. This applies to all the Salesforce internal and third party apps using Mobile SDK. Additionally, Salesforce Mobile App users 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?

"Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org" is active and greyed out. 

Does MFA now apply to sandbox orgs, not just production?

Yes. With these changes, Salesforce is requiring MFA for all employee (internal) users logging into both production and sandbox orgs. This is a change from prior MFA requirements, which excluded sandboxes. 

Does MFA apply to Experience Cloud / Community users?

No. The MFA login requirement applies to employee (internal) users only. External users logging into Experience Cloud and Community users are not subject to the same MFA login mandate. 

We already enforce MFA through our SSO provider (e.g., Okta, ADFS, Entra). Do we still need to configure Salesforce MFA?

SSO logins can satisfy the Salesforce MFA requirement — but only if your identity provider (IdP) sends valid AMR (Authentication Methods Reference) or ACR (Authentication Context Class Reference) signals proving MFA was used. By default, all SSO logins are treated as having no MFA until a recognized phishing-resistant MFA or standard MFA signal is received. If Salesforce cannot detect a valid signal from your IdP, users will be prompted to enroll in Salesforce MFA.

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

For the list of accepted values, see the table in the above section titled: Authentication Strength Tiers.

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

However, if Weak / 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 on Alibaba Cloud Support Team for approval.

What if a user or admin gets locked out?

If a user is locked out, their org Admin can generate a temporary identity verification code, disconnect old verification methods, and assist with re-registration. See Resolve MFA Access Issues for Your Users (Salesforce Orgs).

Does the MFA for All Employees requirement apply to Developer Edition, scratch, or other non-paid orgs?

No. The MFA for All Employees requirement is scoped to paid Production and Sandbox orgs only. Developer Edition orgs, scratch orgs, and other non-paid org types are not subject to enforcement.

Is there a SOQL query for auditing users with the "Waive Multi-Factor Authentication for Exempt Users" user permission?

Option 1: Query via PermissionSetAssignment (finds users with the permission through permission sets)                              

 SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username, 
 Assignee.IsActive, PermissionSet.Name 
 FROM PermissionSetAssignment 
 WHERE PermissionSet.PermissionsBypassMFAForUILogins = true 

Option 2: Query via Profile (finds profiles that have the permission enabled)

 SELECT Id, Name, PermissionsBypassMFAForUILogins 
 FROM Profile 
 WHERE PermissionsBypassMFAForUILogins = true 

Note:  Key API field name: PermissionsBypassMFAForUILogins corresponds to the user permission labeled "Waive Multi-Factor Authentication for Exempt Users" in the UI.