阿里云上的Salesforce 关于特权用户（含管理员）强制抗钓鱼 MFA 的变更及准备工作

本文介绍针对特权用户（包括管理员）的抗钓鱼 MFA 要求。对于不具备下述权限的用户，请参见：阿里云上的Salesforce 关于全员员工强制 MFA 的变更及准备工作。

有哪些变化

Salesforce 将对所有分配了以下任一权限的用户强制执行抗钓鱼多因素身份验证（MFA）：System Administrator profile、Modify All Data、View All Data、Customize Application、Author Apex。此要求适用于直接 UI 登录和 单点登录（SSO）登录，并覆盖生产环境和沙盒组织。

Salesforce 的抗钓鱼 MFA 验证方式基于 WebAuthn 的 Security Keys 和 Built-in Authenticators。这些方式也称为 Passkeys（通行密钥）。Salesforce 建议采用基于 Passkey 的无密码登录（文档中的 remember me 功能在阿里云上的Salesforce 暂不支持），以实现更快的登录体验。

Salesforce 为什么要做出此变更

为了更好地保护组织中最具特权的账户，Salesforce 正在采用抗钓鱼标准，以更强地抵御复杂的身份相关威胁。此更新将使您的组织符合行业最佳实践，确保特权访问仅限于授权用户。

此变更何时生效

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

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

受影响对象

以下条件任一满足的用户，在生产或沙盒组织中通过 Salesforce 登录（直接 UI 或 SSO）时都会受到影响：

• 分配了 System Administrator profile 的用户

• 分配了以下任一特权权限的用户：Modify All Data、View All Data、Customize Application、Author Apex

  • 注意：

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

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

不受影响对象

满足以下条件的用户已符合要求或属于豁免范围，不会受到影响：

• 未分配 System Administrator profile，且不具备以下任一权限的用户：Modify All Data、View All Data、Customize Application、Author Apex

• 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 信号（AMR/ACR），则不受影响。

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

预期行为

管理与策略变化

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

用户登录与注册体验

• 直接 UI 登录：在登录时，包括管理员在内的特权用户将被阻止登录，直到他们注册符合要求的抗钓鱼 MFA 方式（Security Key 或 Built-in Authenticator）。之后的每次登录都需要完成 MFA 验证。

• 应用内横幅提醒：
  对于以下情形，将显示给使用 SSO 登录的所有用户，以及所有组织：
  

  • 已配置 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 登录的特权用户（包括管理员），Salesforce 现在要求 IdP 传送特定信号，以确认在身份提供商层面使用了抗钓鱼 MFA；否则用户将被提示在 Salesforce UI 中注册符合要求的抗钓鱼 MFA 方法。
  

• OAuth Web Server 与 Hybrid Token Flow：
  使用这些流程的 Connected Apps 或 External Client Apps 需要用户在 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 登录。

这些值可能会变更。

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. 审核受影响用户：

   • 确认所有分配了 System Administrator profile 或以下任一权限的用户：Modify All Data、View All Data、Customize Application、Author Apex。您可以使用 Salesforce Reports、User List Views、SOQL 或 User Access and Permissions Assistant。

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

2. 设置组织验证选项：

   确保在组织中启用 Security Keys 和/或 Built-in Authenticators。一旦在 Setup 中启用这些方式，它们将对所有组织用户可用。无法将其限制为仅管理员或其他特权用户使用。

   • [推荐] 启用 Passkey 登录：为实现更快的登录，允许使用 Passkey 进行无密码登录。用户只需使用用户名和 Passkeys（Built-in Authenticator 或 security key）即可满足抗钓鱼 MFA 要求。在 Identity Verification 设置中，打开 “Allow passwordless login with Passkeys.” 详见：基于 Passkey 的无密码登录（文档中的 remember me 功能在阿里云上的Salesforce 暂不支持）。

3. 配置 SSO 以满足 MFA 合规要求

   SSO 有两条主要路径：更新您的身份提供商（IdP），要求抗钓鱼 MFA 认证并传递必要的 AMR/ACR 信号；或为 SSO 登录启用 Salesforce MFA。

   如果使用 IdP 的 MFA 服务，请确认 OpenID Connect 的 ID Token 或 SAML 响应中包含所需的 AMR/ACR 信号。

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

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

4. 测试您的抗钓鱼 MFA 实现

   在测试环境中启用 MFA，确保可以成功注册并使用抗钓鱼 MFA 登录。详见：测试您的 MFA 实现。

5. 预先为用户注册

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

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

• SSO 信号问题：
  如果您的 SSO 提供商使用了抗钓鱼 MFA，但未发送相应信号，用户将被要求在 Salesforce 中注册 MFA。为避免在 Salesforce 中收到提示，请与 SSO 提供商协调，确保正确传递 ACR 或 AMR 信号。
  

• 特权用户锁定：
  如果特权用户完全无法登录，且无法提供抗钓鱼 MFA 因子，另一位组织管理员可以生成临时身份验证代码、断开旧验证方法，并协助重新注册。详见：解决用户的 MFA 访问问题（Salesforce 组织）。如果没有其他管理员，请联系 Salesforce on Alibaba Cloud 技术支持团队寻求帮助。
  

常见问题

Salesforce 支持哪些形式的抗钓鱼 MFA？

Salesforce 支持以下抗钓鱼 MFA 方法：

FIDO2/WebAuthn 验证器

• Built-in Authenticators：
  与设备绑定的 Passkeys，使用设备的安全硬件，并受 PIN 或生物识别保护。示例包括：
  

  • Windows Hello for Business：使用设备的 TPM（Trusted Platform Module）和 PIN 或生物识别；密钥与设备绑定且不可导出

  • Apple Passkeys（Touch ID / Face ID）：内置于 Apple 生态系统（iPhone、Mac、iPad）；密钥可设备绑定，也可通过 iCloud Keychain 同步

  • Android/Google Passkeys：使用设备的安全区域和生物识别

• Security Keys：
  外部 FIDO2/WebAuthn 安全密钥（例如 YubiKey），可通过 USB、NFC 或蓝牙连接
  

• Cloud-Synced Passkeys（云同步通行密钥）：
  通过密码管理器或云钥匙串管理的 Passkeys（例如 1Password、Bitwarden、iCloud Keychain）。虽然不与设备绑定，但只要密码管理器符合 FIDO2/WebAuthn 标准，也可满足抗钓鱼 MFA 要求。
  

基于证书的认证（CBA）

基于证书的认证使用 x.509 客户端证书来验证用户身份。企业证书安装在用户设备上，并通过双向 TLS（mTLS）与 Salesforce 进行认证。证书的私钥由 TPM（Trusted Platform Module）或安全区域等安全硬件保护，因此能够抵御钓鱼和凭据窃取。配置细节请参见：Certificate-Based Authentication。

API 登录会受影响吗？

此变更仅针对基于 UI 的员工登录。

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

1. “Login for Admins” 按钮：
   在 Mobile SDK 13.2.0 及更早版本中，默认 Mobile SDK 身份验证模式（WebView）无法支持抗钓鱼 MFA。使用该版本的管理员将被阻止登录，除非其组织已在 My Domain 设置中预配置 advanced authentication，并使用 My Domain 作为登录服务器。
   如果未配置 advanced authentication，管理员可以使用将于 2026 年 5 月随 Mobile SDK 13.2.1 发布新增的 “Login for Admin” 菜单项。该按钮会强制使用高级、基于浏览器的身份验证，从而自动启用抗钓鱼 MFA。此规则适用于所有基于 Mobile SDK 的 Salesforce 内部和第三方应用。此外，Salesforce Mobile App 管理员也可以使用 “Login with Email” 选项。
   
   

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

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

使用 Salesforce MFA 的特权用户将只能使用 Security Keys 和 Built-in Authenticators。它们将不再允许使用第三方 Authenticator Apps（TOTP）来完成所需的 MFA。

如果通过 SSO 登录，若其 SSO 提供商未传递可证明已使用抗钓鱼 MFA 的必需 AMR 或 ACR 信号，特权用户将看到提示，要求注册并使用 Salesforce MFA。

谁被视为“特权用户”？

特权用户是指拥有 System Administrator profile，或被授予以下任一权限（包括通过权限集授予）的用户：Modify All Data、View All Data、Customize Application、Author Apex。

特权用户可以使用 TOTP 应用作为有效的 MFA 方法吗？

不可以。移动 TOTP 应用不符合针对包括管理员在内的特权用户的新抗钓鱼 MFA 要求。虽然这些工具被归类为标准 MFA，但仍然容易受到钓鱼攻击。对于因技术或组织原因而难以采用抗钓鱼硬件或生物识别方式的特权用户，应联系 Salesforce on Alibaba Cloud 技术支持团队或客户代表寻求指导。

抗钓鱼 MFA 要求是否也适用于特权用户的 SSO 登录，还是只适用于直接用户名/密码登录？

两者都适用。通过 SSO 登录的特权用户必须让其 IdP 发送被认可的抗钓鱼 MFA ACR/AMR 信号。如果未收到此类信号，特权用户将被提示在 Salesforce 中注册抗钓鱼 MFA。在强制执行之前，用户会看到应用内提示以完成注册。

启用抗钓鱼 MFA 是否会改变所有用户的注册流程，还是仅影响特权用户？

在此变更强制执行后，任何被提示设置新 MFA 方法的用户都将被引导注册 Passkey，例如 Security Key 或 Built-in Authenticator，以确保抗钓鱼保护。对于不强制使用抗钓鱼 MFA 选项的用户，仍可选择第三方验证器应用。

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

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

如果检测到抗钓鱼 MFA 信号，用户将立即获得访问权限，无需额外认证。

但是，如果收到的是标准 MFA，或弱 MFA / 无 MFA 信号，则用户将通过 Salesforce UI 被提示选择一种验证方式并将其绑定到 Salesforce 账户。

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

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

如果组织中唯一的管理员被锁定怎么办？

如果管理员完全无法登录，且无法提供抗钓鱼 MFA 因子，另一位组织管理员可以生成临时身份验证代码、断开旧验证方法，并协助重新注册。详见：解决用户的 MFA 访问问题（Salesforce 组织）。如果没有其他管理员，可联系 Salesforce on Alibaba Cloud 技术支持团队获取帮助。

无密码 Passkeys 登录是否算作抗钓鱼 MFA？

是的。即使没有密码，Passkeys（Built-in Authenticators 和 Security Keys）本身也会使用多因素进行身份验证。

在沙盒刷新后，如果 SSO 被禁用且 MFA 验证器丢失，管理员如何重新获得访问权限？

当 Salesforce 沙盒从生产环境刷新时，SAML SSO 设置会部分继承，但由于 Recipient URL 已更新为新的沙盒 URL，SAML SSO 会在沙盒中自动被禁用。因此，刷新后用户无法立即通过 SSO 登录，必须重新配置 SAML 设置后才能恢复访问。关于哪些 SSO 设置会被复制以及哪些会变化的完整说明，请参考：SSO（单点登录）在沙盒刷新期间的SAML设置行为-会复制哪些内容以及会发生哪些变化。

此外，由于验证器是组织级别的，MFA 验证器不会在沙盒刷新后保留。管理员必须先直接登录 Salesforce，并注册新的抗钓鱼 MFA 验证器，然后才能重新配置 SSO。

沙盒刷新后的建议步骤：

1. 使用账户用户名和密码直接登录 Salesforce，并注册抗钓鱼 MFA 验证器（Security Key 或 Built-in Authenticator）

2. 重新配置并重新启用刷新后沙盒的 SAML SSO 设置，包括更新 Recipient URL

注意： 在启动沙盒刷新前，请提前规划，确保至少有一名管理员可直接登录并持有兼容的抗钓鱼验证器（例如硬件安全密钥），因为在重新配置 SAML 设置之前，SSO 将不可用。

此抗钓鱼 MFA 要求是否适用于 Developer Edition、scratch org 或其他非付费组织？

不适用。抗钓鱼 MFA 要求仅适用于付费的 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” 的用户权限。

是否有 SOQL 可用于审核具有管理员或特权权限的用户以确定 PR-MFA 的影响范围？

查询具有标准 System Administrator profile 的用户

SELECT Id, Name, Email, Profile.Name, IsActive
FROM User
WHERE Profile.Name = 'System Administrator'

查询具有特权用户权限的用户

PR-MFA 强制执行所适用的核心 “特权用户” 权限：

- PermissionsModifyAllData — Modify All Data

- PermissionsViewAllData — View All Data

- PermissionsCustomizeApplication — Customize Application

- PermissionsAuthorApex — Author Apex

通过权限集查询具有任一上述权限的用户

SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,
       Assignee.IsActive, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true
   OR PermissionSet.PermissionsViewAllData = true
   OR PermissionSet.PermissionsCustomizeApplication = true
   OR PermissionSet.PermissionsAuthorApex = true

通过 profile 查询具有任一上述权限的用户

SELECT Id, Name, Email, Profile.Name, IsActive
FROM User
WHERE Profile.PermissionsModifyAllData = true
   OR Profile.PermissionsViewAllData = true
   OR Profile.PermissionsCustomizeApplication = true
   OR Profile.PermissionsAuthorApex = true

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 in Salesforce on Alibaba Cloud.

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 (the "Remember Me" function in this document is not supported by Salesforce on Alibaba Cloud) 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

• Preview Sandboxes(CHN5S): Week of August 24, 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 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

  • 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:

• Users who are not assigned the System Administrator profile, or do not have any of these permissions: Modify All Data, View All Data, Customize Application, or Author Apex.

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

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. 

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 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 on Alibaba Cloud Support Team 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 (the "Remember Me" function in this document is not supported by Salesforce on Alibaba Cloud).

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, another 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). If there are no other admins, they can contact Salesforce on Alibaba Cloud Support Team for assistance.

Common Questions

What forms of phishing-resistant MFA does Salesforce support?

Salesforce supports the following phishing-resistant MFA methods:

FIDO2/WebAuthn Authenticators

• Built-in Authenticators: Device-bound passkeys that use the device's secure hardware protected by a PIN or biometric. Examples include:

  • Windows Hello for Business: Uses the device's Trusted Platform Module (TPM) chip with a PIN or biometric; keys are tied to the device and cannot be exported.

  • Apple Passkeys (Touch ID / Face ID): Built into the Apple ecosystem (iPhone, Mac, iPad); keys can be kept device-bound or synced via iCloud Keychain.

  • Android/Google Passkeys: Uses the device's secure enclave and biometrics

• Security Keys: External FIDO2/WebAuthn security keys (e.g., YubiKey), including those that connect via USB, NFC, or Bluetooth.

• Cloud-Synced Passkeys: Passkeys managed through a password manager or cloud keychain (e.g., 1Password, Bitwarden, iCloud Keychain). While not device-bound, they are FIDO2-compliant and meet the phishing-resistant MFA requirement, provided the password manager is FIDO2/WebAuthn-compliant.

Certificate-Based Authentication (CBA)

Certificate-Based Authentication uses x.509 client certificates to verify a user's identity. A corporate certificate is installed on the user's device, and mutual TLS (mTLS) is used to authenticate with Salesforce. The certificate's private key is protected in secure hardware such as a TPM (Trusted Platform Module) or secure enclave, making it resistant to phishing and credential theft. See Certificate-Based Authentication for configuration details.

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 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 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 on Alibaba Cloud Support Team 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?

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

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

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

If an Admin is completely locked out and cannot provide a phishing-resistant MFA factor, another 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). If there are no other admins, they can contact Salesforce on Alibaba Cloud Support Team for assistance

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.

After a sandbox refresh, how do admins regain access when SSO is disabled and MFA verifiers are lost?

When a Salesforce sandbox is refreshed from production, SAML SSO settings are partially carried over but automatically disabled in the sandbox because the Recipient URL is updated to match the new sandbox URL. As a result, users cannot log in via SSO immediately after a refresh, SAML settings must be reconfigured before SSO access is restored. For full details on what SSO settings are copied and what changes, see SSO (Single Sign-On) SAML Settings Behavior During Sandbox Refresh — What Is Copied and What Changes.

Additionally, MFA verifiers do not carry over after a sandbox refresh since verifiers are org-specific. Admins must log in directly to Salesforce and register a new phishing-resistant MFA verifier before they can reconfigure SSO.

Recommended steps after a sandbox refresh:

1. Log in directly to Salesforce with the account username and password, and enroll your Phishing-resistant MFA verifiers (security key or built-in authenticator)

2. Reconfigure and re-enable SAML SSO settings for the refreshed sandbox, including updating the Recipient URL

Note: Plan ahead before initiating a sandbox refresh by ensuring at least one admin has a compatible phishing-resistant verifier (e.g., a hardware security key) available for direct login, since SSO will be unavailable until SAML settings are reconfigured.

Does the Phishing-Resistant MFA requirement apply to Developer Edition, scratch, or other non-paid orgs?

No. The Phishing-Resistant MFA 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.

Is there a SOQL query for auditing users with Admin or privileged permissions for determining scope of user impact for PR-MFA?

Query for Users with the Standard System Administrator Profile

SELECT Id, Name, Email, Profile.Name, IsActive
 FROM User
 WHERE Profile.Name = 'System Administrator'

Query for Users with the privileged User Permissions

 Core "Privileged User" Permissions for Phishing-Resistant MFA Enforcement:

- PermissionsModifyAllData — Modify All Data

- PermissionsViewAllData — View All Data

- PermissionsCustomizeApplication — Customize Application

- PermissionsAuthorApex — Author Apex

 Query for users with any of these permissions - Via Permission Sets

 SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,
 Assignee.IsActive, PermissionSet.Name
 FROM PermissionSetAssignment
 WHERE PermissionSet.PermissionsModifyAllData = true
 OR PermissionSet.PermissionsViewAllData = true
 OR PermissionSet.PermissionsCustomizeApplication = true
 OR PermissionSet.PermissionsAuthorApex = true

Query for users with any of these permissions - via Profiles

 SELECT Id, Name, Email, Profile.Name, IsActive
 FROM User
 WHERE Profile.PermissionsModifyAllData = true
 OR Profile.PermissionsViewAllData = true
 OR Profile.PermissionsCustomizeApplication = true
 OR Profile.PermissionsAuthorApex = true (edited)