Change Overview

Change 1: Phishing-Resistant MFA Enforcement for Privileged Users

Change Details

Salesforce will enforce Phishing-Resistant Multi-Factor Authentication (MFA) for privileged users. This requirement applies to both direct UI logins and SSO logins.

Change Impact

Affected users: Users with any of the following permissions

• System Administrator profile
• Modify All Data
• View All Data
• Customize Application
• Author Apex

Authentication method requirements:

Important reminder: TOTP applications (including Salesforce Authenticator) will no longer meet the MFA requirements for privileged users.

Impact on SSO: Privileged users logging in via SSO must have their Identity Provider (IdP) pass valid phishing-resistant MFA-level AMR/ACR signals in the ID Token or SAML Response. Otherwise, users will be required to register a phishing-resistant MFA verifier on the Salesforce side.

Other impacts: The "Waive Multi-Factor Authentication for Exempt Users" permission will no longer automatically waive MFA. To retain the waiver, contact Salesforce Support for approval.

Change 2: MFA Enforcement for All Employees

Change Details

Salesforce will enforce MFA for all employee users, covering both direct UI logins and SSO logins, applicable to both production and sandbox environments.

Change Impact

Affected users: All employee users without the above privileged permissions (Experience Cloud / Community users are not affected).

Authentication method requirements:

Other impacts:

• The org-level setting "Require MFA for all direct UI logins" will be automatically enabled and cannot be disabled
• The "Waive MFA for Exempt Users" permission will no longer automatically waive MFA
• When new users register for MFA, they will be guided to register Passkey (phishing-resistant option) by default

Change 3: Step-up Authentication for Report and Dashboard Operations

Change Details

Salesforce is implementing a new time-based mandatory step-up MFA authentication framework to enhance data protection for reports and dashboards and prevent unauthorized data exposure.

Change Impact

Core requirements:

• When users access, view, or run reports and dashboards, if the time since the last step-up verification exceeds the administrator-configured time window (2–120 minutes, configurable), the system will require users to complete an additional MFA step-up verification.
• MFA at login does not reset the step-up verification timer. Even if a user has just completed MFA login, they must still complete the step-up verification separately.
• Step-up verification is enforced in all network environments, including trusted IP ranges and corporate intranets.
• SSO users who have not registered MFA on the Salesforce side will complete verification via email or SMS OTP. Step-up verification cannot be delegated to an external IdP.
• The framework adopts a "Fail-Closed" security policy: if the MFA service is unavailable or verification fails, report operations will be blocked.
• Administrators can configure the "Require periodic step-up authentication" policy and verification interval in the Session Level Policies on the Identity Verification page.

Unaffected scenarios: Scheduled/subscribed report auto-delivery, reports and dashboards embedded in Lightning pages, API access, SOQL queries in Developer Console / Workbench, Salesforce Mobile App, Experience Cloud external users, administrator "Login As" sessions, Developer Edition / Scratch and other non-paid organizations.

Change 4: Transaction Security Policy (TSP) Enhancement

Change Details

This change includes two parts:

a) New permission: Modify Transaction Security Policy

• Creating, updating, deleting, enabling, or disabling TSP will simultaneously require both "Customize Application" and "Modify Transaction Security Policy" permissions
• Operating TSP via the UI also requires completing step-up authentication

b) Default ReportEvent TSP

• A default ReportEvent TSP will be automatically deployed for Shield / Event Monitoring customers
• Triggered when the number of report records exported via the UI exceeds 10,000, requiring users to complete step-up authentication
• Only affects UI report exports; does not affect API / Data Loader exports

Change Impact

Affected users:

• All Event Monitoring (EM) / Salesforce Shield customers
• Users managing TSP
• Users exporting large volumes of report data via the UI

Change 1: Phishing-Resistant MFA Enforcement for Privileged Users

1. Audit all privileged users and confirm their MFA registration status
2. Enable Security Key and/or Built-In Authenticators in the Org
3. Recommend enabling Passkey passwordless login
4. If using SSO, confirm that the IdP can pass the correct AMR/ACR signals
5. Notify all privileged users to complete MFA registration before the effective date

Change 2: MFA Enforcement for All Employees

1. Confirm that MFA verification methods are correctly configured in the Org
2. Notify all users to complete MFA registration before the effective date
3. If using SSO, confirm that the IdP passes standard MFA or higher-level AMR/ACR signals
4. Establish an internal MFA access recovery process (administrators generate temporary verification codes)

Change 3: Step-up Authentication for Report and Dashboard Operations

1. Review configuration: (After this policy becomes available) Review the new step-up authentication policy in the sandbox and adjust the time window (2–120 minutes) according to business needs
2. Confirm user verification methods: Ensure all users (especially SSO users) have at least one of the following configured:Salesforce-registered MFA verification method / Valid email address / SMS phone number
3. Notify users: Inform users in advance that they may encounter step-up authentication prompts when accessing reports
4. Assess impact: Evaluate current report usage frequency, set an appropriate step-up authentication interval, and balance security with user experience

Change 4: Transaction Security Policy (TSP) Enhancement

1. Audit users currently managing TSP and assign them the new Modify Transaction Security Policy permission
2. Confirm that relevant users have step-up authentication configured
3. Test the default ReportEvent TSP in the sandbox to confirm whether it meets security requirements
4. If a custom ReportEvent TSP already exists (built via Condition Builder), the default policy will not be automatically deployed