Salesforce Requirements for Phishing-Resistant MFA and Step-Up Authentication FAQ

Phishing-resistant MFA is required for privileged users, meaning anyone with elevated permissions that give broad access to data or system configuration. This includes users with a System Administrator profile or users who have permissions such as “View All Data,” “Modify All Data,” or similar rights that allow them to see or change all records on an object, regardless of sharing settings. In your org, this will typically include users who can view or modify all data on an object or manage sensitive configuration settings.

Passwordless login allows users to sign in without a traditional password by using secure identity verification methods, such as biometrics or security keys. Users can register and manage these verification methods as needed.

Once passwordless login is enabled, it applies to all internal users in your organization.

Passkeys are a phishing-resistant authentication method that uses public key cryptography along with a device-based factor, such as biometrics (for example, fingerprint or facial recognition) or a device PIN, to verify a user’s identity. Passkeys are designed to replace traditional passwords.

Common examples of passkey-enabled authentication include FIDO2 security keys, Microsoft Authenticator, Windows Hello for Business, and platform-based solutions such as macOS Secure Enclave with Platform SSO.

Hardware security keys are small physical devices—typically resembling a USB drive or keychain fob—used to verify a user’s identity during authentication. They provide a phishing-resistant MFA method by requiring the user to physically interact with the device.

Common examples include YubiKey and Google Titan security keys, as well as other FIDO2-compatible hardware devices that support passkeys.

Smart cards are physical, credit card–sized tokens that contain an embedded microchip used to securely store and process data for identification and authentication. In MFA scenarios, they are typically used as a physical factor that must be present to verify a user’s identity.

Single sign-on (SSO) must also comply with phishing-resistant multi-factor authentication (MFA) requirements. Salesforce requires signals from your identity provider (IdP) confirming that a phishing-resistant MFA method was used during authentication.

If the IdP does not provide this verification, users will be prompted within Salesforce to enroll in a compliant phishing-resistant MFA method.

If your organization already uses passwordless login or another phishing-resistant authentication method that meets these requirements, SSO is not expected to be impacted.

Users typically create passkeys directly from the login experience or their account security settings once an admin has enabled passwordless login with passkeys in Salesforce and/or the IdP (Identity Provider). In Salesforce, this usually means enabling built-in authenticators or security keys, turning on “Allow passwordless login with passkeys,” and guiding users through creating a passkey during sign-in. In IdP-driven flows (Microsoft, Google, etc.), users often create passkeys from their account security page (for example, “Add a passkey” or “Security key”) while signed in on a supported device.

Passkeys are designed to be significantly more secure and more phishing-resistant than passwords and traditional MFA codes because they use asymmetric cryptography and never expose a reusable secret. The main operational concerns are device management (for example, what happens if a user loses a device) and ensuring your institution has clear policies for backup sign-in methods and account recovery.

Salesforce is moving toward mandatory phishing-resistant MFA and step-up MFA controls for sensitive actions, which means non-compliant configurations are likely to result in increased prompts, limited functionality, or enforcement actions over time. In practice, this can translate into a poor user experience (frequent additional challenges) or blocked high-risk operations, so most institutions will need to adopt at least one supported phishing-resistant method (such as passkeys or FIDO2 keys) to remain aligned.

Step-up authentication is a new security measure enforced by Salesforce that requires users to complete an additional verification method, or “challenge”, when running or viewing a report. The frequency of when step-up authentication is required is controlled by the org administrator, with challenges being required at least every 2 hours. This is required even if the user has recently logged in using MFA or phishing-resistant MFA methods.

Salesforce’s new time-based step-up MFA framework is described as mandatory for all users, including those who log in with federated SSO. Even if initial sign-in occurs via SSO, Salesforce will require an additional challenge (step-up) for sensitive operations—such as viewing or exporting reports—once the period of time determined by the system administrator has passed. SSO users will be challenged via a SMS One-Time Password (OTP) or email.

To align with recent Salesforce security enhancements, we’ve updated how large report-based email sends are handled in our platform. Currently, TargetX email tools use our administrative user (TargetX Integration) to access recipient reports without any limits on how many recipients can be sent content.  

Salesforce has introduced stricter protections around report access and export to reduce the risk of unauthorized data extractionn, aka, “data exfiltration” as documented by Salesforce.  

To operate within these new constraints, email sends utilizing Salesforce reports for TargetX Email and TargetX Communication Planner are now limited to a maximum of 100,000 rows (recipients) per send. Additionally, TX SMS bulk send and TX Print recipient reports will be limited to a maximum of 100,000 rows. To remain compliant and ensure reliable delivery, we’ve aligned our products with these limits.  

If a send is attempted to a recipient report with more than 100,000 rows via TargetX Email, Communication Planner, TX SMS, or TX Print, all system administrators will receive email notice that the job was not processed. The email notification will contain specific information regarding the email, campaign, bulk SMS, or print job so your users know which sending was impacted. 

We understand this may require changes to how recipient reports are built for your organization. We recommend segmenting existing recipient reports into smaller reports based on different recipient variables. For example, report filtering can be used to segment recipient reports based on:  

• Region / geography 
• Student type 
• Student or admissions funnel stage 
• Date ranges (created date, inquiry creation date, application creation date, etc.) 
• Anticipated entry term. 
• Last Name starts with A-L, Last name starts with M-Z, etc. 

See this article for more details and FAQ: Minimizing Disruption Due to New Email Send Limits